The Web Almanac by HTTP Archive is a free, open-source collaborations featuring input from over 80 contributors. It is one of the most complete “state of the web” reports currently available. Offering 20 chapters with insights into Page Content, User Experience, Content Publishing, and Content Distribution, it can also be overwhelming, so we’ll be summarizing the web performance section in an easy-to-understand manner.
We’ll be diving into Chapter 7 – Performance. One of the biggest takeaways from this information is that the Web Almanac places a great importance of what the user actually experiences. While it’s important to check various speed metrics, the Web Almanac uses data from the Chome UX Report which focuses on how Chrome users actually experience the web.
First Contentful Paint
The first metric that analyzed was First Contenful Paint (FCP). This is the time visitors spend waiting for the page to display something useful. Again, this is important because it measures something that the user is experiencing, rather than scripts loading in the background that the user never notices.
In the below image, ‘fast’ websites are those with a FCP consistently below 1 second. Conversely, ‘slow’ websites are consistently slower that 3 seconds.
The results show that only 13% of the websites in this study are considered fast. 20% of sites are considered slow. Obviously this means that there is a ton of work to be done going into 2020 for web performance.
As we mentioned in our article Average Page Load Times for 2020, mobile page speed is a huge deal going forward. To this end, we can also look at FCP by device.
This shows 17% of websites have fast FCP for desktop users, with only 11% for mobile users. There are obviously other factors at play, such as mobile data being slower than the typical home wifi. However, this still illustrates the need for mobile website design and optimization, as the majority of visitors are coming from mobile devices.
Time To First Byte
As we’ve covered before, TTFB is the amount of time between the user navigating to a URL and when the browser receives the first byte of information. It can also be described as server delay.
Past a certain point, if you have a slow enough TTFB, you can’t possibly have a fast first contentful paint. Time to first byte is a blocker for all other metrics that follow it. Because of that, this is one of the most important metrics to measure. The results…
… aren’t good. Only 2% of the websites in the pool had a TTFB under 0.2 seconds, which is considered fast. A whopping 42% were slow (over 1 second). This was one of the more shocking areas of the study. There is obviously a huge amount of work that needs to be done here concerning web performance. TTFB is typically reduced via server-side optimizations, such as enabling caching and database indexes. The hosting plan you select also plays a big role here. Therefore, it’s imperative that we make sure we have everything optimized for this metric.
First Input Delay
The last metric that was looking at the Web Almanac was First Input Delay (FID). This metric is the time from a visitors first interaction with the page, until the browser is ready to process that event. If you’ve ever had a page that seemed to load quickly, but then lagged and refused to register that you were clicking on the UI, then that website had a bad FID.
Per Google’s Page Speed Insights, a fast First Input Delay is below 100ms. A slow FID on the other hand, is more than 300ms.
Finally, some positive news! Only 15% of websites exhibit a slow FID. This makes sense, as we tend to experience way more sites that are slow to display anything, rather than display an unusable site.
It’s still a useful metric to study however. FID is different than many of the metrics we look at because it is an interactivity metric. It ties in closely with another metric we’ve looked at, Time-To-Interactive, but is useful because it shows the actual delay that your user is experiencing.
While not a page speed metric, keeping track of our page weight is an essential part of web performance. This is actually detailed in a separate chapter of the Web Almanac, but it’s important to touch on.
Page weight has recently become an area that is overlooked, thanks to high speed internet and powerful mobile devices. However, this is a mistake, as it ignores your users that don’t have those luxuries. In addition, huge pages tax data-limits and batteries, especially for mobile users.
Google actually led a machine learning study analysing the effects of bigger, complex pages. The results showed a very interesting correlation between the elements on a page and the conversion rate of that page. Specifically, converting pages had 38% fewer images on average than those that didn’t convert.
So to recap, huge pages are a strain on even our highest bandwidth users, and lead to lower conversion rates! Sure makes lighter, nimbler pages seem like a no-brainer.
As we’ve said repeatedly, no one metric paints the entire picture when it comes to measuring your sites speed. From the graphs above, we can see how a metric like TTFB can effect every metric that comes after it if it’s slow enough. That’s why it’s so important to do the following:
- Measure your sites speed long term. Using a service like MachMetrics can help with that.
- Check multiple site seed metrics to make sure that you have the entire picture of your sites performance.
- Think about how your websites actual users are experiencing your site and how you can improve that interaction.
It’s very apparent from the data presented in the Web Almanac that there is a ton of work to be done in web performance. Using these new metrics you can measure your own site next to the data presented here and come up with a plan to improve. Every little bit helps. In addition to the Web Almanac averages, you can compare your site to the Average Page Load Times for 2020. Let us know where you stand below!
Are you using Speedy Site?
Website speed optimization with speedy.site ensures your WordPress site is loading fast throughout the day, around the world, and on various devices as well as passing Google's code web vitals.