Why Lighthouse 90 is our module ship-blocker

Every module on this marketplace passes a Lighthouse Performance budget before it goes live. The number is 90 on mobile, measured against a Magento 2.4.6 plus Hyvä 1.3 reference store with the module installed and active.

If the module drops the score below 90, it does not ship. We send it back to the developer with the failing trace.

Why this rule exists

In 2019 the team that runs this marketplace spent six months chasing a 1.4-second LCP regression on a customer store. The trail led through three third-party modules. None of which individually broke Lighthouse, but together they shipped 240KB of unused JavaScript and four blocking network requests on first paint.

That work was billable to us. The customer was fine. But the lesson stuck: most module catalogs treat performance as a customer problem. They sell features. The store owner installs five, conversion drops, and nobody knows which module to blame.

We decided to flip the responsibility. If a module ships from us, it must not cost the customer measurable performance.

What the 90 budget actually catches

The audit runs nine specific checks:

1. Total blocking time under 200ms. Long tasks during initial render fail this fast.
2. Largest Contentful Paint under 2.5s. Module-injected hero images or above-fold widgets that do not lazy-load fail here.
3. Cumulative Layout Shift under 0.1. Any widget that appears after first paint without a reserved space fails.
4. No legacy JavaScript. Modules shipped with Babel-targeted ES5 polyfills for browsers nobody uses get flagged.
5. No unused CSS over 20KB. Bootstrap or Materialize residue gets caught.
6. Render-blocking resources under 600ms. External fonts, sync scripts, blocking stylesheets all fail this.
7. Image formats current. PNG hero images when WebP would do, JPEG hero images when AVIF would do.
8. No render-blocking third-party iframes. Live-chat widgets that block paint instead of loading post-paint fail.
9. Server response stays under 600ms TTFB with the module's backend code active.

Modules can pass with cleverness, code-splitting, deferred loading, server-side rendering. The budget rewards the right behaviors, not specific implementations.

The argument we have most often

Developers sometimes ask why we don't just run the audit on the customer's real store instead of a reference store. Reasonable question.

The answer is that customer stores have noise. Five other third-party modules, custom code, a custom theme. By the time you isolate the new module's contribution you have spent an hour. The reference store gives a clean baseline. Modules pass or fail in isolation.

We do also run a secondary audit on a few real-world store configs before final approval, but the reference-store audit is the gate.

What this means for buyers

Every module page shows the Lighthouse score the module passed against. The score the module starts at is not necessarily the score your store will end at. That depends on everything else you have installed. But the module's contribution is bounded.

If a module's performance changes after a version update, the new score replaces the old one on the page. You can spot regressions by reading the version history. We have reverted modules over a 2-point drop.

The discipline costs us features. We turn down submissions that would otherwise pay. The trade is worth it: a catalog where every module's performance is documented and bounded is a catalog buyers can trust.