No tables here - web standards and performance

To content | To menu | To search

Monday 26 April 2010

Zoompf - another performance tool

By Alex on Monday 26 April 2010, 12:15

I tried running the site through Zoompf and found the resulting report to have predictable results given the issues that we already know about.

What was useful from it though was the scoring of defects by impact and ease of fix. This can then guide you towards the 'low hanging fruit', in this case:

  • Turn compression on for favicon.ico
  • Zoompf taking issue with an empty robots.txt
  • Images without caching information - which should really be the next thing on the 'to-do' list
  • Javascript without caching information
  • HTML files that could be minified - ie. remove white space that improves readability but increases file size
  • Style sheets without caching information - I'm starting to see a pattern here, caching is important
  • Unoptimised images, either GIF with unused information or JPG with excessive quality.

So yes, there is still a fair bit of work to do

one comment no trackback

Thursday 15 April 2010

An easy gain - gzip text files

By Alex on Thursday 15 April 2010, 14:31

The first thing that can be done is to compress any text files as they travel from the server to the browser. This costs a little CPU at the server end but the reduced size of files and hence time to transfer the file make it worth while.

Turning it on under Cpanel

  • Look under Software / Services, there should be an entry for Optimize website. If there isn't you'll need to speak with your hosting company.

Go to optimise website

  • Change the setting to "Compress the specified MIME types" and list the Mime types for the resources you want to compress. If unsure try compressing them offline and check the results. As a general rule images don't compress well so in this case I chose "text/html text/css application/javascript" which catches all web pages, style sheets and scripts.

Did the results improve?

Yes they did. The results of a test from webpagetest.org using New Zealand as the test location:

  • Time to start of rendering - first view - 1.314s (baseline 1.455s)
  • Time to page complete - first view - 2.977s (baseline 3.268s)
  • Bandwidth - first view - 255KB (baseline 284 KB)
  • Time to start of rendering - repeat view - 0.601s (baseline 0.581s)
  • Time to page complete - repeat view - 1.312s (baseline 1.345s)
  • Bandwidth - repeat view - 3 KB unchanged

Under Key Optimisations we now get an "A" grade for compress images.

Note that the repeat view numbers are unchanged. In the repeat view the page is rendered again, but uses cached resources so as transfer is unaffected we would expect no difference. Still the first page view is improved by 10% and our bandwidth is reduced by 10%, Not bad for a simple tick a box change!

no comment no trackback

Wednesday 14 April 2010

The numbers - baseline

By Alex on Wednesday 14 April 2010, 16:50

The results of a test from webpagetest.org using New Zealand as the test location.

  • Time to start of rendering - first view - 1.455s
  • Time to page complete - first view - 3.268s
  • Bandwidth - first view - 284 KB
  • Time to start of rendering - first view - 0.581s
  • Time to page complete - first view - 1.345s
  • Bandwidth - first view - 3 KB

Key Optimisations

  • Enable keep-alive - A grade - 100%
  • Compress Text - F grade - 30% (Gzip Text)
  • Compress Images- A grade - 100%
  • Cache static content - F grade - 0%
  • Combine js and css files - A grade - 95%
  • Use a CDN - F grade - 0%

Other Optimisations measured

  • Minify JS - 68%
  • Cookies - 100%
  • No Etags - 0%

YSlow results

These were much the same with an overall performance score of 75 - C Grade (Ruleset applied: YSlow(V2)). The sub-scores that weren't A were:

  • F - Use a Content Delivery Network (CDN)
  • F - Add Expires headers
  • E - Compress components with gzip
  • F - Configure entity tags (ETags)

Pagespeed results

PageSpeed gave a score of 82/100. Items with red crosses were:

  • Leverage browser caching
  • Minimise JavaScript
  • Serve scaled images

Items with yellow triangles were

  • Combine external CSS
  • Parrallelize downloads across hostnames
  • Use efficient CSS selectors

The numbers - control page

The results of a test from webpagetest.org using New Zealand as the test location.

  • Time to start of rendering - first view - 0.665s
  • Time to page complete - first view - 3.131s
  • Bandwidth - first view - 418 KB
  • Time to start of rendering - first view - 0.413s
  • Time to page complete - first view - 1.517s
  • Bandwidth - first view - 4 KB

As this is the control I won't look at the other tests or suggested optimisations.

For download and comparison - the pages and their resources (660KB zip file).

no comment no trackback

Task one - improving an existing website.

By Alex on Wednesday 14 April 2010, 16:31

A very good friend is the webmaster for www.samhs.org.au and the technology used for it is often the subject of conversation between us. At the end of last month the bandwidth was exceeded for this site and it was unavailable for a few days. There are two solutions:

  • Buy more bandwidth
  • Reduce the bandwidth requirements

For the moment I will attempt the latter, this should save a few pennies but at the same time give a better visitor experience as there should be less bandwidth used, along with faster loading times. It is probably also of more importance now as Google has announced that they will consider page loading times as part of their ranking. \

Approach to be used

Two pages that receive the most hits and generate the most bandwidth have been chosen:

I will baseline both pages and use diagnostics on the first and apply this to both.

Tools to be used

Measures to be used

  • Total bandwidth - first page load
  • Total bandwidth - second page load
  • Total time to render page
  • Time till page starts rendering

no comment no trackback