What Auditing a Single Gaming Article Reveals About the Web's Performance Debt

Simon Willison recently published a performance audit of a PCGamer article that is worth reading carefully, not because the findings are surprising, but because someone took the time to document them precisely. The conclusions are familiar to anyone who has run Lighthouse on a major media property, but the specificity makes it harder to dismiss.

PCGamer is owned by Future Publishing, a company that operates dozens of high-traffic editorial sites including Tom’s Hardware, TechRadar, Digital Camera World, and GamesRadar. Future’s network is enormous, and it runs on a shared platform that centralizes ad serving, analytics, consent management, and content delivery. That centralization makes the business easier to operate at scale, and it makes individual pages hard to fix.

What a Performance Audit Is Actually Measuring

When someone audits a page using Lighthouse or WebPageTest, they are measuring several distinct things that often get collapsed into a single verdict of “slow.”

Total page weight matters, but raw bytes transferred is a misleading number in isolation. A 5 MB page that delivers a readable article in under a second is better than a 2 MB page where the main content appears at 4 seconds because JavaScript is blocking the render path. The metrics that actually correspond to user experience are the Core Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP, which replaced First Input Delay in 2024).

LCP measures how long it takes for the largest visible element, usually the hero image or the first paragraph of article text, to appear. For a text-heavy gaming article, a good LCP is under 2.5 seconds. The failure mode on sites like PCGamer is not usually the content itself but the number of render-blocking third-party scripts that run before the browser is allowed to paint anything useful.

CLS measures unexpected layout shift, the experience of trying to read a paragraph and having it jump down the page because an ad loaded above it. Gaming media sites are particularly vulnerable here because ad slots are sized dynamically, and the consent management overlay that fires on first visit adds another layer of layout disruption on top of that.

INP measures responsiveness to user input. On pages carrying several hundred kilobytes of JavaScript from ad networks and analytics vendors, the main thread is frequently occupied when users try to scroll or click, which pushes INP scores well above the 200ms threshold Google considers acceptable.

The Anatomy of the Overhead

A typical Future Publishing article page makes requests to dozens of third-party origins. Chrome DevTools’ network panel on a page like this shows a cascade: the article HTML arrives quickly, then the consent management platform fires (often Sourcepoint or OneTrust), then the ad server initializes, then the header bidding auction runs across multiple demand partners, then analytics tags from Google, Comscore, and others load, then social sharing widgets add their own scripts, and then the page is finally interactive.

Each of those steps has latency. Some are sequential by design because consent signals have to propagate before advertising can be served legally under GDPR and similar frameworks. The result is that the editorial content, which is the only thing the reader came for, is competing for bandwidth and CPU time with infrastructure that exists entirely to serve the publisher’s revenue model.

The JavaScript involved is not small. Prebid.js, the open-source header bidding library used by most major publishers, is around 250KB minified before any adapters are added. A typical deployment with a dozen demand partner adapters can easily reach 500KB of bidding-related JavaScript alone. Add Google Publisher Tag, Google Analytics or GA4, a tag management container, a consent platform SDK, and a handful of sponsored content trackers, and the third-party JavaScript payload alone can exceed a megabyte.

This is not unique to PCGamer or Future. The HTTP Archive’s Web Almanac consistently shows that third-party JavaScript accounts for the majority of script execution time on news and media pages. The editorial page itself, the HTML, the article CSS, the images, is usually not the problem.

Why Publishers Have Limited Leverage

The easy read on this situation is that publishers are making bad technical choices and should fix them. That misunderstands the incentive structure.

The ad revenue on a page like a PCGamer article depends on participating in a real-time bidding ecosystem where each additional demand partner increases the chance of a high-value impression. Removing a bidding adapter to reduce JavaScript payload directly risks revenue. Delaying third-party script execution to improve LCP can interfere with viewability measurement, which affects CPM rates. The performance tax is real, but it is the cost of doing business within the programmatic advertising ecosystem.

Consent management adds another constraint. GDPR-compliant consent flows require the platform to wait for user interaction before loading personalized ads. That means the page must load the consent UI, wait for a click, and then initialize ad serving, which is inherently sequential. Publishers can optimize the consent UI itself, but they cannot eliminate the waiting.

The shared platform nature of Future’s infrastructure means that individual site editors have essentially no control over this stack. Decisions about which ad partners to include, which analytics to run, and how the consent flow behaves are made at the platform level and apply to every property in the network. A PCGamer editor cannot remove Prebid adapters any more than they can change the CDN configuration.

What Google’s Core Web Vitals Program Has and Has Not Changed

In 2021, Google began incorporating Core Web Vitals into its search ranking algorithm through the Page Experience update. The theory was that tying ranking to performance metrics would give publishers a financial incentive to optimize, since worse performance would mean lower organic traffic.

The practical effect has been modest. Large media properties have enough domain authority and editorial output that ranking penalties for poor Core Web Vitals are absorbed rather than acted on. There has been measurable improvement at the tail of the web, where smaller sites optimized aggressively to protect their search traffic, but the high-traffic media properties that generate the most impressions have largely continued as before.

Google also operates within a conflict of interest here. Google Ads is a major revenue source for publishers and a major component of the JavaScript payload that degrades performance. Google Publisher Tag and the header bidding integrations that connect to Google Ad Manager are not going away.

What Better Looks Like

Sites that perform well with editorial content are almost always the ones that have either opted out of programmatic advertising or built their business on subscription revenue. Simon Willison’s own site loads in under a second because it is a static site with no ad tech. The Daring Fireball approach, direct sponsorships with a single weekly ad unit, produces a page that is fast because there is nothing to slow it down.

The IndieWeb and static site generator ecosystems have thrived in part as a reaction to this problem. Tools like Astro, Eleventy, and Hugo make it straightforward to publish content that scores 100 on Lighthouse because the output is HTML and CSS with no runtime overhead.

For large commercial publishers, those options are not realistic. The revenue model requires the ad tech, and the ad tech requires the overhead. Audits like the one Willison ran are useful because they document the gap precisely, and because that documentation has a way of accumulating into pressure over time. Browser vendors have increasingly aggressive throttling for third-party scripts. Privacy-focused browsers block most of the tracking payload by default. The ecosystem is slowly changing around publishers who have not changed themselves.

What makes the PCGamer audit worth reading is not the discovery that a major media site is slow. It is the careful accounting of exactly what is responsible and what each piece costs. That level of specificity is what makes the problem legible, and legibility is usually the first step toward anything changing.