(Note: This technique can be applied anywhere. This article is specifically related to a Symfony 1.4 implementation)
As recommended in the Google Page Speed best practices, static resources should be cached locally in the browser. This means setting a far-future expiration date on filetypes such as .css and .js content. This first step is achieved rather simply by adding something like below to the application’s .htaccess file or virtualhost’s httpd.conf include.
<IfModule mod_expires.c>
Header set cache-control: public
ExpiresActive on
ExpiresDefault "access plus 1 month"
# Other ExpiresBy... declarations here...
# css and javascript
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
</IfModule>
FileETag None
Note the last line above removes ETags, since according to Yahoo ETags are not needed for static content with far-future expiries set1.
The changes above will cause CSS and Javascript files to be cached locally in the browser for 1 month from the first access time, causing future requests to be made without checking against the server for newer versions of these static resources. Though the caching desired is now in place, it’s not perfect since if these static resources are modified in any way, the cached local browser version of these files will not be invalidated.
Currently in the <head> of my application, default stylesheets are added and then all included stylesheets (including those added by the specific action being requested) have their <link ... /> tags constructed and appended to the DOM using the following code
use_stylesheet('main.css');
use_stylesheet('handheld.css', '', array('media' => 'handheld'));
include_autoversioned('stylesheets');
The include_autoversioned() function is where the work is done which invalidates the browsers’ cache. This function is a wrapper of Symfony’s include_stylesheets() and include_javascripts(). I have added a Template.php file to my application’s lib/helpers/ directory which contains the function as shown below.
/**
* Depending on the type of include requested (stylesheets or javascripts), for
* each file already added to the response object, for each file, i.e. /css/base.css,
* replaces it with a string containing the file's mtime, i.e. /css/base.1221534296.css.
*
* @see http://stackoverflow.com/questions/118884/what-is-an-elegant-way-to-force-browsers-to-reload-cached-css-js-files
*
* @param $file The file to be loaded. Must be an absolute path (i.e.
* starting with slash)
*
* @throws InvalidArgumentException when invalid type is requested
*
* @return void (outputs string response directly)
*/
function include_autoversioned($type = 'stylesheets'){
if (!in_array(strtolower($type), array('stylesheets', 'javascripts'))) {
throw new InvalidArgumentException(sprintf("\$type can only be 'stylesheets' or 'javascripts': '%s' was passed", $type));
}
$function = sprintf('get_%s', $type);
$code = $function();
unset($function);
$code = preg_replace_callback('/(href|src)\=\"([^\"]+)\"/', function($matches){
if (strpos($matches[2], '/') !== 0 || !file_exists(sfConfig::get('sf_web_dir') . DIRECTORY_SEPARATOR . $matches[2])) {
$path = $matches[2];
} else {
$mtime = filemtime(sfConfig::get('sf_web_dir') . DIRECTORY_SEPARATOR . $matches[2]);
$path = preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $matches[2]);
}
return str_replace($matches[2], $path, $matches[0]);
}, $code);
echo $code;
}
(Note: The above code requires >= PHP5.3 due to the use of an anonymous function)
Also, again to the application’s .htaccess file or virtualhost’s httpd.conf include, the following must be added above the other RewriteRules that are in place for Symfony applications by default2.
# Cache-busing js and css files
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]
To show what this does, let’s look at the <link ... /> tags generated using Symfony’s get_stylesheets in the <head>
<link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" />
<link rel="stylesheet" type="text/css" media="handheld" href="/css/handheld.css" />
and compare this to the output generated by the new include_autoversioned('stylesheets')
<link rel="stylesheet" type="text/css" media="screen" href="/css/main.1282090705.css" />
<link rel="stylesheet" type="text/css" media="handheld" href="/css/handheld.1282076131.css" />
By modifying the filenames of these static resources by injecting a unix timestamp for the last-modified time of each file, whenever a change is made to one of these files, however small, it will cause the filename of that resource to change, effectively invalidating the local browser’s copy of that file. This guarantees that a browser will maintain a copy of a static resource for as long as can be reasonably expected, while always guaranteeing they immediately receive the latest changes to those resources as soon as they’re published.
The .htaccess section was in part taken from http://github.com/paulirish/html5-boilerplate ↩
Though modified considerably, the cache invalidation was inspired by this stackoverflow answer ↩
After implementing query caching using Doctrine’s Doctrine_Cache_Apc interface in a Symfony application I am working on, when running the application’s functional tests, warnings were returned intermittently in a few places
$ [apc-warning] Potential cache slam averted for key ...
In APC >= 3.0, an apc.slam_defense configuration option was added in attempt to avoid repeated writes to the same APC cache key as might occur under very high traffic. This apc.slam_defense option was later removed due to having been deprecated in favor of apc.write_lock as of APC >= 3.0.11. This is enabled by default, so the first thing I tried in my development environment was disabling this option. A simple test case will still fail though with apc.write_lock disabled.
apc_store('my_key', 1);
apc_store('my_key', 2);
echo apc_fetch('my_key'); // outputs 1, not 2
One of the more recent comments in this PECL ticket for APC offers a patch that can be applied to the latest release of APC before compiling it. This patch re-introduces the previously removed apc.slam_defense option. For my development environment only (since the cache slam warnings thrown in this environment due to my functional tests are irrelevant), I fixed the cache slam warnings by following these steps
php.ini, add the newly recognized apc.slam_defense=0 With apc.slam_defense in place and disabled, the test case above and my application’s functional tests run without any cache slam warnings.
