Let’s look at how you can use Lighthouse to find the exact issues you may be dealing with.
Looking at Core Web Vitals in Lighthouse
To open Lighthouse, right-click anywhere on the webpage and select Inspect.
Go to the Lighthouse report and look for the Opportunities it lists. These tell you where you could optimize the speed of the page via development.
Scroll down to find where it says View Original Trace. This will take you to the timeline, where you can find when the Core Web Vitals were logged.
In the screenshot below, you can see FP (first paint), FCP (first contentful paint), and LCP listed in the timings.
Once in the timeline, you can zoom in to see the screenshot. This helps you understand what element Lighthouse marks as the largest.
In this case, it’s a placeholder for a big image. This placeholder is good practice for optimizing LCP.
Below is one more example of looking into LCP. Notice the gap of how long it took for this image to load – resulting in a poor LCP metric.
Again, Lighthouse will show its recommended opportunities and diagnostics about website performance so you can find ways to improve the LCP
This is a good place to save a screenshot for your developer and share the recommendations.
Performance Insights from Semrush
Another place to get ideas is from Semrush.
From the Site Audit tool, the Site Performance report will offer insight on fixing any speed-related issues that were seen in the crawl.
For each issue, you can see exactly where it occurred and receive ideas on how you can improve your LCP metrics.
If you aren’t as tech-savvy as your dev team, it could be difficult to decide what to fix first.
A good way to go is to collect as much specific info as you can and give it to your developers so they can offer a solution from their point of view.
Next, it’s time to look into first input delay – how long it takes before a user interacts with the page.
According to Google’s web.dev article, “Long first input delays typically occur between First Contentful Paint (FCP) and Time to Interactive (TTI).”
In order to measure this via simulation, tools like Semrush and Lighthouse use Total Blocking Time (TBT), a metric recommended by Google as a substitution to FID.
TBT measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) and correlates with FID, capturing issues that affect interactivity and can be obtained in laboratory conditions.
To inspect, we can look at an example of a slow-loading image using the Performance tab in the Dev console. You can click View Original Trace in the Lighthouse report.
Then, switch on the Web Vitals setting to see when Long Tasks take more than 50ms.
These are the instances where FID could be worked on.
Some of Lighthouse’s recommendations that could help with FID include:
- Avoid long tasks.
- Minimize main thread work.
- Keep request counts low and transfer sizes small.
Cumulative Layout Shift is the metric that basically tells you how much the page jumps and shifts around as the result of issues with images, fonts, and dynamic items such as pop-ups.
To find out what part of a page made shifts:
- Go to the Performance tab (click on click View Original Trace in Lighthouse report).
- See the Experience track to find when happened shifts.
- Zoom in and look for Layout shifts to see what part of the page made these shifts during loading.
Some recommendations in Lighthouse that can help deal with layout shifts are to:
While no one can know just how much of an impact Core Web Vitals will have on Google rankings, it’s always better to be prepared and aware of where your webpages can be made faster and provide a better experience.
That’s why we recommend using both Semrush’s Site Audit and Lighthouse to get all of the information you need to provide your dev team with clear instructions to improve these vitals.
Don’t forget that Google itself did emphasize how “great, relevant content” should still be your main priority – with page experience as an added factor in addition to that initial goal.