April 2012 Newsletter
Last month's newsletter started our review of website speed. This month I am going to show you a tool you can use to evaluate your web performance and provide topics for discussion with your web designers.
If you are still not sure you need a faster website, read this page covering how speed affects bounce rate, pages per visit and other performance metrics:
[Web page no longer available]
Run your home page and a typical interior page through WebPageTest.org - print out or save the results as a pdf for future use. These results are called waterfalls and show the sequence and timing of the html, images and other files being downloaded.
The image below is from a 4specs page (Handrails - 05-7260) with the most images. This page is our slowest pages with lots of text (67,000 bytes, gzipped to 13,000 bytes) and 36 advertiser images plus the 4specs images. Look at the 4specs results as a speed target for your website.
Below is a website I ran through WebPageTest while talking with the marketing manager. I blurred the url to protect the company. I am using this waterfall to show problems I frequently see when looking at advertisers' websites. Note that while the waterfall images are the same width, the time scales are very different.
Here are my observations and thoughts as to why this website is very slow.
1. On the html page, the web server takes around 0.8 seconds to start to serve the first byte, as compared to 0.1 seconds for the 4specs page. I reran this test several times, with the same results each time. I suspect there are 2 reasons for the slowness -
(1) the use of a content management system with a slow database
(2) and heavily loaded server
In comparison, 4specs is on a server with very light loads and the pages are static html. I believe the 4specs html and images are maintained in the server memory cache, and do not require a disc access. I recommended to this manufacturer that they evaluate why the first byte was so slow. I would start by changing the page to a static html page and review changing to a server with much less load.
2. Note that the first image is file #26, starting around 2.4 seconds. The images do not load until all the Cascading Style Sheets (CSS) and Javascript (JS) files are loaded and evaluated.
3. Note the number of CSS files - I count 18 CSS files plus the one that is broken (in red). The first step would be evaluate which CSS information was needed and to combine all the CSS files into one CSS file. Google has a good discussion on this:
https://developers.google.com/speed/docs/insights/mobile
4. Note the number of JS files - I count 5 JS files. I would evaluate what Javascript is actually required on the page and work to combine the Javascript files and then minify the files. This can be a bit tricky, and may take some good code analysis to achieve the needed results. Here are links to additional information:
[listed website no longer works]
https://en.wikipedia.org/wiki/yMinification_(programming)
5. The last step discussed in this newsletter is to use gzip for the HTML, JS and CSS files that remain. A goal for this website would be to reduce the start time for images from 2.4 seconds to 0.5 seconds.
Here is another page that discusses waterfalls and how to use them:
[Web page no longer available]
In future newletters I will discuss ways to reduce the total load time for images.
If you want to discuss your results after running your website through WebPageTest, email me a link for the Webpagetest url and we can review your results on the phone.
Colin
--------------------------------------
Colin Gilboy
Publisher - 4specs
Contact us