Making CSS Faster With Browser Caching
Recently we have been trying to implement some basic good practices for making our websites as fast as they possibly can be. We feel this is worth while and our target is to have our pages load 0.8 seconds and below.Our index page according to pingdom tools takes 1.3 seconds to load so there is room for improvement and we should be able to get it down a little bit. Although this site speed is perfectly acceptable we want to try and make it as quick as we possibly can.
We can control browser caching by sending the cache-control headers to the user agent to inform it that the item should be cached until a specified time has passed.
cache-control header |
Browser Caching CSS
The idea behind browser caching is any items which are static in terms of content can be saved to local storage allowing quick retrieval if the cached file is required again.An obvious candidate for static content are CSS files as they do not change very much and can be considered almost static.
Before we can take advantage of browser caching our first task was to enable the correct Apache module allowing us to define a expires time header to our responses when the file is a certain mime type.
root@chic:~# a2enmod expires && /etc/init.d/apache2 reload
Now we have enabled the correct module and had Apache reload its configuration we are ready to add some directives to our configuration file. We use a config file for each site located under the sites-available directory but your mileage may vary.
ExpiresActive On
This will enable the expires module and should be placed inside your
<VirtualHost>
tags it does not matter were it goes inside.
ExpiresByType text/css "access plus 1 month”
Adding this directive will make all the CSS files Apache serves have an expiry date of the access date plus a month. The expires by type directive will send a header with the cache-control set to a month in the future.
You can play about with this and change it to a year it depends on how much the style on your site changes. The available options are seconds, minutes, hours, days, weeks, months and years.
For us a month is plenty of time and we should not have to many changes to our external CSS files by then but we can just clear our cache if we make changes although these will only be available to users who do not have it cached.
Caching Icons
Another item we use on our website that is perfect for a long expiry time is our favicon which we have only ever changed a few times in over ten years so we set this one nice and long.
ExpiresByType image/x-icon "access plus 1 year”
Using the above directive will tell Apache to send a cache header which will expire a year in the future. For most websites this directive makes sense because it rarely changes unlike database driven dynamic content.
JavaScript Browser Caching
We cache our JavaScript at only one week because we feel our JavaScript can change quite a bit due to our release cycle. We like to get the software out the door with a minimal feature set then implement the rest as we go on a rolling release cycle.For us this allows the system to evolve through usage and this can allow us to not waste time on unused stuff which might not be realised during initial development.
ExpiresByType application/javascript "access plus 1 year"
Same rules apply to this as it did with the CSS files some websites may not change their JavaScript much so a longer expiry date might be better.
After making all of those changes to the
<VirtualHost>
for our websites we need to reload Apache so it reads the new changes to enable caching.
root@chic:~# /etc/init./apache reload
Conclusion
Now our page load time is down to 0.895 seconds which is a definite improvement over our earlier tests. Testing has shown on average we have a 28% wait time, 8% connection time and 58% receive.We will be attempting to improve our website speed even more and will hopefully be writing a blog posting about it in the coming months.
One last thing, we will be adding a few resource and links pages to this blog this weekend in the hope it might be useful to somebody.
No comments:
Post a Comment