Google has recently added 2 new Lighthouse engine metrics to the main web metrics analysis: INP and TTFB. These new metrics are now available both in the PageSpeed analyzer and in other services such as WebPageTest.
Why these two new metrics?
The question would rather be why not before, and I explain …
In my opinion have always been missing in PageSpeed web optimization analysis to measure the time to the first byte of information served by the page, a metric that has always existed and moved away from the tool, and on the other hand, some way to measure when all the resources of the page are available and you can interact with them, not just the first (FID).
Until now PageSpeed seemed – strangely – obsessed only with the moment from when the first element of the initially visible part of the document is painted (FCP) to the first interaction (FID), at the first fold (above the fold), but not on the overall behavior of the page.
TTFB – Time To First Byte
The TTFB or time to first byte is already a well-known metric, and it is no more and no less than the time it takes the browser from the time you type a URL and press Enter or click on the URL and it starts to load.
Needless to say that a high TTFB is worse than a low TTFB, the less time it takes to load the first byte of the page the better.
This metric is heavily influenced by redirects, the response time of the DNS server, the SSL certificate and, finally, the web server where the website is hosted, and in fact it was already a metric that affected all the others.
It has always been a very important metric, and now it is reflected in PageSpeed. As I’ve already written in depth about TTFB I encourage you to review this guide on what factors affect it, and how to improve TTFB in your WordPress.
However, to summarize, this would be a good strategy to keep TTFB low:
- Avoid multiple redirects.
- Add the HSTS header to avoid http to https check latency.
- Use HTTP/2 or HTTP/3
- Preload as many resources as possible
- Apply a predictive prefetch if possible
- Contract with a good hosting company
INP – Interaction to Next Paint
The INP or interaction to next paint is a new metric, but for analytics, it is not something that we as users do not take into account when analyzing the browsing experience on a website.
It seems that – finally – Google has realized that the average user spends most of the time browsing all that other 90% of the page that is not the first fold (above the fold), clicking on images, buttons, products, interacting with the various elements of the pages.
Well, now it will also measure these “other” interactions, not only the first one (FID).
Examples of INP would be …
- Time from when the user clicks on a mobile menu until its drop-down items are displayed.
- Time from when the user adds a product to the cart and the page displays the message that it has been added to the cart and can be visited or checkout.
- Time from when the user clicks on the thumbnail of an image gallery and the chosen image is displayed.
And this is across the entire page, not just in the first fold of the page.
Google illustrates with this graph an example of good and bad INP responses…
In the second image, the response (good responsiveness) of the page to user interaction is immediate, and that would be a good INP.
How does Google measure INP?
Now, it turns out that on a page there may be several elements that offer interaction, or none at all, so how does Google display a metric that reflects whether that page has a good or bad INP?
Basically, the measurement is this:
- INP less than 200 ms equals good page responsiveness.
- INP between 200 and 500 ms indicates that responsiveness should be improved.
- INP of more than 500 ms is that the page has poor responsiveness.
And it will be analyzed like this:
- If the page has no interactive elements (buttons, etc.) no INP result is displayed.
- If the page has less than 50 interactive elements, the result of the one with the worst result (worst availability time) is displayed.
- If the page has many interactive elements (more than 50) the result will be the 98th percentile of the availability time.
How can I improve the INP?
The incorporation of the new INP metric, still in testing, introduces a few questions when it comes to applying WPO strategies to our WordPress websites, and not for nothing.
It turns out that, until now, Google was focusing a lot on the first fold, on that first impression of the web pages, and this has led many administrators to apply load optimization techniques specifically focused on that first fold (above the fold), perhaps somehow neglecting the availability of the rest of the resources of the pages.
And is that if you are obsessed with the first content of a page, logically, you will apply optimization techniques that defer all resources that are not necessary for that first content. I am referring to techniques such as:
- Postponing JS loading
- CSS critical path
- Selective loading of CSS and JS
Too conscientious an application of these techniques can cause other interactive resources on the page to simply not work, or take too long to become available, hurting INP metrics.
Does this mean I should switch WPO techniques altogether and start optimizing INP to death?
Neither. To begin with, remember that INP is a metric still in testing, and that because of its interrelationship with other metrics there will be upcoming modifications in the way this and other affected metrics are measured. This also means that for the time being it should not have any influence on positioning factors.
However, the INP is an important metric for your users, so far somewhat underestimated by Google’s web metrics, because remember that your user will want to interact with several elements of your pages, not just the first one, and all of them must work and be available as soon as possible.
This implies that, in addition to not forgetting to offer a great first impression of the optimization of your pages (LCP, FCP, FID, TTFB, CLS and TBT), this should not harm the rest of the page elements (INP), which should be available for the user to interact with them as soon as possible.
And how does this eat into real life, how do I now optimize my pages for an overall experience?
Absolutely right, and as I see it, the point is that you were doing it right so far, you just have to be careful not to neglect the rest of the content on your pages.
- Should you create the critical path CSS? – Yes, but make sure it collects the necessary CSS for all the resources on the page.
- Should I conditionally load CSS and JS? – Yes, but don’t skip loading CSS or JS needed by any interactive resources on the page.
- Should I defer loading JS that blocks display? – Defer yes, but don’t stop loading it when it is needed by the rest of the interactive resources on the page.
The ultimate test to know if you are optimizing a page well for Google’s main web metrics, and a good experience of your users would be:
- The page loads fast and is immediately interactive.
- All the interactive resources of the page work correctly and without waiting.
Best of all, Google PageSpeed now also helps you with that second part, which until now seemed less important for the metrics, but never ceased to be relevant for the overall experience of your users.
