Since April 2010, Google has started taking load time into account when ranking sites, to help in populating results for Google searches (aka SERPs or Search Engine Results Pages). The web community went into uproar with questions such as what is a slow site, how can website speed be improved, what affects website speed, so on and so forth.
The task of optimizing a site’s website speed originally fell into the hands of SEO specialists, as it’s an SEO’s responsibility to improve or ensure a website’s ranking in Google Search results. So SEOs had to get to the bottom of this ranking algorithm change and get technical, fast. Soon SEOs were looking for tools to measure site speed and methods to improve site speed. Finally, Google threw out a lifeline with Page Speed Insights in 2011 and now, even more detailed site speed information can be found within a site’s Webmaster Tools account if you have created one and verified your site. I’m not focusing on those today as there are quite a few guides out there already for them, and the tool I’ll be discussing is really quite simple to use.
What I’ll be focusing on is a tool called WebPageTest.org. The utility of this tool is like an Alienware 14 laptop compared to a Commodore 64. Sure, the Commodore 64 was helpful and important in the industry, but alas, new and better tools have been developed. In the case of WebPageTest.org it not only provides more comprehensive and detailed information, it is also Developer friendly, as in, provides the details a Developer needs to dig into the programmatic elements that are affecting site speed, rather than the blanket recommendations that Page Speed Insights provides. Did I mention it’s free, for any number of sites, and all you need to do is paste in the URL? Interested yet? Great! Let’s continue.
Paste the URL of the site/page you want to test. Start with the homepage of the site and also test some of the popular pages of your site. If you’re not sure what the popular pages of your site are, review the “Landing Pages” section of Google Analytics to see what pages visitors go to first/most often when visiting your site.
Select the browser you want to run the test with and if you’re on a desktop or mobile device. Note that some browsers and devices are inherently slower or faster so you are likely to see variation in speed if you test using different browsers. (So basically, do not be alarmed to see variation in page speed time by browser).
Click “Start Test”. Easy as pie!
Change originating location of test. This option is helpful for sites that receive traffic internationally, overseas mainly. If your site does receive international traffic, test from within the regions from which your site receives said traffic. Note any areas with slower times. Later, the section “CDN”(Content Delivery Network) may be useful for speed improvements for international sites.
Here Comes the Results
You’ll immediately notice the report card form of results.
This report card is a helpful indication of how your site is doing overall (note the score here for MSN.com of 89/100) and specific areas of improvement, such as “cache static content” for which MSN.com received an F. Don’t be too alarmed by a “D” or an “F” in any one area, this isn’t High School! This is just a breakdown of elements that affect overall site speed. Each area may not be relevant for your site (again, use of CDN may not be needed for average sites not expecting overseas visitors). This is more of a guide, if indeed your site speed is slow, giving you insight into areas that can be improved at a bird’s eye level.
Site Speed and the Waterfall
Who doesn’t love a waterfall? Niagara, Angel Falls, Waterfall Showerheads and “Waterfall View” of your site loading in browser – pretty nice stuff. Webpagetest.org gives a waterfall view of your site loading with details along the way and an overview of what was experienced, from redirects to DNS lookup times: no detail is spared! This makes web developers happy.
Page Speed Insights doesn’t provide this level of information, only suggestions about what to fix. Going to a developer with a laundry list of “suggestions” without seeing which aspect is really affecting site speed will likely lead to a much longer “Do Later” list, along with revamping the database and redesigning the site.
What Does the Waterfall Show?
The waterfall shows how each item loads on a page, from the first item to the last and how long it takes to load. For each time it shows various aspects that affect its loading speed – DNS lookup, initial connection, SSL Negotiation, Time to First Byte, etc. If the overall “First Byte” and “Start Render” time are slow (generally considered 3 seconds or longer), viewing how each element loads can give insights into improving this critical first view of the site.
The First Byte time is the time from when the visitor started to navigate to the page until the first bit of the server response arrived. The bulk of this time is usually referred to as “back-end time” and is the amount of time the server spent building the page for the user. DNS lookup time, initial connection time and SSL negotiation often affect the First Byte time.
Start Render Time
As site visitors expect content to at least start loading right away, the Start Render time is critical for the appearance of content and keeping visitors onsite (and not hitting “refresh” 10 times hoping the page will load). The Start Render time for MSN.com is reported as 1.257 seconds, which is great. If this time is 3 seconds or greater, review whether there are multiple 3XX or 4XX responses on content that must be downloaded, large image files, custom fonts and the overall “Content Download” time for the individual items, all of which could be a factor here.
“Keep-Alive Enabled” and “Compression Transfer”
Compression Transfer is usually another easy win, especially text. If you’ve ever tried to “zip” a file to send as an email attachment because it was too large as is, then you’re familiar with this concept. Text files will shrink quite dramatically when compressed (aka “zipped”), although images do not compress quite so readily, so they are detailed in a separate section.
As mentioned in a previous post on site speed improvements, the way a file is saved can impact file size and ultimately site speed, especially on home pages that are mostly images. As outlined in the example below, there are at least three versions of one image that are smaller file sizes, yet no apparent difference in quality of the image. The file size goes from 213K to 25.54K to 11.74K down to just 7.416K by opting to “Save for Web” and reducing the “Quality” to 65. Also, in Webpagetest.org you can get a full list of the images on the page that were tested and view the details, recommended optimization and estimated savings after optimization for each image.
Other Image Best Practices
Use the minimal image size needed for web resolution. For editing photos, programs like Photoshop often offer “Save for Web” options to optimize the images for use on websites by automatically compromising between image compression (via the JPEG format) and minimal file size. If your image editor does not offer such a setting, configure your image compression settings so they look acceptable at 72 pixels per inch (ppi, or sometimes also referred to as dots per inch, or dpi), using the pixels setting as unit measures for width and height. Set the pixel dimension (typically width) to the size you want the image to be on your page. You can often use JPEG compression as high as 70-85% and retain the image quality you want.
Advanced optimization involves further (lossless) compression of JPEG and PNG files.
There is a free web-based tool by Yahoo called Smush.it You can enter an image URL to Smush.it and it will provide the losslessly compressed image. There is also a plug-in for GIMP which is called “Save for Web”. It allows visual adjustment of various image parameters such as quality, number of colors, dimensions, etc to reach optimal file size see http://registry.gimp.org/node/33.
Cache Static Content:
Last, but not least…
Effective use of CDN
CDN stands for “Content Delivery Network”, as in a network that is setup to deliver a webpage’s content (images, text, etc). As each request from the server travels from a visitors computer to wherever-in-the-world the website’s server is, CDNs have servers all over the world that are close to users that serve a web site’s static content from servers close to users. Essentially, this is useful to speed up the delivery of content to a visitor that is far away from the server (as in, overseas) or if the web server is actually overseas from where the majority of visitors are located.
That’s a rundown of the WebPageTest.org tool, the meaning of the results, and most of what you are likely to find. There are a lot of hidden nuggets of information that can be seen by clicking around. My recommendation is to start on a journey of discovery, reviewing each section and noting how the webpage is delivered as a whole before relying on the prominently displayed “Report Card”, because, as mentioned before, sometimes the report card grade does not equate to the largest area of improvement for your site speed. It’s still by far one of the best tools for digging into ways to improve site speed – just get your detective hat on first!