Skip to content
arrow_backBack to insights
April 13, 20261 min read

Performance Audits — Beyond the Lighthouse Score

Measuring perceived performance and editorial efficiency in heavy decoupled environments, where a green Lighthouse score can hide real problems.

Lighthouse is a proxy, not a goal

A 98 Lighthouse score on a staging page with 50ms RTT to the CDN is not the same thing as a fast site. The metric that matters is the one your users feel.

What I actually measure

p95 TTFB from the cheapest device on the slowest network your audience uses. Editorial publish-to-live latency. The time from "I know I need to fix this" to "the fix is visible to the customer".

The tools I use

WebPageTest, Blackfire, Drupal's own performance logger, and — more than anything — conversations with the editorial team about what actually slows them down day to day.

Read next

  • Jul 24, 2026

    Layout Builder Is Over-Applied: A Decision Framework for When It Actually Fits

    Layout Builder has become the reflexive answer in Drupal to "how should editors build pages." Somewhere along the way it stopped being one option among several and became the default. That is a mistake I see repeated across projects. Layout Builder is a genuinely good tool for a specific job. The problem is that it gets chosen for jobs it is not suited to, usually because it is the most visible option and nobody paused to ask whether it fit. This post is the decision framework I use to choose between Layout Builder, Paragraphs, custom templates, and plain blocks.

  • Jun 23, 2026

    I Keep Evaluating Alternatives to Drupal. I Keep Choosing Drupal. Here Is the Actual Reasoning.

    I don't ignore the alternatives to Drupal. Sanity, Payload, Strapi, custom Next.js builds. I've built real things with several of them. When a project's requirements push me to look elsewhere, I take them seriously. Here is the honest reasoning behind why I keep choosing Drupal anyway.

  • May 25, 2026

    Stop Making Users Pay for Work Your CI Pipeline Could Do

    Most slow Drupal sites are not slow because the code is wrong. They are slow because expensive work runs at request time when it could have run in the CI pipeline instead. Cold caches, image derivatives, search indexes. The pattern repeats. The fix is the same in every case: move the cost off your users and onto a controlled environment where nobody is waiting. This is a principle, not a tip. Three examples below to make it concrete.

Share this

X and LinkedIn only let you share a link. Copy the content below to paste the full post into either platform.