For all the developers in our audience, here is what I think is a definitive list of optmisation tips for websites, with a focus on Rails apps. Email me if you think I’ve missed any ( email@example.com ).
With all performance fixes there is a trade-off between getting your site to load quick and making it maintainable. Also, remember not to optimise too early, make sure you know your site works and that you are improving actual bottlenecks rather than wasting time.
- If you’re AJAX request is less than 2k, use GET, it’s quicker. Try cache AJAX responses where possible.
- Don’t scale images in HTML, make sure the image is the correct size on the server. If an image is going to be displayed 100px wide, save it as 100px wide
- Use an External CDN for loading client-side scripts or images available from other sites (e.g. Yahoo YUI libraries or Google-hosted jQuery libaries), refer to them directly rather than storing them locally on your server. This means that users who have visited sites that use the same scripts will already have them cached in their browser.
- When releasing JS and CSS to prod ensure that it is minimised (i.e. remove whitespace, comments etc.) using tools such as http://developer.yahoo.com/yui/compressor/ Some CMS software can do this for you in production, such as Drupal.
- Optimise graphics for web (In Photoshop, Save for Web)
- Use CSS sprites, which involves combining multiple images in to one graphic, and then cropping the image in multiple areas (explained in point 1 here: http://www.leemunroe.com/optimise-website/). By loading only one image from the server, the number of HTTP requests is significantly reduced.
- Gzip what you can if you’re using Apache (http://developer.yahoo.net/blog/archives/2007/07/high_performanc_3.html)
- Try and cache in memory rather than in the file system. This will work if you have a server with plenty of RAM. I was once on a training course where the bloke claimed that if accessing RAM takes 1 second (obviously in reality it is much less) then accessing the equivalent data on disk would take 3 months. Whatever the figure, cutting out the mechanical bottleneck of accessing the disk is certainly going to speed up your load times.
- iPhone specific-tip: keep assets under 25k otherwise they will not be cached on iPhones
- Use indexes based on the where clause of common queries on each table
- Analyse tables regularly. Our tables get analysed and hence re-indexed everynight, so the tables perform better more of the time.
- Use Timed Fragment Caching to simplify caching a page fragement for particular time periods e.g. 1.hour.from.now (rather event-driven expiration e.g. when a new post is added, when a user signs in) - http://www.ruzee.com/blog/2008/07/timed_fragment_cache-on-rails-21
- Cache models using acts_as_cached (http://errtheblog.com/post/27)
- A couple of Ruby tips for good measure: Always use regular expressions over expensive loops. It’s often possible to remove some slow loops all together by restructuring code.
- Avoid dynamic finders like SomeModel.find_by_*, use SomeModel.find_by_sql to query directly instead
- Question the use of helpers i.e. do you really need a form helper for a static form or can you make do with the pain of writing the html once?
- Use eager loading for models with has_many relationships (http://railscasts.com/episodes/22-eager-loading)
- Automatic asset minimisation - http://davetroy.blogspot.com/2007/12/automatic-asset-minimization-and.html
- Use Rails’ excellent Page/Action/SQL caching helpers http://guides.rubyonrails.org/caching_with_rails.html
Use Yslow to identify bottlenecks
- Use firefox add-on Yslow (https://addons.mozilla.org/en-US/firefox/addon/5369)
- It requires Firebug, which if you don’t already have it, is a good tool to have anyway (https://addons.mozilla.org/en-US/firefox/addon/1843)
Do you have any more? Feedback welcome.
If you liked this, why not 'like' us?
We appreciate it!
This post was by Alex, project coordinator at WeMakeWebsites. We are e-commerce and Drupal experts based in Clerkenwell, London.