Clock Blog

A School Report: Optimisation...

Posted on Monday, 4 April 2011 @ 17:38 GMT in tech-blogs by Robert Arnold

Using Google Page SpeedA couple of useful tools that we use for checking page speed (and optimisation of) are 'YSlow' and 'Google Labs: Google Page Speed'.

To run through some of the nuances and discussions we have internally, I thought it might be a nice exercise to blog about the ones I discovered for our very own blog, which happens to be using the WordPress system (in this version of the site).

Impressively WP/we scored an overall Page Speed Score of 93 (out of 100), and no high or medium priority recommendations were raised.

The following items were raised as low priorities:

  • Leverage browser caching
  • Defer parsing of JavaScript
  • Minify CSS
  • Minify JavaScript
  • Minify HTML
  • Remove query strings from static resources
  • Specify a Vary: Accept-Encoding header

Leverage browser caching

So beginning with 'Leverage browser caching'. The feedback states that

"Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network."

GPS (which turns out is a terrible acronym for the Google Page Speed site!) listed a few different files that aren't being cached by the browser, one of which was: http://blog.clock.co.uk/.../fradmcn-webfont.svg

With the assistance of Mike Cronnelly - we checked the virtual host, specifically looking at the mod_expires settings and we had:

ExpiresActive On
ExpiresByType text/plain "modification plus 5 year"
ExpiresByType image/png "modification plus 5 year"
ExpiresByType image/gif "modification plus 5 year"
ExpiresByType image/jpeg "modification plus 5 year"
ExpiresByType image/pjpeg "modification plus 5 year"
ExpiresByType text/css "modification plus 5 year"
ExpiresByType application/json "modification plus 5 year"
ExpiresByType application/x-javascript "modification plus 5 year"
ExpiresByType application/javascript "modification plus 5 year"
ExpiresByType image/x-icon "modification plus 5 year"
ExpiresByType application/x-shockwave-flash "modification plus 5 year"
We happen to use resource versioning to take advantage of being able to cache for such a long period. So in other words we usually append version numbers to  images etc so that only on deployment does the browser re-request the same (updated) file, i.e. logo.gif?v=@VERSION-NUMBER@ becomes logo.gif?v=1.0.3 As you can see we didn't have a rule for svg files, so we now have a to-do item to revisit each site's caching criteria. A win for all sites - not just the blog. Teachers grade: B Teachers comment: Good effort, try that little bit harder

Defer parsing of JavaScript

We are going to have to take a slap on the wrists for this one, usually we would - as recommended, add JavaScript to the bottom of the page - however, due to WP set-up - the JS to include jQuery is in the header - a big no-no... there happens to be a couple of workarounds (that our very own Ben G knows of) but we have been lazy thus far. We consider ourselves told off. Teachers grade: D Teachers comment: See me after class

Minify CSS & JS

Usually our deployments handle the minification of CSS, as obviously for code maintenance point of view, it can't be minimised until the last thing... however, as discussed we are using the WordPress system, so this is something we have ignored for the blog site - we could of course run the CSS include through a script that minifies it. We are usually pretty good at 'minifying' code where appropriate - so no real new learnings here, but obviously a reminder to keep on top of it. Teachers grade: A Teachers comment: Well done.

Minify HTML

Ah, this one actually stopped and made me think for a while and do some checks. The learning would be that our deployments do not minify inline JavaScript nor CSS - when they perhaps should, however, from experience I know that we do not as a rule - write inline CSS, and also when JS does happen to be coded inline - it should just call a function included in an external JS file which *would* be minimised. Also, we don't actually minify the actual HTML, one for our internal radar. Teachers grade: B+ Teachers comment: You understand the fundamentals, now just make sure you follow through in your work

Remove query strings from static resources

Argh! as discussed, we utilise resource versioning - however, this is now raised as an issue by GPS - as:
Resources with a "?" in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL.
This raised some nice debate within clock, as we feel that by moving the version number parameter from the end of the file path (i.e. logo.gif?v=@VERSION-NUMBER@) to something like: logo-@VERSION-NUMBER@.gif or perhaps /image/@VERSION-NUMBER@/logo.gif We'd then simply be referencing a different file. But this does mean that our efforts to version resources and thus cache items, is actually bypassing a useful caching process implemented by large companies (proxy cache servers such as 'Squid'). A few more discussion about this I feel!! Teachers grade: ? Teachers comment: I might have to think about this too!

Specify a Vary: Accept-Encoding header

A new one on me:
The following publicly cacheable, compressible resources should have a Vary: Accept-Encoding header.
A quick Google search for the rationale shows:
Bugs in some public proxies may lead to compressed versions of your resources being served to users that don't support compression. Specifying the Vary: Accept-Encoding header instructs the proxy to store both a compressed and uncompressed version of the resource.
I am not convinced that coding for bugs in proxies is a good tip - but further reading shows:
The mod_deflate module sends a Vary: Accept-Encoding HTTP response header to alert proxies that a cached response should be sent only to clients that send the appropriate Accept-Encoding request header. This prevents compressed content from being sent to a client that will not understand it.
Usually mod_deflate is used for our sites: 
<Location /resource/>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/json ...
</Location>

so it may be that we just haven't set in our conf correctly for the blog.

Teachers grade: B Teachers comment: Please use your sound knowledge across all projects.

That's all for now folks, maybe some more findings later on...

Big thanks to Mike Cronnelly, Ben Gourley, Jack Brewer and Tom Smith for their input.

blog comments powered by Disqus