Simon Willison recently published a performance audit of a PCGamer article, and it’s the kind of post that deserves more attention than it tends to get. Performance audits of media sites read like horror stories to anyone who has spent time optimizing a web application, but they’re also instructive in a specific way: they show what happens when business incentives, legacy CMS decisions, and editorial velocity all push in the same direction without anyone responsible for the total cost.
PCGamer is not an outlier. It’s a representative example of a category: ad-funded gaming journalism with a massive content archive, a CMS that predates modern performance tooling, and a revenue model that creates structural pressure toward more JavaScript, not less.
What a Performance Audit Actually Measures
The tooling Willison would reach for here is well-established. Lighthouse provides a synthetic benchmark with scores across performance, accessibility, and SEO. WebPageTest gives filmstrip views, waterfall charts, and real-browser test runs from multiple geographic locations. Chrome DevTools Network panel tells you exactly how many bytes crossed the wire and from how many distinct origins.
The metrics that matter most for a media article page are:
- Total page weight: The sum of all transferred bytes. Gaming media pages routinely exceed 10MB on a cold load, with some hitting 20MB or more when video autoplay is factored in.
- First Contentful Paint (FCP): How long before the user sees anything. On a well-optimized page this is under one second. On a ad-heavy media page with above-the-fold interstitials, it can stretch to four or five seconds on a mid-tier mobile device.
- Largest Contentful Paint (LCP): The render time of the largest visible element, usually a hero image. Google’s Core Web Vitals threshold for “good” is under 2.5 seconds.
- Total Blocking Time (TBT): Milliseconds spent blocking the main thread before it becomes interactive. A single poorly-loaded third-party script can dominate this number.
- JavaScript execution time: Not just download size but parse-and-execute cost. A 500KB minified JS bundle costs more than 500KB of images because it has to be parsed and JIT-compiled.
The distinction between JavaScript size and JavaScript execution time is one that audits often make visible in a useful way. A page might transfer 3MB of JavaScript across 40 separate requests, but the execution cost of that JavaScript on a Moto G4 or equivalent mid-range device can be 15-20 seconds. This is what “Time to Interactive” captures, and it is routinely catastrophic on media sites.
Why Gaming Media Sites Are Particularly Heavy
Gaming media has some specific characteristics that compound the general problem of ad-funded journalism.
First, the content itself tends to be media-heavy. Reviews include screenshot galleries, embedded YouTube trailers, performance benchmark charts. Each of these adds weight, and when they’re implemented via embedded iframes from third-party providers, they bring their own JavaScript runtimes along.
Second, the affiliate revenue model layered on top of display advertising means additional tracking and click-attribution scripts. A single article about a graphics card might have affiliate links to Amazon, Newegg, and Best Buy, each wired through a commission-tracking intermediary that injects its own JavaScript. Stack a few of those alongside the standard ad network stack (Google Ad Manager, header bidding wrappers, viewability measurement, brand safety scanning) and you’re looking at 30-50 distinct third-party script origins before any editorial content loads.
Third, CMS inertia. PCGamer runs on a platform inherited from Future Publishing’s acquisition history. Migrating a site with tens of thousands of articles and an established editorial workflow is genuinely hard. Performance optimizations that would require template changes or plugin replacements often lose to “ship the story” priorities.
The Third-Party Script Problem
The thing that makes media site performance audits feel intractable is that the worst offenders are third-party scripts that the site owner does not fully control. The HTTP Archive’s Web Almanac consistently shows that third-party content accounts for a plurality of total page weight on news and media sites, and a majority of blocking time.
Consider a typical ad-supported page load sequence:
- HTML arrives, begins parsing
- Synchronous script tags block parsing while Google Tag Manager loads
- GTM fires its own tag list, loading the ad network wrapper, the analytics beacon, the A/B test framework, and the affiliate link injector
- The ad network wrapper runs its own header bidding auction, making concurrent requests to 15 demand-side platforms
- The winning bid renders an iframe that loads its own full JavaScript environment
- Meanwhile, the editorial content (the article text, the images) has been sitting in the network buffer waiting for the main thread
This is not a performance problem in the traditional sense of “the code is inefficient.” It is an architectural problem where the sequencing of resource loading is determined by third-party contracts rather than user experience priorities. You can defer some of this, but deferred ads that load after the content introduce their own layout shift problems, which hurt Core Web Vitals scores in a different way.
What Good Actually Looks Like
For comparison: a well-optimized article page on a media site should be achievable at under 500KB total transfer weight on a text-and-image article, with LCP under two seconds on a 4G connection. Sites like The Guardian have invested significantly in performance engineering and publish their approach. Cloudflare’s blog and Increment Magazine are examples from the tech world of editorially-rich pages that stay fast.
The pattern that makes the difference is almost always the same: lazy-load everything below the fold, preload the LCP image, self-host or inline critical CSS, and treat each third-party script as a performance budget line item with a hard cap.
Lazy loading in modern HTML is now a single attribute:
<img src="screenshot.jpg" loading="lazy" width="1200" height="675" alt="...">This alone can cut the initial page weight of a screenshot-heavy review by 60-70%. The width and height attributes matter too: without them, the browser cannot reserve layout space before the image loads, causing cumulative layout shift.
For JavaScript, the type="module" + <script defer> combination with explicit dependency management has largely replaced the older async-vs-defer debates. But on a legacy CMS, the template that controls script tag rendering may not be touched in years.
The Audit as a Forcing Function
What makes Willison’s audit useful beyond the specific numbers is the implicit argument it makes about visibility. Performance problems on media sites are invisible to the people who could fix them, because those people use fast devices on fast connections and have the site cached from yesterday’s visit. The numbers in an audit, rendered as a Lighthouse report or a WebPageTest filmstrip, create a shared artifact that makes the problem legible.
Google’s decision to incorporate Core Web Vitals into search ranking in 2021 was, in practice, the strongest incentive media organizations received to actually measure and act on page performance. A site that ranks on the first page for gaming hardware reviews cannot afford a sustained ranking penalty from poor LCP scores. The business case, finally, lined up with the user experience case.
The question Willison’s audit implicitly asks is whether that incentive has been enough. For PCGamer and sites like it, the answer seems to be: partially. The most egregious blocking-script patterns from 2015 are largely gone. But the weight, the third-party count, and the Time to Interactive on mid-range mobile remain well above what any user-centered performance budget would allow.
Running this kind of audit on your own projects, or on sites you read regularly, is worth doing at least occasionally. PageSpeed Insights is free, requires no setup, and gives you real-world CrUX data alongside the synthetic Lighthouse run. The numbers are sometimes demoralizing. They are always informative.