To start with, I just love FirePHP. This extension extends Firebug itself and allows PHP to show messages in the console.

FirePHP use special headers to send required information, so browses without FirePHP doesn’t feel any difference, but others can easily extract information. It doesn’t mean that DB profiling information should be visible in production server, but it definitely helps in development stages. If you look at normal website’s headers you would see something like this:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:29:29 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

where FirePHP modifies it to:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:28:39 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
X-Wf-Protocol-1: http://meta.wildfirehq.org/Protocol/JsonStream/0.2
X-Wf-1-Structure-1: http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-1-Plugin-1: http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-1-1-1: 56|[{"Type":"INFO","File":"","Line":""},"This is a debug!"]|
X-Wf-1-1-1-2: 58|[{"Type":"ERROR","File":"","Line":""},"This is an error!"]|
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

FirePHP website has libraries for sending these headers, but since I was trying it when using Zend Framework, I chose Zend_Log_Writer_Firebug module. It works as writer interface for Zend_Log and since Zend_Log is (or should be) used for all logging in ZF, you can get very nice access to all information (execution time, queries, warnings, etc.) from browser. For example, to send something with Zend Framework, code would look like this:

// Place this in your bootstrap
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
 
// Use this in your model, view and controller files
$logger->log('This is a log message!', Zend_Log::INFO);

Simple and clean (it won’t work if Zend_Controller_Front is not used, look at manual).

Logging to files still should be used for information which will be required for further analysis, eg. payment gateway errors, but such information as execution time works perfectly in FirePHP. Users doesn’t care how fast page was rendered, but developers sometimes needs this information and in my opinion, using FirePHP sounds most reasonable. Have you tried it?

Our task is to give browser enough information to identify content, which later can be used to decided if content has changed, and if not – say it to browser without sending content again. Bigger picture is explained here, I really recommend analysing it a little bit – it gives better understanding how headers work and what they mean.

As you saw in headers map, there are many possible headers to send, but we can focus on three of them:

1. Etag. Unique identified for output data (maybe hash)
2. Last-Modified. Date of last data modification
3. Expires. When to expire content

Constructing algorithm is pretty simple, it can be explained in pseudo-code:

get request headers
   is content expired
      send content, new headers
   else is content different (Etag)
      send content, new headers
   else
      304 header, no content

I’ve created outputCacheHeaders(…) function which (available here) outputs all required headers and returns true if you need to output content or false if not. All you need to do is pass modification time, live time and data (two last ones are not required). Live time says how long should cache be kept and data is used to generate Etag. Very simple!

After enabling correct headers sending, my websites started to feel much faster, because HTTP requests takes much less time. Also, Yahoo performance tips are really worth reading, really. There are many great tips and I have been using many of them for a long time. These tricks are much much more significant than 0.1 s. faster PHP rendering time.