Join our webinar and get expert insights on how to pass LCP →
Struggling to pass Core Web Vitals?
According to Google:
55.4% of all websites with CrUX data fall short when it comes to meeting the good threshold for all three metrics – LCP, FID, and CLS.
However, passing the CWV assessment by no means is a mission impossible.
In fact, it’s a 3-step process:
And by the end of reading this article, you will be equipped with all the needed knowledge to perform each step successfully.
So read on!
You might've stumbled across this Google statement:
But as the famous saying goes – you can’t improve what you don’t measure.
Or at least that was the situation with measuring user experience before CWV.
Back in 2020, Google introduced Core Web Vitals to provide website owners with a definitive set of benchmarks that directly impact and signify the user experience. They were announced as part of Google's broader initiative to emphasize user-centered metrics in evaluating overall web health.
In their core (pun intended), CWV are a set of performance metrics that shed light on the quality of user experience on a webpage. They encompass three main elements:
LCP, or Largest Contentful Paint, measures the loading performance of a page. It gauges the time it takes for the page's main content to load. An optimal LCP is considered to be under 2.5 seconds.
FID, or First Input Delay, assesses the interactivity and responsiveness of a site. It measures the time from when a user first interacts with your page (like clicking a button) to the moment the browser begins processing that interaction. A good FID score is anything below 100 milliseconds.
CLS, or Cumulative Layout Shift, evaluates the visual stability of a page. It looks at unexpected layout shifts that occur without user input. A commendable CLS score would be less than 0.1.
There’s also a fourth metric that will replace FID in March 2024 – Interaction to Next Paint (INP).
INP records the latency of all interactions throughout the entire page lifecycle. Then, the longest delay from all interactions is recorded as the page’s INP.
The reason why INP will replace FID is that the former introduces a more comprehensive way of assessing page responsiveness, measuring all interactions. In contrast, FID only accounts for the first one. A good INP score is anything below 200 milliseconds.
Although INP does not directly impact your Core Web Vitals assessment (for now), Google has already started flagging INP issues through Search Console.
When discussing Core Web Vitals metrics, Google often refers to the 75th percentile.
This means a site should aim for performance metrics that meet or exceed the recommended thresholds for at least 75% of its page visits.
It's a way to ensure that a majority of user interactions with the site are satisfactory rather than just focusing on average or median values.
The first two steps on your Core Web Vitals optimization journey require you to run some tests and identify possible culprits.
There are several popular tools you can leverage along the way:
Google’s PageSpeed Insights offers both page-specific and origin-wide CWV data for the past 28 days. It also delivers actionable advice for boosting performance.
And at the bottom, you have the Opportunities & Diagnostics widgets, which provide you with a list of issues and the respective metrics that they affect.
The Core Web Vitals report in Search Console includes performance data for individual URLs. This makes it a great option for identifying specific pages that need improvement. Unlike PageSpeed Insights, Search Console reporting includes historical performance data.
Hence, you can track back how impactful your optimizations are and whether or not you’re moving in the right direction.
CrUX gathers real-world user experience data from countless websites, offering key insights on Core Web Vitals based on genuine user interactions.
You can tap into the CrUX dataset in two main ways:
While these methods demand more effort than a quick PageSpeed Insights or GSC check, they present versatile data analysis and visualization options. For instance, BigQuery enables data segmenting and integration with other datasets.
As you already know, LCP gauges the duration required for the primary content element, like an image or a text block, to become visible on a webpage.
Any delay in retrieving the initial HTML document from the server can push the LCP metric into the unfavorable range.
And these are the main culprits:
1. Slow server response times due to budget hosting
Slow server response times, often observed in shared hosting or overcrowded server environments, can notably influence your LCP score.
When server response times lag, the loading of the LCP elements follows suit, creating a cascading effect of delayed content rendering.
Furthermore, a key characteristic of WordPress is its dynamic nature, frequently requiring content to be fetched from a database. In scenarios where this database is hosted on a sluggish server, the retrieval and display of content can be impacted, further affecting the loading time of the biggest element on your page.
Last, relying on budget hosting can negatively affect your Time to First Byte. TTFB measures the interval for the first byte of information to be dispatched from the server to the user's browser. A prolonged TTFB is often a precursor to a delayed LCP.
And, since resources such as CPU and RAM are divided up among multiple websites on shared hosting, your WordPress site might not always get the resources it needs for efficient loading.
Render-blocking resources are those scripts and stylesheets that act as roadblocks, halting a web page from rendering until they've been fully processed.
When a WordPress theme or plugin introduces elements that obstruct rendering, it inherently delays the core content's visibility, leading to websites failing their LCP assessment.
So, when it comes to your WordPress site, less is more.
In other words, striking the right balance between a site's functionality and speed is pivotal for achieving those green Core Web Vitals.
3. Unoptimized images
According to the Web Almanac:
High-resolution images possess substantial file sizes. Without optimization, these bulky files demand more bandwidth, prolonging their download and rendering times.
Additionally, unoptimized images can introduce rendering challenges. When browsers encounter image formats that aren't natively supported or need additional processing, the subsequent decoding can add to the overall rendering time.
A poor CLS score indicates that elements on the page are unexpectedly shifting during the lifespan of a page, which can lead to a frustrating user experience, rage clicks, and higher bounce rates.
Here are the things that cause your page content to jump up and down:
1. Images inserted without set dimension
One often overlooked detail in web development is the specification of image dimensions.
Defining width and height attributes for images isn't just about aesthetic precision; it's a practical measure to maintain layout stability.
Without these attributes, a browser lacks the foresight to allocate the necessary space for the image during the initial render. This might seem inconsequential until the image fully loads.
At this point, if its actual dimensions are larger than the default or assumed space, the image pushes aside or displaces nearby content, leading to abrupt and disruptive layout shifts.
2. Ad placements without reserved space
Do you incorporate dynamic elements like ads, videos, or other embedded content?
You should know that this integration comes with its set of challenges.
A significant one is the unpredictability of the content's dimensions. If you don't proactively reserve space for these elements, the page renders without considering the space they'd occupy.
This becomes problematic when these elements, especially dynamic ads, load. If their actual size exceeds the unallocated or default space, they intrude upon other content, causing it to shift.
3. Unoptimized font delivery
In the pursuit of branding consistency and captivating design, custom fonts have become a staple in web design.
With custom fonts, especially the heavy ones or those fetched from external sources, there's a temporal gap before they're fully loaded and displayed. During this interval, a page might exhibit FOIT, where text remains invisible, or FOUT, where a fallback system font fills in.
When the loaded custom font varies significantly from its fallback counterpart, it reshuffles the text layout. This sudden change can be both disorienting and frustrating for users engrossed in reading or interacting with text elements.
A blocked main thread is a primary culprit for poor FID scores. When there's extensive work queued up on the main thread, user interactions have to wait in line, leading to perceptible delays.
And these are the resources that most commonly block the main thread:
2. Poor resource prioritization
Not all resources loaded on a website have equal significance for the initial rendering or user interactions.
If non-essential resources are prioritized over crucial ones, or if there's no proper prioritization in place, it can cause the main thread to be busy with tasks that slow down the responsiveness of the page.
In other words, effective resource prioritization ensures the browser remains responsive to users by focusing on what's essential first, optimizing the user's experience, and keeping FID scores low.
3. Running excessive amount of third-party scripts
Third-party plugins can significantly impact the responsiveness of your web pages. These plugins, which often come in the form of scripts, analytics tools, advertising networks, or various widgets, can introduce additional processing tasks.
Additionally, bear in mind that third-party scripts often rely on external servers. Any delay in their server response times can also introduce latency.
Considering that INP will replace FID next year, it’s no surprise that the things that negatively impact the current responsiveness metric will also affect the upcoming one.
But there’s one more thing:
1. Having large DOM size
The Document Object Model (DOM) is the backbone for every web page, presenting an HTML document as a structured tree. Each branch of this tree culminates in a node, which houses various objects. These nodes can depict different segments of the document, like elements, textual content, or commentary.
While the DOM is fundamental to a webpage's function, its size can lead to responsiveness issues because:
The larger the DOM, the greater the demand for a browser to swiftly and effectively render a page.
In simpler terms:
For prompt responsiveness to user actions, it's crucial to streamline your DOM to only essential elements.
You might ponder on the definition of "essential." As per Lighthouse's criteria, a DOM size is deemed burdensome if it surpasses 1,400 nodes.
LCP is the metric website owners struggle with the most. That’s why there are multiple optimizations you need to apply:
To guarantee smooth and fast page responsiveness, implement the following optimizations:
To eliminate the possibility of users experiencing unexpected shifts, make sure to:
All optimization techniques mentioned in the FID section will inevitably improve your INP score. On top of that, you should implement the following:
Going through the long list of optimizations could be so overwhelming that it might make one think:
Do I really need to pass the Core Web Vitals assessment? Are they that impactful?
And the truth is – it’s not about the metrics themselves.
Yes, running a PSI test and seeing everything in green is always nice. And yes, they are part of Google’s ranking factors, so that you might see a boost in your SERP position.
But the actual value comes from the fact that passing your CWV directly translates into you providing a top-notch user experience.
And this leads to real-world results like:
So, going back to the questions, we would say passing your Core Web Vitals is crucial.
But we would also agree that it’s not easy to deal with all the optimizations.
That’s why we created NitroPack.
NitroPack is a lightweight web performance solution that powers up more than 180,000 websites globally, allowing them to achieve excellent Core Web Vitals, performance scores, and user experience.
Thanks to its 35+ built-in page speed optimization features, NitroPack is the leader in Core Web Vitals optimization:
And the best part is – you can set up NitroPack in 3 minutes. No technical skills or coding required. Simply install the plugin, connect it to your website, and see your performance issues getting fixed.
Niko has 5+ years of experience turning those “it’s too technical for me” topics into “I can’t believe I get it” content pieces. He specializes in dissecting nuanced topics like Core Web Vitals, web performance metrics, and site speed optimization techniques. When he’s taking a breather from researching his next content piece, you’ll find him deep into the latest performance news.