WebPageTest on CSS-Tricks: Finding and Fixing Performance Bottlenecks

Chris Coyier recently sat down with Tim Kadlec of WebPageTest to run a performance audit on CSS-Tricks. The session, recorded and available to watch, surfaced several concrete issues. Performance work here is a two-step process: first measure and identify problems, then fix them. The audit revealed some significant pain points, and most of the fixes have already been implemented, with measurable improvements.

The Long Road to Largest Contentful Paint

Largest Contentful Paint (LCP), a Core Web Vital that Google considers an SEO factor, was clocking in at 3.993 seconds—well above recommended thresholds. The audit showed that First Contentful Paint (FCP) and LCP were not landing together, which is the ideal scenario.

What was wrong:

  • The LCP element was a large image that was not properly optimized. It lacked a responsive srcset and was not CDN-hosted.
  • The image had loading="lazy" applied, which is counterproductive for the LCP element.

The fix:

  • Proper image handling was already in place for other file types, but none of it worked for .gif files. The LCP image was a GIF at the time of testing, and moving away from that format for this area was necessary.
  • Lazy loading was turned off for the LCP image. Since this is a WordPress featured image, the fix involved using <?php the_post_thumbnail('', array('loading' => 'eager')); ?>. For inline images, removing loading="lazy" from the <img> tag tells WordPress what it needs to know.

The Costly Gap Between First Byte and First Paint

Kadlec spotted a notable problem in the waterfall: HTML arrived in about 0.5 seconds, but rendering didn't start until around 2.9 seconds. That gap is far too long.

The culprit was a redirect chain. A third-party CSS file was redirecting to local CSS files that contained custom fonts. This redirect added significant time on every page load—not just the first one, but even on subsequent cached loads.

What was wrong:

  • A CSS file redirect chain delayed the start of rendering.
  • Fonts were not self-hosted.

The fix:

  • The redirect was eliminated by purchasing new fonts and self-hosting the font files.
  • New typefaces were brought in—MD Primer for display and Blanco for body text, chosen in part because the RIBBI versions (Regular, Italic, Bold, and Bold Italic) were well-optimized.
  • @font-face is now declared directly in local CSS with no redirects, using font-display: swap;.

Retesting showed a dramatic improvement: on a large article page, the start render time dropped by a full two seconds on a 4G connection.

That’s a biiiiiig change. Especially as it affects cached page loads too.
See how the waterfall pulls back to the left without the CSS redirect.

Layout Shift Revealed by Simulated Scrolling

To measure Cumulative Layout Shift (CLS) more accurately, Kadlec used a WebPageTest trick: injecting custom JavaScript to instruct the test to scroll down the page. This is important because layout shift often happens during scrolling, not just on initial load.

The team tested the Complete Guide to Grid—a quintessential CSS-Tricks page—rather than the homepage. With the scroll injection, Core Web Vitals results were significantly worse than the homepage numbers.

I’m not terribly worried about the LCP with the scrolling in place. That’s just some image like any other on the page, lazily loaded.

The CLS issue was particularly concerning because any layout shifting is obnoxious to users. The waterfall showed visible evidence of shifting layout, marked by dotted orange lines.

The orange CLS lines correlate with images loading (as the page scrolls down and the lazy loaded images come in).

What was wrong:

  • Lazy-loaded images were coming into the viewport and shifting the layout.

What remains unclear:

  • The affected images are inline <img> elements with proper width and height attributes. In theory, those dimensions should reserve space and prevent CLS, even when images are fluid thanks to aspect ratio handling. The suspicion is SVG images might behave differently, but there's no definitive answer yet.

This particular issue remains an open question. Performance work often presents this mix: easy wins from straightforward mistakes, small battles that yield immediate results, larger fights involving external factors, and the occasional mystery that takes time to fully diagnose. Tools like WebPageTest provide the visibility needed to pursue these problems and measure progress along the way.