Google Title Rewrites Impact On Core Web Vitals (CWV)

In August 2021, Google released an update, describing how it rewrites titles in the search results. At the time, I was super annoyed at this, and I still think it’s highly presumptuous of Google to assume that it knows better than us what we want to convey. However, there’s not much I can do but accept it. However, I’ve discovered a curious connection between title rewrites and the Core Web Vitals metric that you might not have considered.

How Title Rewrites Can Affect your LCP Times

The LCP or Largest Contentful Paint metric measures the time it takes for the largest visible element on your page to load when a user visits your site. In a lot of situations, this is the heading, so it’s not too big a deal. But often, the biggest visible element is the image. So you want your above-the-fold images to be as compressed as possible.

Lazy Image Loading Makes LCP Times Worse

I love lazy loading images. What’s not to like? Your visitor doesn’t have to wait for everything to download and can start reading content right away. Given that images are often the largest component of a web page, this makes perfect sense.

However, lazy loading is a problem for LCP because it appears only after the entire page has loaded, and is often above the 2.5-second threshold by Google’s standards. Even if your images are well compressed and small, it doesn’t matter because the browser doesn’t begin to display them until later.

Some tools solve this problem by disabling lazy loading for the first visible image on the page. This way, the LCP times are short because the user sees the first image instantly.

Table of Contents Can Cause LCP Problems

The problem arises when Google rewrites your titles and links a sub-heading of a page. Then when the page loads, the user is scrolled directly to the sub-heading, which means that any lazy-loaded image will take a long time to load – possibly more than 2.5 seconds, which would end up ruining your LCP metrics.

So even if your tool disables lazy loading for the first image, it won’t matter if the user is immediately redirected to a sub-heading on your page, and then whichever images happen to be in the viewport at the time will lazy-load, thereby increasing the page-load speed.

There’s No Perfect Solution to This

So far, I haven’t found a solution to this problem. My website WP-Tweaks.com has plenty of articles with a Table of Content block, and so users frequently land on my sub-headings. Most of the time, it’s just another heading that is the largest element, so it doesn’t matter. But there are some popular headings with images just beneath or above them, that often contribute the most to my LCP times.

For these situations, there’s nothing I can do other than reduce the size of the image as much as I can. There is a facility for me to disable lazy image loading on a case-by-case basis, but I don’t’ want to go down this path.

Google Needs to Address this Problem

I feel that this is Google’s problem – not ours. It’s not my decision to link users to a specific sub-heading on the page. The intended user experience is for them to land on the top of my page and scroll down. If Google chooses to send them elsewhere, then I can hardly be blamed for the user experience.

One solution might be to use a “placeholder” image when the page loads, and then fill in the images one by one as the browser loads them. But this seems to be overkill for what shouldn’t be my problem in the first place. Luckily, it hasn’t had a huge impact on my LCP times yet. If that changes, I might be motivated to seek a different solution in the future.