If you are using Google PageSpeed Insights to test your site, you’ll see this “avoid enormous network payloads” warning if the total size of your page is more than 1.6MB.
It sounds technical, but this is actually one of the recommendations that you as the site owner have the most control over. Unlike some PageSpeed recommendations, you can fix this one!
Core Web Vitals are the 3 key metrics that Google believes indicate healthy performance for your web site.
Whether you agree with their selection of metrics or not, soon you will not really have a choice.
Unlike their previous PageSpeed metrics, which did not impact ranking at all, Core Web Vitals will eventually be used as a ranking signal.
Today, we’re building on this work and providing an early look at an upcoming Search ranking change that incorporates these page experience metrics. We will introduce a new signal that combines Core Web Vitals with our existing signals for page experience to provide a holistic picture of the quality of a user’s experience on a web page.
https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html
Preload key requests is an “opportunity” that you may see recommended by PageSpeed.
PageSpeed will show you this message when there are necessary files to render (display) your page which are referred to 3 levels deep in your code.
This is the blog post that accompanies a talk I gave at WordCamp Seattle in 2019. You can see the slides here. The video of the talk is up on WordPress.tv
Additionally, the HTTP Archive Web Almanac was published around the same time so I’ve also interspersed some of the insights from that report since they dovetail really nicely.
Providing excellent context for this post, the CMS chapter shows how sites built with a Content Management System (and WordPress sites comprise almost 75% of those in the report) tend to:
Additionally it reported that WordPress sites tend to have slower performance metrics.
Now this is not really the fault of WordPress itself, it’s really due to what we site owners have done.
While it’s possible to build bloated pages and use techniques to make them seem fast, that shouldn’t be the goal. Let’s just build lighter pages to begin with!
Listen, let’s keep it real, PageSpeed Insights is a tool best used by developers. Its intentions are good but it’s not targeted at the average WordPress site owner. Even with the recent introduction of some WordPress-specific messaging, many aspects of the report are too technical to be clearly actionable.
In this guide I’ll try to translate what PageSpeed is talking about and let you know which factors you can control, as a WordPress site owner, and which you can’t.
The basic principles that PageSpeed Insights is trying to communicate are:
These are solid principles but PageSpeed communicates them in somewhat obscure ways.
The Time To First Byte (TTFB), or server response time, of your WordPress site can be an important indicator of performance. It doesn’t represent the whole picture, but a very specific part in the process.
Time to First Byte is a measure of how fast your server responds when someone tries to visit a page on your site. Specifically, it’s measuring how long it takes from the time the browser asks the server for the page, to when the browser receives the first piece of data from the server.
Visitors want sites to feel fast, so the sooner some meaningful content is displayed on the screen, the better. TTFB can influence this – the faster the server responds, the faster content can get to the user.
