03 · Technology
Make it fast, then keep it fast.
A slow site makes visitors wait, some of them leave, and nobody can say exactly when it got slow. Usually no single change did it: a dependency here, an oversized image there, a script that blocks rendering. Performance engineering is the hands-on work of finding where the time and bytes go, fixing the causes, and putting guardrails in the build so the site stays fast. We profile on realistic devices and networks, fix what we find and set a budget that fails the build when it is exceeded. If you need a written diagnosis before committing to any fixes, start with the Performance & Architecture Audit.
What you walk away with
- A profile of where time and bytes go, measured on realistic devices and networks rather than a fast laptop on fast wifi.
- LCP, CLS and INP improved against targets agreed up front, checked in field data where it exists rather than only in a lab snapshot.
- Performance budgets for bytes, requests and timings, wired into the build.
- Caching and edge delivery designed as architecture.
- Guardrails that make a regression fail loudly before it ships.
What it covers
- Core Web Vitals
- LCP, CLS and INP measured in field data and engineered toward Google's published targets: LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. Then guardrails go in so a future deploy can't quietly undo the work.
- INP and interaction latency
- Interaction to Next Paint exposes the JavaScript cost many sites ignore: long tasks that block the main thread and make a page feel sluggish to touch. We profile the interactions that matter and break up the work stalling them.
- LCP and the rendering path
- Largest Contentful Paint is mostly an architecture story: what loads first, what blocks it and how the critical path is composed. We fix the rendering pipeline rather than chasing the symptom with a preload tag.
- Performance budgets
- Thresholds for bytes, requests and timings, wired into the build so regressions are caught before they ship rather than after a user complains.
- Profiling and diagnosis
- Before we change anything, we measure under realistic conditions. We would rather spend an hour profiling than a week optimizing the wrong thing.
- Caching and edge architecture
- Where computation happens decides how fast it feels. We design caching and edge delivery deliberately, so the right work runs in the right place and the response comes from somewhere close.
What it looks like in practice
For Roseville Star Ready Mix, a ready-mix concrete delivery company in Roseville, California, we refactored its 12-page Astro site and removed React. Per our build report, client-side JavaScript fell from about 230 KB to 5.5 KB. The concrete calculator customers use stayed, with unit tests around it, so the speed did not cost a feature.
That is the pattern: measure, remove what the page doesn’t need, keep what customers actually use, and test it so it stays correct. The budget then lives in the build, so the next dependency someone adds has to justify its weight before it ships. For the INP side of this work in detail, see our guide to optimizing Interaction to Next Paint.
How the work runs
Every engagement moves through the same five stages, with one team throughout.
Understand
A first conversation and a look at what already exists: your position, your customers’ path, your traffic and your technology.
Define
Positioning, scope and architecture decided deliberately and written down, so everyone knows what is being built and why.
Design
Brand, content and interface designed together, against those decisions rather than the fashion of the month.
Build
Built with speed, accessibility and security as requirements, and reviewed on a staging site before anything goes live.
Improve
Launch is the start. We measure what matters, fix what drifts and report in plain language.
Further reading
- INP Optimization: How to Fix Interaction to Next PaintWhat a good Interaction to Next Paint score is, why sites fail it, and the concrete fixes that bring INP under 200 milliseconds for real users.
- Core Web Vitals for Scaling WordPress: Beyond Caching PluginsCaching plugins only go so far. What actually limits Core Web Vitals on large WordPress sites, how to fix each cause, and when the architecture is the ceiling.
- Web Performance Guide 2026: Fixing Core Web VitalsThe three Core Web Vitals, their thresholds and the fixes that move them: LCP, INP and CLS, with working code and a performance budget to hold the line.
Performance engineering: common questions
How is this different from the Performance & Architecture Audit?
The Performance & Architecture Audit is a fixed-scope diagnosis: a ranked findings report and a verdict, with no fixes, covering architecture, technical debt and security as well as speed. Performance engineering is the work itself: changing the code, the rendering path and the caching, then keeping the numbers where they should be. If you already know speed is the problem, start here; if you are not sure what the problem is, start with the audit.
Can't a caching plugin do this?
A caching plugin treats a symptom and often hides the real problem. It can lift a score on a test run while the underlying causes (too much JavaScript, a rendering path that fights the browser, an unbudgeted dependency) stay in place and reappear under real traffic. We fix the cause, and use caching as deliberate architecture rather than a bandage.
How do you actually measure performance?
Against reality, not a fast laptop on fast wifi. We profile with realistic device and network conditions, look at Core Web Vitals field data where it exists, and trace where time and bytes go through the rendering and network path. A number you can't reproduce on a mid-range phone isn't a result we trust.
Do you guarantee a specific Lighthouse score?
No. We won't promise a number divorced from your constraints, because a lab score that ignores real-world conditions proves little. We engineer the page against the metrics that matter, show you results you can reproduce under realistic conditions, and put budgets in place to keep them.