A Core Web Vitals Primer for TYPO3 Users

|Franzi Töpler
Feature Image for Article A Core Web Vitals Primer for TYPO3 Users

In today’s world of digital content, search engines love fast websites, and slow websites lose visitors. To answer the question, “Is my website fast enough?”, you need to define the words “fast” and “enough”. 

A good rule of thumb is the Doherty Threshold:

Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
—  J. Doherty and Ahrvind J. Thadani

This threshold originates from IBM’s Walter J. Doherty and Ahrvind J. Thadani, who understood that computing time had a business impact. (Find out more in this republication of their paper, The Economic Value of Rapid Response Time.) Efficient performance of your website is a business requirement because a slow website is losing you business.

Displaying a web page in a browser requires a complex rendering process. Any bottlenecks in this delivery chain can severely affect performance. To ensure speedy content delivery, web developers have to optimize many moving parts. But which ones? A carefully crafted set of web page metrics can help identify them.

In this primer, we’ll look at three fundamental metrics of web page performance. You will learn what the three Core Web Vitals are, what aspects they measure, and what results you would want to strive for. Then, we’ll look into ways of improving these metrics with TYPO3 and how to monitor them to maintain a high page performance.

What are Core Web Vitals?

The Web Vitals initiative by Google is a standardized set of metrics to help developers understand how users experience a web page. In May 2020, Google delineated three of these vitals to help developers focus on the metrics that matter most when evaluating site performance — these are called Core Web Vitals. 

Google stipulates the Core Web Vitals metrics and their associated thresholds as Largest Contentful Paint (LCS), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). These deal with delays in page loading and user interaction, and visual stability. Let’s explore each of them in detail.

LCP: Largest Contentful Paint (loading performance)

Most users consider a page ready to be used when almost all of the content on the screen is rendered. Consequently, the Largest Contentful Paint (LCP) metric measures the time from the start of the page load process until the largest block (whether it’s a text block or an image) visible inside the current viewport has finished rendering.

This metric is much more accurate than simply measuring how long the page takes to fully load. 

 A full page load includes the parts of a page that are either outside the viewport as well as parts that don’t contribute to the visible contents, such as scripts that are needed for later interaction. LCP ignores these parts.

What target LCP score should websites strive to reach? Google suggests using three categories for evaluating LCP:

  • A good LCP score is 2.5 seconds or less
  • An LCP between 2.5 and 4.0 seconds is considered as “needs improvement”
  • Anything beyond 4.0 seconds gets tagged as “poor”

INP: Interaction to Next Paint (responsiveness)

After a page has loaded, users expect fast responses when interacting with that page. This is what the Interaction to Next Paint (INP) metric is about. INP collects response times to user interactions (mouse clicks, touchscreen taps, and keystrokes) while a page is open. It reports the longest of these response times and attempts to ignore outliers. 

INP is the successor to First Input Delay (FID) as of March 2024. FID measures the time from a user’s first interaction with a page to the time the browser actually begins processing this event. INP, on the other hand, samples all interactions on a page and is therefore a more reliable indicator of overall responsiveness.

The ideal INP scores are in the same range as the Doherty Threshold (measured in 100s of milliseconds):

  • An INP below 200 ms is good
  • An INP between 200 ms and 500 ms needs improvement
  • An INP above 500 ms is considered poor

CLS: Cumulative Layout Shift (visual stability)

If you have ever tried to click a button and then accidentally clicked an adjacent button because the page content suddenly moved up or down, you know what Cumulative Layout Shift (CLS) is and how annoying it can be. 

The CLS metric measures layout shifts by looking at visible elements that unexpectedly change their position while the page loads. The metric then calculates a score based on how much these elements move and what portion of the viewport the move affects. This score should be as close to zero as possible:

  • A CLS below 0.1 is good
  • A CLS between 0.1 and 0.25 needs improvement
  • Anything above is considered poor

Tip: The Layout Shift GIF Generator is a free and open-source tool that turns layout shifts into an animated GIF for a quick evaluation.

Why care about Core Web Vitals?

The three Core Web Vitals measure very specific and quite technical aspects of a page’s lifetime. What makes these three metrics so special? Why should UX designers and web developers use exactly these metrics for evaluating web page performance?

Google’s Core Web Vitals are a way to quantify key aspects of the user experience. One aspect is “page experience,” which refers to “how users perceive the experience of interacting with a web page.” Google discovered that these three core metrics make almost all the difference when measuring the user experience of a page. 

When you improve a page to make these three metrics score well, you may likely observe increased user engagement, improved user experience and satisfaction, and, ultimately, a positive impact on conversion rates and revenue. 

Another factor to consider is Google Search ranking. If a page’s Core Web Vitals meet the thresholds set by Google, the page is likely to get better rankings. 

In summary, a page with high-scoring Core Web Vitals attracts more visitors and makes them want to stick around for longer. These are two good reasons to take a closer look at these metrics and how to optimize a TYPO3 site for delivering top scores for all three Core Web Vitals. 

How to improve Core Web Vitals in TYPO3

What can designers, developers, and admins of a TYPO3 site do to make the Core Web Vitals skyrocket? Here are some tips and quick wins.

TYPO3 features that help with optimizing Core Web Vitals

TYPO3 comes with handy built-in features that can help rank better in these metrics: caching, support for lazy loading, and asynchronous JavaScript loading.

Caching

Optimal caching is a great step towards high Core Web Vitals scores. TYPO3 has several caching strategies and chooses the best one based on the use case (static, semi-static, or dynamic pages), but the simple rule is that the more cache-friendly your page design is, the better the pages can rank.

Lazy image loading

Particular element types, first and foremost images, can be lazy-loaded after the main content has been rendered. TYPO3 supports lazy loading of images by default for all Fluid-styled content. If you use custom Fluid templates, make sure that your templates use the ‘loading’ attribute like so:

<f:image src="{file.uid}" treatIdAsReference="1" loading="{settings.media.lazyLoading}" />

Automatic image optimization

Image size can significantly affect page load performance. Images added to a page unmodified are often too large and compressed with a low compression ratio. Extensions like b13/picture turn images into the format you need. 

Often neglected: cleaning up unused code

Every web project risks accumulating scripts and CSS configurations that aren’t used anymore. Still, the web server delivers those artifacts to the browsers, where they drag down the performance metrics. Tools like PageSpeed Insights indicate if there is old, unused code to get rid of.

How to monitor Core Web Vitals and overall site performance

Before you can start optimizing your site, you need to collect Core Web Vital metrics first. Luckily, tools like Lighthouse are built into the browser’s console (for Chromium-based browsers) or available as an extension, so you can start measuring right away. And after having optimized your code, you’ll likely want to run regular measurements to ensure the metrics don’t deteriorate.

If you have suboptimal Core Web Vitals measurements but are unsure where to start looking for the culprits, consider running a general performance test with Blackfire to pinpoint the performance bottlenecks at the PHP level. From there, you can work your way through fixing the slowest parts until the desired performance is achieved.

Key Takeaway: Improving on just three metrics can make a big difference

Core Web Vitals are the heartbeat of user experience. They signal issues like slow load times, sluggish interaction, or jumpy layouts that drive visitors away. 

The good news is that Core Web Vitals are measurable and manageable. Identifying the elements causing a low score is the first step. Then, designers, developers, and site admins can make targeted optimizations to improve the user experience.

Neglecting your Core Web Vitals opens the door to losing sales and customers. Take steps to optimize these metrics and create a frictionless site experience for your visitors.

Do you need help identifying quick wins on website optimization, or do you want a full performance analysis?

Get in touch.