PHP browser caching confusion

[chobo]

Hi, I'm trying to utilize both server-side caching and client-side caching, but I'm having trouble understanding exactly how I should go about controlling the browser cache with PHP.

I haven't written any code yet, and I plan on using PHP Pear cache lite, so far this is the order I am planning to do things.

1. Disable client side caching with php by sending the appropriate headers
2. Create cache files for specific parts of a page (header, body, footer, etc...) using PHP and the pear lite class
3. Control the browser cache using the last modified header?

Say for example that a user is loading up the page "index.php", which utilizes server-side caching and creates three cache files (header.cache, body.cache, and footer.cache). If I'm controlling the browser cache do I check when the index.php file is modified and compare it to something? I'm not even sure what to compare that to... I'm kind of lost on step 3, if anyone can help clear things up that would be awesome.

PS: I have read the guide/tutorial on sitepoint titled PHP anthology 2... that deals with this (which is really good), but didn't go into enough detail on browser caching.

[Mittineague]

AFAIK you can control the server-side cache. But the headers and meta tags only instruct the browser. How a user has their browser configured is beyond your control.

[chobo]

With controlling browser cache (client-side cache) I'm referring to this tutorial on sitepoint

http://www.sitepoint.com/article/php...-2-5-caching/4

Here the author utilizes the browers cache, as well as server-side caching. I think on each page request he checks for a last-modified header and compares it to something else (not sure what). I just don't get that whole comparing the "last modified header" bit.

[chobo]

I've decided to hold off on dealing with browser-side caching for awhile. I just finished setting up pear cache lite for the body of my index page, which just runs a query to get some results.

What kind of shocked me was the fact that it is faster to not use the pear caching system for that. I benchmarked (apache ab) with and without caching on that page and it was about twice as fast without caching . I think this has to do with the constant require and instantiation of the cache lite object, which seems to take more resources then that query.

[TheRedDevil]

Yes, if your site is "lightweight" using cache solutions will most of the time make the site slower.

Especially if you use the bloated pear library.

There are many ways you can implent a cache solution, but unless your site has a few "resource" demanding pages or has high traffic, there is basically no use for you to add it.

Keep in mind that when you "over optimice" the script you usally get into problems. Finish the page and if its heavy on the load or get a steady heavy traffic then implent a cache solution.

[Mittineague]

I see the article is referring to HTTP headers

Expires, Last-Modified, and If-Modified-Since, as well as HTTP status code 304 (Not Modified)

These are helpful if you don't want a file to be cached (eg. a dynamic image) that you want to be reloaded every so often. Or if a file (esp. a large, slow loading file) is used on multiple pages or that you would rather not be reloaded as often.
But AFAIK even using HTTP headers does not provide control in the strict sense, only if the user has the browser configured to go by them.

[chobo]

Thanks for help, I just assumed caching would be something useful to add right now, but obviously it's not

[Mittineague]

As TheRedDevil mentioned, it can be useful. If you have any heavy weight files (large images, swf, etc) or a page that uses a lot of database or other server resources, or if your site gets lots of traffic, then it can be a very good idea.

[TheRedDevil]

Images, flash, javascript, css files etc are cached automatically as long as they are not served with "no cache" headers and the browser has not been configured to work without a cache.

[Mittineague]

are cached automatically

:d'oh: True indeed. I guess it might be more important to use "no cache" on dynamic content to keep it fresh.

[kromey]

I built a CMS recently that was designed from the get-go to be "cache-friendly". Although the load to build each page was not high enough to warrant implementing server-side caching, I did include HTTP headers intended to strongly suggest to the browser that it cache my pages (Mittineaque is exactly right, best you can do is suggest that the browser cache your pages, it's entirely up to the browser whether it will or not).

Since every "page" in my CMS included a column in the database to hold the last-modified date, and I was using a single file as the template, sending a last-modified header was easy:

//date of the last modification of the content or the template
header("Last-Modified: ".gmdate("r", max($cms['lastmodified'], filemtime($template)))); 

I also used the ETag header, although in practice it's just a failsafe in case a browser doesn't acknowledge Last-Modified:

//if the content or the template change, the page has changed
header("Etag: ".md5($cms['lastmodified'].filemtime($template))); 

Then every request made to the server that includes either a If-Modified-Since or If-None-Match has those values compared with the ones computed above; if they match, I send an HTTP 304 Not Modified response and terminate execution (as per spec, a 304 response MUST NOT include any entity-body - the whole point behind the introduction of this header was to reduce bandwidth by not sending the same data over and over). This improved performance for me by about 3 fold since there were several very complex SQL statements involved in generating a page; for cache misses (that is, the browser needs a fresh page either because its cache is stale or this is its first request) this adds overhead of about 1 millisecond to a page that takes almost 10 milliseconds to parse - I saved on average 85% of my load time!