Get a perfect Largest Contentful Paint (LCP) time with a single line of code

A hack that tricks browsers into thinking LCP is much lower

James Koshigoe, Web Performance Consultant
February 6, 2020

As Google’s Core Web Vitals initiative will be soon be affecting websites in search rankings starting mid-June of 2021, many websites are scrambling to fix the 3 metrics that are considered part of the Core Web Vitals: Cumulative Layout Shift (CLS), First Input Delay (FID), and Largest Contentful Paint (LCP). Websites will soon be penalized in Google's search rankings for poor performance in any of these 3 metrics.


Since we work with a lot of Shopify websites, DevisedLabs has spent a lot of time learning about best practices to fine tune these metrics for Shopify websites, which we’ve shared previously in this blog post: Improving Core Web Vitals for Shopify Sites 


But during our continuous process of researching how to maximize the performance of websites, we’ve stumbled upon a little hack to instantaneously improve your LCP metric with a single line of code.


We’re calling this our Very Large Image™ hack (or VLI hack for short, for those who have a thing for acronyms).

Here's the results from a webpage we tested with very poor performance adding our VLI hack. These results come from Google's web performing testing tool, PageSpeed Insights:

Before our VLI hack


After our VLI hack

Without burying the lede, the following code is all you need to get the lowest LCP:


<!-- DevisedLabs Very Large Image LCP Hack --><img width="99999" height="99999" style="pointer-events: none; position: absolute; top: 0; left: 0; width: 99vw; height: 99vh; max-width: 99vw; max-height: 99vh;"  src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSI5OTk5OXB4IiBoZWlnaHQ9Ijk5OTk5cHgiIHZpZXdCb3g9IjAgMCA5OTk5OSA5OTk5OSIgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj48ZyBzdHJva2U9Im5vbmUiIGZpbGw9Im5vbmUiIGZpbGwtb3BhY2l0eT0iMCI+PHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9Ijk5OTk5IiBoZWlnaHQ9Ijk5OTk5Ij48L3JlY3Q+IDwvZz4gPC9zdmc+">



If this is all you came here for, well that’s it. Insert that right at the start of your <body> or even at the top of your <head> tag (yes this works) and you should be good to go. You can verify it's working by running the page you installed it on in PageSpeed Insights.


But honestly, you probably don’t want to rely on this. Instead, it would be better to actually work on the underlying issues that might be causing web performance issues on your website because actual visitors are impacted by this. If you need help with that, we’re experts in web performance and would be glad to help. Scroll to the bottom to learn more about what we do.


The point of this blog post is to dive into why this works, and maybe even bring this hack to browser vendors' attention so they can fix it. Since after all, improving web performance for real users should be the goal.


So why does this work?

Before we start discussing the finer details of this code, let’s back up and explain what Largest Contentful Paint is and how it’s measured first.


The simple definition of Largest Contentful Paint is that it’s a measurement of how long it takes to display the largest content on the screen. But the simple definition is not enough. There’s a lot of nuance that goes into this, and how it’s measured will depend on what you’re using to measure it. For this blog post, we will be discussing how Chrome measures LCP.


Here’s how LCP is actually measured by Chrome:


  • Chrome defines large content as any large images or text essentially. For example, a product gallery image or heading text.
  • At the start of the page load, Chrome begins a timer that will be used to track the time it takes to see the largest content.
  • Chrome shows (paints) content on the screen in waves (as it arrives in the browser or as things on the page make changes to the DOM, CSS, etc.). In each wave, Chrome looks for the largest content visible in the above-the-fold region.
  • When it finds content larger than it has previously, it notes how long it took to see it from when it began timing.
  • Once the user starts interacting with the page, the last reported largest contentful paint is the Largest Contentful Paint time.


You can find more information about how Largest Contentful Paint is tracked in this helpful Web.dev article on the subject.


Our hack ensures that we show the largest thing on the visitor’s screen as early as possible and thus Chrome ignores all other content that comes after.


Now that we understand how the LCP algorithm works, let’s discuss how our code works.

How does the code work?

Our single line of code creates a transparent square image that has the dimensions of 99999x99999 px. We assume 99999x99999 px is going to be larger than most things on the screen, but this number is chosen arbitrarily and could be much larger. The actual image itself is an SVG image that has been embedded inline with a Base64 transformation. Here’s the code of the SVG before it was transformed:


<?xml version="1.0" encoding="UTF-8"?>
<svg width="99999px" height="99999px" viewBox="0 0 99999 99999" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <g stroke="none" fill="none" fill-opacity="0">
        <rect x="0" y="0" width="99999" height="99999"></rect>
    </g>
</svg>



Once we have our Very Large Image, we position it at the top of the page using absolute positioning and give it almost full screen dimensions. It floats over the content and isn’t seen since it’s transparent and cannot be interacted with since we’ve turned off pointer events on it. Why almost full screen dimensions instead of full screen dimensions you ask? In our testing, Chrome ignores anything that’s full screen or larger when tracking the LCP. Thus we've specified the image should be 99vw by 99vh in the image CSS.


Note that it doesn’t matter if this image overlays the content or if the content sits on top of this image. Even if the Very Large Image is fully obscured by content, as long as it has full opacity, Chrome will still count this as the largest content (very naughty of you Chrome!)


What matters is that Chrome sees that this image is the largest thing on the page, even though its dimensions are constrained to 99vw by 99vh. You read that correctly, Chrome doesn’t care that this image has been resized to fit the screen. It’s only looking at the actual pixel dimensions of the image itself. So even if there was something else on the page that competes with the image in terms of width and height (unlikely anyway), this image will still likely win the algorithm race because it has the largest pixel dimensions (naughty again Chrome! you’re being a very bad browser!)


Here’s the full rundown of what happens during a page load with our snippet of code:


  1. The body content starts to be parsed and loaded
  2. Our Very Large Image is parsed, rendered and painted on the page
  3. Chrome instantly recognizes this as the largest content because of the image dimensions
  4. Other content loads after, but has smaller dimensions so Chrome ignores everything else
  5. At the end of the page load, since our Very Large Image was still the largest thing painted, Google reports the time it was painted at (very early) and claims our website has a very low LCP


That’s it in a nutshell. I would love to see a solution to this issue from browser makers since this hack will be very easily abused. Why will it be abused? Because once again, Google, the search engine that controls 90% of web searches, has decided that Largest Contentful Paint will count against the search ranking of websites if it’s not in Google’s desired range starting in May. And this hack is very easy to add to every website. That gives a lot of incentive for website owners to play games with this and other Core Web Vital metrics just like every other SEO hack. I’m sure this is just the beginning of many cat and mouse games with Core Web Vitals metrics.


I'd like to wrap up by saying as a web performance consultant who has seen how good web performance makes users much happier, I very much applaud Google for making web performance a more important matter. And hopefully this hack will be fixed so real performance issues can be given attention.


If you're an ecommerce brand that cares about making your shoppers and Google happy with better website performance, we’ve built incredibly powerful tools to audit, monitor, and fix web performance issues. We’re experts in making ecommerce websites load blazingly fast. Get in touch with us below if you need help.

Get a free site speed evaluation by our experts

We help ecommerce brands conquer their site speed so they can increase sales and improve their SEO. We'll provide you with a free site speed evaluation by one of our experts so you can take the right steps to make your site faster than ever.

Get Started