Skip to content
Web & Digital Growth

Performance Engineering

Fast is a budget you enforce, not a score you screenshot.

Core Web Vitals brought inside Google's thresholds on real devices, and kept there by a gate in your pipeline.

The problem

The score that was green at launch

Most performance work is done once, screenshotted, and then undone over eighteen months by a marketing tag here, a hero video there, and a font that was only meant to be temporary. The site is not slow because nobody optimized it. It is slow because nothing stopped it drifting back.

Meanwhile the measurement most teams look at is a lab score from a fast machine on a fast connection. Google ranks on field data from real users on real devices, and the gap between the two is where the surprise lives.

We treat performance as a budget with a gate: numbers that must hold, enforced in the pipeline, on the devices your visitors actually use.

What we do

What we do

Core Web Vitals remediation
LCP, INP and CLS diagnosed from field data and fixed at the cause: render-blocking chains, layout instability, main-thread contention and hydration cost.
Edge rendering & CDN strategy
Content served from close to the user, with the right rendering mode per route — static, streamed, or dynamic at the edge — rather than one strategy imposed on the whole site.
Caching architecture
Cache layers, invalidation rules and stale-while-revalidate policy designed so speed does not come at the price of stale prices, stock levels or content.
Image & font pipelines
Modern formats, correct sizing, priority hints for the largest element, and font loading that does not shift the layout after paint.
JavaScript budget & code splitting
A hard ceiling on shipped JavaScript per route, enforced rather than aspired to, with the bundle analysis that shows where it went.
Third-party script governance
Tag audit, load strategy and a policy for what may be added later — the single most common cause of a fast site becoming slow.
Real-user monitoring
Field measurement by template and device class, so regressions are found by instrumentation rather than by a client noticing.
CI performance gates
Lighthouse CI and bundle-size checks in the pipeline. A pull request that breaks the budget fails, the same way a broken test fails.
How we work

How a performance engagement runs

  1. 01

    Measure the field, not the lab

    Real-user data by template and device. Lab scores are a debugging tool, never the target.

  2. 02

    Fix causes, not symptoms

    Ranked by impact on the metric that is actually failing, with the effort against each so you can choose.

  3. 03

    Set the budget

    Explicit numbers for LCP, INP, CLS and shipped JavaScript, agreed with you and written down.

  4. 04

    Gate it

    The budget enters CI. From that point performance stops being a project and becomes a property of the codebase.

Our method, published

The budget we enforce

These are the numbers a release has to meet on a mid-range mobile device on a 4G connection. They are not aspirations printed in a proposal — they are gates in the pipeline, and a build that misses them does not ship.

  • LCP under 2.5s (field, 75th percentile)
  • INP under 200ms (field, 75th percentile)
  • CLS under 0.1 (field, 75th percentile)
  • JavaScript under 170KB compressed per route
  • Lighthouse performance 95+ on key templates
  • No render-blocking third-party script above the fold

StackCore Web Vitals·Lighthouse CI·Cloudflare·Next.js·RUM·CDN

FAQ

Performance, answered directly

Lighthouse is a lab simulation on a synthetic device. Google ranks on field data from your actual visitors, whose phones and networks are usually slower. A 95 lab score alongside failing field vitals is common, and the field number is the one that counts.

Request a performance audit

Describe what you have and what it needs to do. We will tell you what it takes.