Framehole: PageSpeed 6.0 loophole for easy perfect score

Every good web developer knows that Google's PageSpeed Insights and the open source Lighthouse used behind the scenes are the most state-of-the-art tools to help identify the relative performance of a website. They also offer key insights into what changes you can make to improve this perceived speed. PageSpeed has become the gold standard measure of fast and slow on the web.

It doesn't hurt that Google themselves are now tracking this PageSpeed score of each website and using it as one of the many inputs to determine who gets to the top of the search results, and who is exiled to the purgatory of page 10.

There is a whole industry and many millions of dollars changing hands just to optimize and improve this score in hopes of getting closer to the unattainable perfect score of 100. The newest release of PageSpeed/Lighthouse 6.0 includes a new set of favored metrics for developers everywhere to optimize for. These new metrics are: Largest Contentful Paint(LCP), Cumulative Layout Shift(CLS), and Total Blocking Time(TBT). Google has an entire article explaining these new "Web Vitals" which does an excellent job detailing the nitty gritty of how they are measured.

With this new release, it's a brand-new opportunity for the web performance industry to sell more services as websites now need fresh and different changes in pursuit of that top score. Well, no need to spend a dime, I'll show you a simple change that immediately takes you from even the depths of 60 score hell, all the way up to 100 score heaven.

TLDR: PageSpeed no longer accounts for speed impacts of 3rd party embeds like YouTube and Ads

If you just want the meat of it, the answer is that Google's latest changes put a heavy weighting on Largest Contentful Paint. This is the measurement of how long it takes for the largest element on screen to appear when loading a website. It's a good proxy for a user's perception of load speed. The problem is that Largest Contentful Paint doesn't consider any embedded content even if that content technically qualifies as the largest element above the fold.

Without speculating on motivations for not surfacing the performance impact of 3rd party embedded content like YouTube videos and large advertising embeds, I would simply say that it will incentivize people to make the wrong changes to improve speed and will move the web backwards.

As an example, that would seem preposterous, although not unlikely given how important PageSpeed score has become. We improve a website's PageSpeed score from 60 all the way to 100, just by iframing the original slow version of the website. The quick commands just to confirm the results are here but read on below to see how a user optimizing their score progresses to our ultimate Framehole solution.

# Verify you have the new Lighthouse 6.0 installed
npm install -g lighthouse

# This one should have a score somewhere around 60 :(
lighthouse https://webvitalsfail.b-cdn.net/ --view

# Instantly to 100
lighthouse https://webvitalsfail.b-cdn.net/anything-100.html --view

Cat Dance v1 - Link

This is a simple example website to show a typical-looking promo page for our mobile app, "Cat Dance". It features a super cool animated gif to demonstrate the dancing cats you get when installing our hot-off-the-press app to your phone. Now let's check out the Lighthouse 6.0 score for this website:

Woah, a performance score of 60 is painful for overachievers like us. How could this simple site, be so slow according to Google? Let's focus on the "Largest Contentful Paint" as that is one of the fresh new metrics introduced in this version.

This is super helpful as it recommends using a video for animated content and shows us that the Largest Contentful Paint element is the animated gif of our dancing cats. Cool, let's move on to:

Cat Dance v2 - Link

In this version we replace the animated gif with an mp4 played back using the native HTML5 Video Element. This should be much better since mp4's were literally made for animated content and will be much smaller than the comparable animated gif.

Well, this is certainly moving in the right direction. We improved by 14 points just by switching to an mp4 for the animation of our awesome dancing cats. Going from an LCP of 104.9s to 9.9s is certainly a substantial improvement. But we are not happy with a 74. That's like a "C" grade and we are a group of A+ achievers.

Looks like our LCP is now generated by the video which makes sense instead of the previous animated gif. But maybe we're doing a poor job with encoding, the poster image, or something, so let's play with that next.

Cat Dance v3 - Link

For this version, we will just use YouTube for the animated cat video. That way if it's something related to video encoding, this will help eliminate that. In general, perhaps our naive video encode is holding us back, so let's see what score we get this way.

Wait a second, these guys are geniuses, they take my PageSpeed Score up to 99. We must have really messed up on our video encode to have caused the 76 score, right?

Is something wrong here? In the previous versions, the dancing cats were always the largest element on the screen. And looking at the screenshots from this test shows that the video is still the same size in this version. So why is it claiming that the text of our <h1> is the largest element? The answer is in the Google description of the Largest Contentful Paint metric. This metric includes the largest element including video, images, SVGs, BUT NOT IFRAMES

Wait, what? This can't be right. If the iframe is the biggest element and loads slow as molasses, it doesn't matter... not counted! So iframes are like magic performance black holes where we can embed our slow or large elements and they won't impact our performance score. No way! Let's try this out.

Cat Dance v4 - Link

To test our theory, we will go back to our exact version 1 site with the large animated gif and everything. We will only make a single change. Let's load the animated gif in an iframe and see what happens to our PageSpeed Score.

Holy crap... can this really be the solution? We just take whatever problems are causing a website speed score to decrease, throw them in an iframe, then BOOM, no more problems. I mean we know that this isn't really changing how fast things load, because it's the same file, same size, just loaded in an iframe. Just like what happened when using the YouTube embed, it didn't actually change the speed that much. Iframes are just magical portals to beat the PageSpeed Score it seems.

But having to move all our slow elements into iframes is sort of a pain in the butt...

Cat Dance v5 - Framehole'd Link

We need a simpler way to immediately boost the speed of any website. Having to selectively replace elements with iframed versions is just super complicated and may not be worth it in the long run. We know how to work smarter instead of harder.

What if we put the entire site in an iframe? This way our solution would be separate from the actual codebase of the site. We could even do this type of thing at the edge, or in NGINX, totally separating this from impacting any existing code.

Our v5 is just the page from v1, iframed into an empty wrapper. Same big animated gif, no optimizations. And we have now gone from a 60 to a 100. It's the holy grail and no work needs to be done to the actual website.

This is dumb

If you are thinking this is the biggest snake oil you have ever seen and no developer in their right mind would care about this score change since the underlying speed didn't change one bit, then I think you are right on the snake oil front, but so very wrong on whether people care.

Remember, PageSpeed is the gold standard on web performance. Google even uses this score to feed their algorithm. If you haven't ever heard from a customer that they want to see how your product impacts their PageSpeed score, then you haven't talked to enough customers. They care because Google cares, and the score is supposed to mean something. Look how many words it took for me to explain this and imagine telling a customer that they are wrong about your product slowing down the site versus the simplified, easy to understand PageSpeed score, proclaiming how wrong you are.

Whatever the reason for this is, at the end of the day, choosing to exclude iframes from the calculations of how long it takes for the most significant content to appear on a website is just wrong!

Using the largest element's display time as an indicator for speed on a website makes all the sense in the world. It still impacts perception of speed even if it's loaded in an iframe. And moving forward with a score that excludes embedded content is harmful to the goal of making the web faster. Embedded content doesn't get a free pass especially when it's the cause of the slow load times.

If the scoring rolls out with these web metrics, then we are in for a web that is incentivized to move back to a patchwork site with huge advertising and third party embeds, completely disregarding the speed cost of those items. Have no doubt that there will be people who implement exactly the iframing of the entire site as mentioned in this article, because management wanted the highest possible PageSpeed Score.

Behavior is shaped by how we keep score