One often overlooked, area ripe for improvement on websites is that of page weight – namely how much data needs to be downloaded by the web browser before the page is rendered. Most web pages will be constructed from a mixture of Javascript, Stylesheets (CSS), Images and HTML. A BBC news article states that the average page ‘weight’ is approaching 1mb
Why does it matter? Well, although it’s tempting to think everyone must have pretty quick >4mbit ADSL, it’s not always the case –
- Mobile users may be on a GPRS (2G) or 3G connection – which is normally far less than 1Mbit/s (3g minimum should be 200Kbit). At this speed our average page would take about 40 seconds to load.
- Some people (often in rural areas) will be limited to around around 512Kb or 1Mbit – due to the long distances between themselves and the nearest telephone exchange (so around about 10 seconds to load).
- If you’re lucky enough to have around a 10Mbit ADSL connection, then the download would take around about 1 second.
We seem to be seeing mobile users accounting for around about 10-20% of the traffic to websites at the moment – and this figure is likely to grow as tablet computing becomes more popular. Having a mobile theme on your website is likely to help with this – so resources are loaded via AJAX (see e.g jQueryMobile)
From a developers point of view, there are a number of things we can do to help reduce the ‘weight’ of a web page – for example :
- Enable compression on textual data being sent back by the web server using deflate or gzip (trading off some CPU time against network bandwidth) (Example below)
- Resize images so they are not being resized in a stylesheet / by the browser – when using PHP, something like the phpimageresize plugin could be used (Example below)
- Ensure static assets have appropriate / correct expiry times/headers to encourage client side caching (or caching by upstream proxy servers) (see mod_expires) (Example below)
- Try and use ‘common’ URLs for JS libraries (e.g. Google’s API hosting) – as there’s a reasonable chance the user will already have the script cached in their browser before visiting your site.
- Compact or minimise stylesheets and javascript resources – removing unnecessary spaces and comments (see e.g. the YUI compressor )
- Delay loading/fetching of Javascript (see e.g. the contentLoader script from jsclasses.org) until after the initial page has loaded.
- Merge multiple resources together (the Google mod_pagespeed Apache plugin can do this) – so rather than your browser making multiple requests to the server for multiple javascript files, it sees only one.
- Appropriate use of AJAX to load content (saving the user from having to download unchanged HTML between ‘pages’).
Server side data compression
If you’re using Apache, enabling the ‘deflate’ module and then having something like the following in a .htaccess file should work well –
AddOutputFilterByType DEFLATE text/css application/x-javascript text/x-component text/html
PHP can also perform the compression for you, but handling the compression through the web server will give better results (more stuff will be compressed).
Image Resizing
If a graphic designer has uploaded an image to the website, and it then gets resized through CSS, your browser is technically downloading more data than it needs to. Instances of this can be easily discovered using the Google PageSpeed tool.
Dynamic resizing of images can be done using the phpImageResize tool (and I’m sure there are many other alternatives) as follows – on the assumption we want to only show a 20px x 20px image:
<img src="<?php echo resize('images/whatever.jpg', array('h' => 20, 'w' => 20, 'scale' => true)); ?>">
For one customer we found correctly resizing the images reduced page ‘weight’ from around about 5mb originally to 1mb (it is a very image heavy news site/blog). Such a drastic reduction will make the site feel ‘snappier’ and more responsive to all users, save on server resources (bandwidth) and allow the server to handle more traffic at once. This should lead to more page impressions and therefore greater advertising revenue.
Expiry Times
Adding something like the following to a ‘.htaccess’ file should work well, assuming Apache as your web server:
ExpiresByType text/css A7200
ExpiresByType application/x-javascript A7200
Which tells the browser to cache the javascript and CSS files for 2 hours after access. Often the expiry value can be far higher – often days, or even years.
It’s also normally useful to turn off eTag support at this point (“FileEtag None” in .htaccess) – to try and stop browsers trying to validate whether their cache is up to date on each request.
Common URLs for JS Libraries
For example, rather than hosting jQuery from your own server (which is probably identical to jQuery on many other servers) you could use e.g.
<script src=”https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js”></script>
Which is both minified and there’s a reasonable chance the end user may already have it cached due to other websites using it. See the Google code site for more information.