Measure
Field data from Chrome users and your own analytics shows which templates are slow, and on which devices.
Faster pages, measured by Core Web Vitals.
We find what makes your pages slow on real phones and networks: heavy images, missing caching, slow server responses, third-party scripts. We fix it in the code and on the server, then watch LCP, INP and CLS so it stays fixed.
- Measured on
- Real visits · p75
- Tools
- CrUX · Lighthouse
The speed loop
Measure. Fix. Verify. Repeat.
Speed is not fixed once. Every release can add weight, so each cycle starts from field data, ships a fix and checks it on real visits before the next one.
Measure
Field data from Chrome users and your own analytics shows which templates are slow, and on which devices.
Fix
Images, caching, server response and scripts fixed in order of how many visits they affect.
Verify
Each fix measured on staging, then on real visits, so the next change starts from a known baseline.
Every releasewith monthly field data
Where the time goes
Six places a page loses its speed.
We measure first and fix in order of impact, from the server to the last script on the page.
- CrUX · Lighthouse
Core Web Vitals audit
LCP, INP and CLS from field data and lab runs, traced to their causes.
- Field data per template
- Lab runs on a throttled phone
- A ranked list of causes
- AVIF · WebP
Images and fonts
Correct sizes, modern formats, lazy loading, and fonts that don't shift the layout.
- Responsive image sizes
- Modern formats
- Fonts that load without shifts
- Redis · Nginx
Server response
Slow queries found, PHP and Node.js tuned, pages cached with Redis or Nginx.
- Slow query review
- PHP and Node.js tuning
- Page and object caching
- Cloudflare
CDN and caching
Static files and pages served from Cloudflare's edge, with cache rules that match your content.
- Edge caching
- Cache rules per content type
- Compression
- JS · CSS
Front-end weight
Unused JavaScript and CSS removed, and the main thread kept free for interactions.
- Script budgets
- Unused code removed
- Long tasks split up
- tags
Third-party scripts
Chat widgets, pixels and tags loaded later, or removed when they cost too much.
- A review of every script
- Loading after the page is usable
- Tracking checked after each change
01Core Web Vitals auditCrUX · Lighthouse
LCP, INP and CLS from field data and lab runs, traced to their causes.
- Field data per template
- Lab runs on a throttled phone
- A ranked list of causes
02Images and fontsAVIF · WebP
Correct sizes, modern formats, lazy loading, and fonts that don't shift the layout.
- Responsive image sizes
- Modern formats
- Fonts that load without shifts
03Server responseRedis · Nginx
Slow queries found, PHP and Node.js tuned, pages cached with Redis or Nginx.
- Slow query review
- PHP and Node.js tuning
- Page and object caching
04CDN and cachingCloudflare
Static files and pages served from Cloudflare's edge, with cache rules that match your content.
- Edge caching
- Cache rules per content type
- Compression
05Front-end weightJS · CSS
Unused JavaScript and CSS removed, and the main thread kept free for interactions.
- Script budgets
- Unused code removed
- Long tasks split up
06Third-party scriptstags
Chat widgets, pixels and tags loaded later, or removed when they cost too much.
- A review of every script
- Loading after the page is usable
- Tracking checked after each change
Measurement
Field data first. Lab tests explain it.
Google uses what real visitors experience, so that is what we report. Lab runs and server logs tell us why a template is slow.
Field data
Core Web Vitals from Chrome users, per template and device, at the 75th percentile.
Lab runs
Lighthouse on a throttled phone, to trace each delay to its cause.
Server timing
Response times and slow queries from the server logs.
Release checks
Key templates measured after every release, before and after each fix.
Monitoring
Every key template, watched between releases.
A new plugin, image or tag can undo the work. You hear from us when a template slips, not only in the monthly report.
Templates · mobile p75
Sample data| Template | Device | LCP | Change | INP | CLS |
|---|---|---|---|---|---|
| Home | Mobile | 1.7 s | −0.2 s | 118 ms | 0.02 |
| Category | Mobile | 2.2 s | −0.4 s | 156 ms | 0.06 |
| Product | Mobile | 1.9 s | −1.2 s | 142 ms | 0.04 |
| Article | Mobile | 2.9 s | +0.5 s | 210 ms | 0.03 |
| Checkout | Mobile | 2.1 s | 0.0 s | 188 ms | 0.01 |
| Search results | Mobile | 2.4 s | −0.1 s | 174 ms | 0.08 |
- HomeMobile · INP 118 msLCP 1.7 sChange −0.2 s
- CategoryMobile · INP 156 msLCP 2.2 sChange −0.4 s
- ProductMobile · INP 142 msLCP 1.9 sChange −1.2 s
- ArticleMobile · INP 210 msLCP 2.9 sChange +0.5 s
- CheckoutMobile · INP 188 msLCP 2.1 sChange 0.0 s
Recent alerts
Sample01 / 04 · swipe
Reporting cadence
A rhythm you can plan around.
Reports in plain language: what got slower or faster, why, and what we changed.
Release
Release check
Key templates measured · Script and image budgets · Before and after per fix
Weekly
Field data review
Search Console CWV report · Regressions flagged · Fixes queued
Monthly
Performance report
Vitals per template · What changed and why · Next month's fixes
Quarterly
Budget review
Page weight budgets · Third-party script review · Platform limits
FAQ
Questions about performance.
Our Lighthouse score is fine, but the site still feels slow. Why?
Lighthouse runs one test on a simulated device. Core Web Vitals in Search Console come from real visitors on their own phones and networks, and that is the data Google uses. We start from field data and use lab tests to find the causes.
Does speed affect search rankings?
Core Web Vitals are one of the signals Google uses, but a small one next to relevance. The bigger effect is on people: slow pages lose visitors before they see the content, especially on mobile.
Do we need to rebuild the site to make it fast?
Usually not. Most of the gains come from images, caching, server response and scripts, which can be fixed on the existing site. If the platform itself is the limit, we show you the measurements before recommending a rebuild.
Will removing scripts break our tracking or chat?
Nothing is removed without your agreement. Often a script stays and loads later, once the page is usable. We check GA4 events after each change so tracking keeps working.
How do we keep the site fast after the project?
Key templates are checked as part of each release, and Core Web Vitals are watched in Search Console. If we host or manage the site, this is part of the routine work.
Start with a measurement
Find out what is slowing your pages down.
A Core Web Vitals audit from field data, the causes ranked by how many visits they affect, and a fix list, whether or not we make the fixes.
The audit covers
- Field data for your key templates
- Lab runs on a throttled phone
- Server response and caching
- Images, fonts and scripts
- A ranked fix list with effort