website load time

Everything You Know About Website Speed Is Wrong: Myth #1: “Load Time is the Most Important Performance Metric”

AJ @ WpFASTER Blog 1 Comment

WpFASTER-Logo

Submits the Following:

Do I have your attention…? Excellent! Because it’s high time to dispel some of the more common myths about website speed — once and for all. Here’s Myth #1 of the series, “Everything You Know About Website Speed Is Wrong”. Let’s bid it a fond farewell and send it back to Prince so they can keep partying like it’s 1999:

Do I have your attention…? Excellent! Because it’s high time to dispel some of the more common myths about website speed — once and for all. Here’s Myth #1 of the series, “Everything You Know About Website Speed Is Wrong”. Let’s bid it a fond farewell and send it back to Prince so they can keep partying like it’s 1999:

MYTH #1: “Load Time is the Most Important Performance Metric”

separator

false


[Thirteen] years ago, onload was a good proxy for the user’s perception of when the page was ready. Back then, pages were mostly HTML and images. JavaScript, CSS, DHTML, and Ajax were less common, as were the delays and blocked rendering they introduce. It wasn’t perfect, but onload was close enough.Steve Souders: Former Head Performance Engineer at Google
Why this idea remains popular is a bit of a mystery, but if I had to venture a guess as to why I’d say it probably has to do with A.) Google not doing a very good job of dispelling it for the masses; B.) popular online ‘speed testing’ tools that give an inordinate amount of attention to load time (for ease of use, maybe?); and, C.) people continuing to read, on some or another ‘authoritative’ blog, insinuations or implications that load time is key, thereby causing a cycle of…well…repeating that it is (the Grapevine Effect, if you will). Which, because we’re all-too-human, then leads to load-time-as-the-most-important-performance-metric being something of a ‘belief’. A belief, that by all appearances, very few people question at all. /Freudian Analysis

The facts are what they are, though. Including the fact that the Earth is round, Sofia Vergara is the most beautiful woman ever to have lived, there is not a food in existence that is not improved by being wrapped in bacon; and, that some of the most basic evidence that load time is (generally speaking) an incidental has been around since at least 2001:



“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).”

The Truth About Download Time by Christine Perfetti & Lori Landesman




When people accomplish what they set out to do on a site, they perceive that site to be fast. […] 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).Christine Perfetti & Lori Landesman: The Truth About Download Time
What exactly is being referenced when most people cite load time is also a mystery (albeit a more minor one) as there are , technically speaking, many “load time” metrics:

  • The loadEvent
  • Fully Loaded
  • (Actual, real, true-blue, definitive) Page Load Time, which most people – whether they are aware of it or not – are not actually referring to when citing the “load time” of some or another website;
  • and, what most people actually are referring to, which is Document Complete.

Regardless of which of these is actually being referenced as regards load time, however, doesn’t actually matter, as the assertion, implication or insinuation that load time is the most important performance metric remains 100% false with any and all of them. The “load time” of your website (an aside: this is the most prominent metric reported by such popular online tools as Pingdom and Gtmetrix) is quite nearly worthless, relative to the other, far more meaningful, user-experience-centered performance metrics that are responsible for how fast your website is perceived to be. These include:

Basically, the speed with which your server responds to a request.
The moment something first displays on the user’s screen. The web page goes from a blank white screen and some sort of visible feedback is presented to the user.
Everything in the user’s device viewport is fully rendered.
The moment the first pixels are ‘painted’ on the user’s screen as reported by the browser itself. This metric is related to, but more important than, Start Render Time which is a synthetic metric.
The “dom” in domContentLoaded stands for Document Object Model. The Document Object Model is a platform- and language-neutral interface that allows programs and scripts to dynamically access and update content, structure and style of documents.

The faster the better.

The time at which a user of your site is able to perform some sort of (‘meaningful’) action, like click a link in your menu.
The Speed Index is the average time at which visible parts of the page are displayed. It is expressed in milliseconds and dependent on size of the view port. The Speed Index is arguably the most important website performance metric in existence as it is a highly accurate means by which to quantify actual, real-world UX, or ‘User Experience’ and how fast a user perceives your site to be. Learn more.



Time to onload is bad performance metric. Modern applications are aiming to deliver […] the progressive rendering experience.”Ilya Grigorik: Web Performance Engineer &
Developer Advocate at Google
Said differently, your site’s load time (and it doesn’t matter which “load time” metric we are referring to) is 8th — if not 9th — in line when it comes to performance metrics importance.

I could here present endless amounts of amassed Internet-garnered data, as well as what we at WpFASTER have accumulated. I could further quote bomb website performance notables all up in ur face. But, simple logic actually bears this out. What is more, common sense does too and does so in the most elegant fashion. 

To illustrate: Things such as your site’s analytics, that ad unit in your site’s footer and any and every image below the visible part of your page are included in all load time metrics. Your users don’t care about these things because they have no impact on their experience of your website until, if applicable, they enter their device’s viewport. It therefore follows that anything outside of the viewport doesn’t matter until the user gets to it. It then of course follows that load time only matters when it negatively affects actual user experience.

To punctuate the point: When’s the last time you cared how long it took a site’s footer Google Maps widget to load…? – because that’s included in load time metrics as well… Right. — you don’t care and never have and neither do your site’s users. Insofar as load time metrics contain these sorts of assets, load time simply does not matter. Same map above the fold? That matters. Same map midway down the page? Better be loaded by the time the user gets to it, but until then it does not matter.



When one optimizes user-experience-centered metrics, one is, 99% of the time and by that fact, optimizing for load time as well. Whereas when optimizing primarily for load time, many of those far more important, user-experience-centered metrics are generally left unoptimized. They shouldn’t be, but they are.”AJ McKay: Managing Partner of WpFASTER
Just like you, your users care about getting done as quickly as possible what they came to a website to do. Ergo, true optimization begins and ends with whether or not your site’s users perceive your website to be fast. Which, as noted on our homepage, is why Google is so adamant about prioritizing the optimization of above-the-fold content and why they so highly favor sites that have implemented Progressive Rendering.

It goes without saying, of course, that if your website’s load time is so long as to prove a hinderance to that most primary goal (getting your site perceived as fast by its users), then your site’s load time is definitely an issue. Having said that, when one optimizes user-experience-centered metrics, one is, 99% of the time and by that fact, optimizing for load time as well. Whereas when optimizing primarily for load time, many of those far more important, user-experience-centered metrics are generally left unoptimized. They shouldn’t be, but they are. Steve Souders sums up the importance of leveraging a user’s perception of speed very nicely in his Ignite presentation, “The Illusion of Speed”, at Velocity 2013:




Onload is not the best metric for measuring website speed […] What we’re after is a metric that captures the user’s perception of when the page is ready.”Steve Souders: Former Head Performance Engineer at Google
The long and short of it, folks, is that you simply must step-up your website speed game and accept that load time is, at best, an incidental performance metric; and, at worst, irrelevant until it is a problem relative to actual, real user experience (UX).

I get it. This stuff is hard and as it evolves rides a constant line of abstraction. It’s easy to plug your URL into one of the more primitive online tools, get that “load time” number and be done with the whole thing. But the truth is that you’re accomplishing very little, if anything, towards achieving what you actually want, which is to improve the experience of your site’s users.

And the bottom line is this: Load time, any load time, really only matters when it’s a user experience problem; and, if you’re not optimizing those user-experience-centered performance metrics that are responsible for how fast your website is perceived to be… you are not optimizing at all.

Be well,
AJ
Managing Partner
WpFASTER

atom small

Stay tuned for Myth #2!

Have a question or a comment? Let us know below!

Comments 1

Leave a Reply

Your email address will not be published. Required fields are marked *