Make your store fast. Then keep it fast.
We find what slows your Magento store down, fix it, and prove the result with the same measurements we started from. It begins with a fixed-price audit; the fixes and monitoring are up to you.
- Audit first
- 1–2 weeks, fixed price
- Fixes re-measured
- same tools, same URLs
- Read-only
- until you approve changes
- Field-confirmed
- real-user data after 28 days
Three steps. Stop after any of them.
- 1Start here
Audit
1–2 weeks · fixed price
Measure everything, find every bottleneck with evidence, and rank the fixes by business impact.
You getBook an audit- Baseline KPI tables
- Findings with evidence
- Impact/effort matrix and roadmap
- PDF report + 45-minute walkthrough
- 2
Fix sprint
Scoped from the audit
We ship the fixes you approve, as reviewed pull requests or paired with your team, then re-measure with the audit's exact protocol.
You get- Quick wins first, big bets planned
- Changes shipped and documented
- Before/after report, same tools and URLs
- Real-user data checked again after 28 days
- 3
Monitor
Monthly
Speed decays with every release and every new extension. We watch it so it doesn't.
You get- Weekly PageSpeed runs on your page set
- Monthly real-user (CrUX) review
- Budgets per page type, alerts on regressions
- Load tests before peak season
When it pays off.
Start now if
- Search Console lists poor or needs-improvement URLs
- The store slowed down after an upgrade, migration or new extension
- Server response is slow even with Varnish in front
- Peak season is coming and nobody knows the breaking point
- Cache flushes, imports or deploys make the site crawl
You can wait if
- You pass Core Web Vitals at p75, on mobile and desktop
- You're still working through a recent audit's findings
- You're mid-replatform: audit the new stack before launch instead
The numbers we move.
We don't promise a score. We measure these before and after, with the same protocol, and show you both.
Server response
How long the server takes to answer. Fixed in cache, PHP, database and infrastructure.
Cache hit ratio
How often Varnish answers instead of Magento. Fixed with VCL, hole-punching and warming.
Largest Contentful Paint
When the main image or heading appears. Fixed with server speed, preloading and image delivery.
Interaction to Next Paint
How fast the page reacts to taps and clicks. Fixed by cutting JavaScript and taming third parties.
Cumulative Layout Shift
How much the page jumps while loading. Fixed by reserving space for images, blocks and banners.
Queries per page
The database work behind every uncached page. Fixed with batching, indexes and cached data.
Peak capacity
How much traffic the store takes before it slows. Proven with load tests, before and after.
Admin & indexing
Saves, imports and indexers that block everything else. Fixed with schedules, queues and cleanup.
Where we look, and what we fix.
Infrastructure & configuration
- Production mode, no debug settings left on
- PHP, OPcache and FPM pool sized to the server
- Redis for cache and sessions, sane eviction
- Search engine memory and response times
Right-sized PHP-FPM pools, OPcache and realpath tuning, Redis split for cache and sessions.
Full-page cache
- Hit ratio per page type
- Blocks that switch off caching for a whole page
- Marketing query strings stripped in VCL
- What flushes the cache, how often, and warming
VCL tuned for your Magento version, private content moved to sections, warming after flushes and deploys.
Application
- SQL queries per page, repeated (N+1) queries
- Product loads inside loops, unlimited collections
- Plugins and observers on hot paths
- Time spent per third-party extension
Batched loads instead of loops, plugins taken off hot paths, data indexed instead of computed per request.
Database
- Slow queries ranked by total time, not single duration
- EXPLAIN on the top 10: full scans, missing indexes
- Deadlocks and lock waits at peak
- Bloated tables and stuck indexers
Composite indexes, rewritten top queries, indexers on schedule, bloated tables cleaned.
Frontend
- What the LCP element is and when it's discovered
- Layout shifts: late blocks, images, fonts
- JavaScript weight, bundling, render-blocking files
- Images, fonts and iframes
LCP image preloaded and sized, space reserved for late content, JavaScript trimmed and deferred.
Third parties & Hyvä
- Every page measured with and without third parties
- Their cost reported separately
- Facades for video, maps and chat widgets
- Whether Luma is your ceiling, with numbers
Facades and delayed loading for widgets, and a Hyvä plan when Luma is the ceiling.
Seven rules we don't bend.
Measure before touching anything
No baseline, no “after”. Every change is compared with numbers taken before it.
Server first, cache second, frontend third
Cache hides a slow backend, but every miss, flush and new URL still pays for it. A fast frontend on a 3-second TTFB is still slow.
One tool per comparison
Every before/after pair comes from the same tool, settings and URL. We never mix WebPageTest and PageSpeed numbers in one row.
Field beats lab
Lab tests diagnose and prove cause. Field data (CrUX p75, Search Console) is what Google and your customers actually experience.
Rank by business impact
Impact × confidence ÷ effort. Not by how interesting the bug is.
Every finding has evidence
A profile, a log line, a query or a waterfall. No best-practice advice without proof it applies to your store.
Your data stays yours
We sign your NDA first, and anonymise screenshots and exports before anything leaves your project.
One protocol, from first number to last.
Step 1 · The audit
- 0
Intake & access
A short questionnaire, read-only access, and the exact pages we'll measure.
You getQuestionnaire, access checklist, page list
- 1
Baseline
Field, lab, backend and infrastructure numbers, taken with a fixed protocol.
You getKPI tables
- 2
Investigation
Layer by layer: server, cache, application, database, frontend.
You getFindings with evidence
- 3
Prioritisation
Each finding scored for impact, confidence, effort and risk.
You getImpact/effort matrix
- 4
Report & walkthrough
Summary, baseline, evidence, ranked bottlenecks and a roadmap.
You getPDF report + 45-minute call
Steps 2 and 3 · Fix sprint and monitoring
Fix sprint
We ship the fixes you approve and re-measure with exactly the phase 1 protocol.
Monitor
Weekly lab runs, a monthly field-data review and alerts when a release regresses.
The same pages, every time.
We agree the exact URLs at intake and reuse them in every measurement, before and after.
The page set
- 01Home
- 02A large category
- 03A simple product
- 04A configurable or bundle product
- 05Your heaviest product
- 06Search results
- 07Cart
- 08Checkout, step 1
Real users (field)
LCP, INP, CLS, FCP and TTFB at p75, mobile and desktop.
PageSpeed Insights · CrUX history · Search Console
Frontend (lab)
Score, TTFB, start render, LCP, CLS, TBT, Speed Index, requests, page weight, JavaScript and third-party bytes.
Median of 5 PageSpeed runs and 3–5 WebPageTest runs
Backend (uncached)
Wall time, CPU, I/O, memory, SQL time and query count, product and collection loads per page. Response-time p50/p95/p99 per page type.
Profiler · APM or server logs
Infrastructure & cache
Varnish hit ratio and evictions, Redis memory, PHP-FPM queue, OPcache, MySQL buffer pool, indexers, cron and queues.
varnishstat · redis-cli · FPM status · MySQL
Quick wins first. Big bets planned.
Quick wins
High impact, low effort
Do these first.
Big bets
High impact, high effort
Plan them.
Fill-ins
Low impact, low effort
When it's convenient.
Not now
Low impact, high effort
Parked, with the reason.
Effort →
How each finding is scored
- Impact
- 1 to 5
- Confidence
- Low · medium · high
- Effort
- S ≤ 1 day · M ≤ 1 week · L > 1 week
- Risk
- Low · medium · high
We put a money value on a fix only with your own conversion data. We never invent uplift percentages.
Same tool, same URL, same settings.
Every number in the report carries its context, so the “after” is measured exactly like the “before”.
| Recorded | Example |
|---|---|
| Date & time | 3 Nov 2026, 10:00 CET |
| URL & page type | /product-x · heaviest product |
| Tool & version | Lighthouse 12.8 · WebPageTest · Blackfire |
| Device & connection | Mobile · 4G profile · fixed location |
| Cache state | Warm (primed first) or uncached |
| Third parties | On or off, with the list blocked |
| Runs | 5, median reported |
| Raw data | Link to the JSON, HAR or profile |
Rules
- The cache is primed before frontend tests, so TTFB never includes a cache miss.
- PageSpeed varies 5–10 points between runs, so we always report the median of five or more.
- Field data takes about 28 days to reflect a fix. Lab proves it on day one; field confirms it a month later.
Speed is a habit, not a project.
Every release, extension and marketing script can undo the work. Monitoring catches it before your customers do.
Weekly lab runs
PageSpeed runs on your page set every week, median of five, compared with the budget.
Monthly field review
CrUX history and Search Console: what your real visitors experienced last month.
Budgets per page type
An agreed limit for each page type. A release that breaks it gets flagged before customers notice.
Peak readiness
Load tests before your busy season, so you know the breaking point instead of finding it live.
Errors on hot paths
Exceptions on product, cart and checkout reviewed every month, because errors are slow too.
Engineers who know your store
The same people who audited and fixed it, ready when something regresses.
Free tools by default. Yours if you have them.
- Field data
- PageSpeed Insights, CrUX History API, Search Console
- Lab
- Lighthouse CLI, WebPageTest, Chrome DevTools
- PHP profiling
- Blackfire or Tideways if you have them; SPX, the Magento profiler and the FPM slow log otherwise
- Response times
- New Relic or Datadog, or your web-server logs
- Database
- Slow-query log with pt-query-digest, performance_schema, EXPLAIN
- Cache
- varnishstat, varnishlog, redis-cli
- Load
- k6, on staging, or in production only with written consent
We read. We don't break.
- Read-only access to code, logs and monitoring
- Search Console read access for field data
- Staging first for anything that adds load
- Written consent before profiling agents, low-threshold slow logs or load tests in production
- Your NDA signed before we get access
- Screenshots and exports anonymised
Before you ask.
Do we have to buy all three steps?
No. The audit stands on its own: you get the report and roadmap, and your team can do every fix itself. Fix sprints and monitoring are separate, optional engagements.
What does it cost?
The audit is a fixed price, agreed after a 30-minute scoping call. Fix sprints are quoted from the audit's findings, and monitoring is a monthly fee. Nothing is billed until you approve a proposal.
How long until we see results?
Lab tests prove a fix the day it ships. Field data, which Google uses, takes about 28 days to fully reflect it, because CrUX is a 28-day rolling window.
Do you guarantee a PageSpeed score?
No, and be wary of anyone who does. Scores vary 5–10 points between runs. We commit to measuring before and after with the same protocol, and to showing you both.
Can you work with our agency or in-house team?
Yes. We can ship the fixes ourselves, pair with your developers, or hand over a report written for them: the file, the fix, the effort and how to verify it.
Will you install anything on production?
Not without your written consent. Profiling agents, a low-threshold slow-query log and load tests run on staging first, or in production only within an agreed window.
Make your store fast. Start with the audit.
Tell us about your store. We reply within one business day to set up a 30-minute scoping call, then send a fixed quote for the audit.