Thinking past Page Load Time
In the past, the performance of a website was measured by checking how long it took for an event called ‘window.onload’ to trigger, this measurement was dubbed the “Page Load Time” (PLT) of a website. Five to ten years ago, this was a very good indicator, but websites have evolved since then, so must our mindset when it comes to performance. Most of them have widgets and functionality that is loaded from other servers (social sharing, commenting systems, ads), combine that with more images and things like infinite scroll, the time it takes for the window.onload() event to trigger can vary. We need to start measuring the time in which a user can start to interact with the website. Tools like Webpagetest.org (WPT) have started to offer things like “Speed Index” and “Above the Fold Render Time”, but I’ve noticed very few people in the WordPress ecosystem aware of this new mindset.
The Current Mindset
Judging by tickets, sales inquiries, and forum posts, it’s clear the average developer or owner of a website is making ill-informed decisions, the pattern I see most often is as follows:
- Test website from www.webpagetest.org
- Focus on page load time, but ignore things like Speed Index, Render Time, Page Size
- Repeat step 1 , not notice any progress (page size on first render still hasn’t been reduced)
There are two problems with this approach, the first is the focus on Page Load Time without regard to page size, and the second has to do with the notion of making expensive decisions without collecting sufficient data.
WPT is a very good resource to understand the breakdown of your website and to identify basic issues with it, but it’s not indicative of actual traffic patterns to your website. In my opinion tools like WPT and Pingdom Tools are good for the following
- Start Render and Speed Index
- Total payload (size of page)
- Understand breakdown of payload (css, images, html, js etc)
- Breakdown of payload by domain (how much of the page is loaded from facebook,twitter as opposed to own domain)
The evidence against Page Load Time
Page Load Time (PLT) is a metric of the past. The tools that measure page load time have been updated to measure and report the performance of a modern website. While PLT is one of the metrics that is reported, it is not relevant for modern websites. If you are still focusing on it, or telling your customers to focus on it, you’re wasting time. Here’s what some of the pioneers and experts in the field are saying.
“Consequently, page load time, which has been the de facto metric of the web performance world, is also an increasingly insufficient performance benchmark – we are no longer building pages, we are building dynamic and interactive web applications. Instead of, or in addition to, measuring the time to load each and every resource (PLT), we are now interested in answering application specific questions” – Ilya Grigorik
– Steve Souders
Turns out, Jared Spool and his team at User Interface Engineering had already figured this out in 2001, when they wrote the following paper “The Truth About Download Time”.
“There was still another surprising finding from our study: a strong correlation between perceived download time and whether users successfully completed their tasks on a site. There was, however, no correlation between actual download time and task success, causing us to discard our original hypothesis. It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.
When we looked at the actual download speeds of the sites we tested, we found that there was no correlation between these and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).”
If not Page Load Time, then what?
In my opinion, When it comes to website performance we should focus on how quickly a visitor is able to start interacting with the website. The faster they can start interacting the better.
Unfortunately, there is no agreed upon name for this in the web performance community. It’s been referred to as “Render Time”, “Speed Index”, “Critical Rendering Path”, and since the tools available to us are currently not capable of measuring/detecting this event accurately, we need to get innovative.
Since April of 2012, webpagetest.org has provided testers with two metrics that can help.
Making better informed decisions
These numbers provide a basic idea of how quickly our page may render, but as I said above we shouldn’t commit to major overhauls based on these tests alone. Fortunately, tools are also available that let us monitor what our actual customers/visitors are experiencing.
At ZippyKid, we utilize Real User Monitoring aka RUM, we encourage our customers to do the same. Implementing RUM is very easy, and there are services that fit all budgets and functionality.
- Pingdom RUM Easy to setup and use, good place to start
- Soasta mPulse
- RUM Analytics This is a new company, currently in private beta, looks very promising
What is RUM? And how do we use it?
Think of it as a service that fires off WPT, or Pingdom Tools every time your website gets a pageview. It stores the results in it’s internal database, which you can then query for some interesting reports. Since these reports are based on actual user visits, you get a better idea of how your website is being experienced. The reports can range from basic distribution of page load time, render time (mPulse), to breakdown by platform (desktop, phone, tablet) and state (network, server, browser).
Load Time Distribution with RUM
The following report from Pingdom tells us how the load time was distributed amongst visitors to our website over the past 7 days. We can see that the majority of our visitors were able to load the website in less than five seconds. Based on our business metrics, and performance of our funnel, our time and money may be better spent on something besides performance.
This report is from mPulse by Soasta, I couldn’t figure out how to give me this report for the same time period as Pingdom, but it’s a daily report.
What about Mobile?
Here are some guidelines by Google, that should help you optimize your website for smartphones and tablets.
What should we do for SEO?
This article from the Google Webmaster Central blog, has caused a stir amongst the SEO community. But, they seem to be ignoring the part where Google says speed is one of two hundred factors that Google uses to rank a website, it’s safe to assume that uptime, and relevance of the data on your website is more important. If your website ranks on page 5, reducing page load time alone will not move it to page one.
“While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point.”
I am not aware of anything else from Google that has shown a change in policy. Even the latest Penguin update from Matt Cutts does not mention this.
If you’re worried about SEO follow the quality guidelines provided by Google
I would like to see the discussion regarding website performance move past page load time, towards Render Time and Speed Index. I hope this post was helpful, and can form the basis of a transition towards websites that are truly optimized for user experience.
Note: This post took three weeks to draft, it would not be possible without the editing help of my co-workers, the research and feedback of people like Steve Souders , Ilya Grigorik , and Jared Spool. Thanks to all of them for all their time and insight.
Vid Luther is the CEO and Founder of ZippyKid, the most reliable WordPress Hosting platform for businesses. For more tips, tricks and myth busting information, head over to the ZippyKid blog.