The discussion about speed
Once in a while the discussion surfaces about how important speed is for a website. And as with every discussion, it is multi layered. First some facts:
Speed does have direct impact on SEO and bounce rates. Nobody questions that. However, some say speed is overrated and point to huge pages like YouTube who's lighthouse isn't really that impressive. On the other hand, opening up your dev-tools on a page like amazon gives you a glimpse into the enormous effort put into delivering products above the fold in the shortest amount of time possible. So who is right?
The fanboy effect
If we look behind the arguments of those who say speed shouldn't be overrated, one can not help to come to a certain conclusion: depending on the technology people have bought into, they seem to be more willing to neglect delivery speed. What do I mean by that? Well, let's take Laravel for example. It's slow out of the box and relatively hard to optimize for speed. It's a great framework, of course, but nonetheless doesn't shine in this respect. On the other hand, users of generators like Gatsby cannot emphasize enough how important speed is.
But is it really impossible to serve dynamic content and still outperform the competition?
PHP8 is the fastest interpreted language
Since version 7.2 PHP developers have noticed a speed increase depending on the logic they ran, but the JIT compiler really pushes the boundaries of what's imaginable. Unfortunately, your Laravel app will not spit out responses noticably faster. But it's fast enough, isn't it?
Since relatively recently I strongly disagree: we had insight into data of various e-commerce platforms and one of the metrics we looked into was the relationship between visitors, pageviews and revenue.
The irony
One sidenote right away: the tools that are commonly used to measure success are the worst enemy. Whether it is Google's analytics or Facebook's pixel - these tools have a negative effect not only on speed but additionally on revenue per 1000 visitors. Of course the only other option would be to fly blind or at least reduce tracking, but I wanted to let you know that you should consider that.
The revelation
I want to be clear that the following data might not be applicable for other industries and/or types of websites. The data is based on 3462 US based small to medium sized e-commerce stores with Gmetrix & Google Pagespeed.
| paint loaded above the fold | time to interactive | revenue loss * |
|---|---|---|
| < 1.2 s | < 1.8 s | 0 |
| < 1.7 s | < 2.1 s | .35 |
| < 2.2 s | < 2.9 s | .4 |
| < 3 s | < 3.5 s | 1.2 |
| < 3.5 s | < 4 s | 2.3 |
| < 4 s | < 4.8 s | 7 |
| < 4.5 s | < 5 s | 12.3 |
| < 7 s | < 10 s | 28.2 |
* In percent in comparison to the top 1/10th percentile.
As you can see, the shoppers impatience kicks in right away: even in the super-fast top field differences can be seen, although it might be worth noting that less than 320 shops delivered securely below 2 seconds. More importantly though for us as developers: bringing your client's delivery speed down has measurable results. As you can see, the 4 second mark is the absolute minimum you should go for. I cannot disclose any concrete numbers, but what financial impact this has on some clients over the year can be staggering numbers and a very good argument to invest into modernization.
Top comments (0)