Templates under load
Category, product and search pages with real catalog sizes and real carts.
Services
Page
Lazy Ants · eCommerce
eCommerce Performance OptimizationA faster store that stays fast through every release.
eCommerce performance optimization for stores where a platform move is still too early. We fix the site speed problems that cost revenue on the templates that sell, then put gates in the release path so the next release cannot undo the work.
- Caught before release
- Modniy Ostrov: regressions stopped by gates before they reach all users
- Caught automatically
- Dressa: checkout mismatches found by release gates
- $2,250, one week
- Where the work starts: your store measured and the fix priced
What actually goes wrong
The store was made fast once. Six months later it is slow again
Most site speed work ends with a report and a better Core Web Vitals score, and the score holds until the next few releases. Nothing in that process stops a slow query, an uncached template or a third-party script from shipping next Tuesday. That is the part we treat as the actual job.
A Core Web Vitals lab score measures one page
It measures one page on one connection. Revenue runs through templates under real load, with real catalogs and real carts, and those are what we measure.
Nothing blocks a regression from shipping
Without a gate in the release path, the next slow change reaches everyone at once, and it is found by a customer or by a chart, weeks later.
Caching gets switched on and left alone
Stores slow down through coupling, invalidation gaps and data access patterns under load. Fixing them means deciding where the cache sits and when it clears, which is architecture work.
Nobody watches the paths that carry money
Monitoring watches servers, and a slow payment callback looks fine on every dashboard the team has.
Measure, fix, then make the fix hold
Every phase is priced fixed and ends in a condition that is either met or not. The third phase is the one most engagements skip, and it is the reason the first two do not have to be repeated next year.
- Audit1 week
What the revenue-facing templates cost under real load and real data, measured in the field. Ends with the fix list, ranked by what each item costs, and a fixed price for the fix.
Gate: the baseline and the price are agreed, or we stop here and you keep the report.
- The fix list2 to 3 weeks or more
Worked in order of what costs the most: boundaries, caching architecture, data access, payload and the checkout paths.
Gate: each item lands with a measurement next to it.
- Gates in the release path
A regression on a revenue template is stopped before it reaches all users. This keeps the work from being undone by ordinary development.
Gate: a deliberately slow change is blocked in CI, demonstrated once.
- Observability on the money pathsRuns alongside
Checkout, payment callbacks and cache behaviour are watched directly, so a slowdown shows up as a signal before it turns into a support ticket.
Gate: handover, with named owners and alerts that someone receives.
- After the fix30 days
We watch the revenue templates against the baseline from the first week, along with the gates and the alerts on checkout, and fix anything our changes broke at no charge.
Gate: the 30 days end, and every gate and alert has an owner on your side, or the store moves to our Support & Maintenance.
The engagement
Who does the fix, how long it takes, and what happens after
Team
Senior engineers do the work, led by our CTO, the same person who measured your store in the first week and priced the fix. The person who found the problem answers for the fix, so nothing gets lost between the report and the code.
Duration
Usually from two to three weeks, longer when the fix list is long. The timeline is set at the end of the first week together with the price, before any work starts.
Handover
Every gate and every alert gets a named owner on your side, and a walkthrough: what it checks, why it fires and what to do when it does.
After the fix
Thirty days in which we watch the revenue templates, the gates and the alerts on the money paths. Then the store stays with your team, or moves to our Support & Maintenance.
Scope
What we work on, and what we leave to others
eCommerce performance optimization here is engineering work on the stack. Conversion optimisation and marketing work belong to other teams, and if that is what you need we will say so on the first call.
Caching architecture
Boundaries and invalidation: where the coupling is, and what it costs.
Checkout and payments
Edge paths, state transitions, refunds, retries and partial failures.
Two stores where performance stopped being a recurring project
Performance stabilization as a system outcomeBoundaries, caching strategy and observability tied to revenue-facing flows. Regressions are now caught by gates before they reach all users.Read the case
Checkout stabilization under revenue riskPayments and order state stabilised under live traffic, with release gates that catch mismatches automatically.Read the caseWhere to start
Start with a one-week audit
Slow is a symptom, and the cause is not always the code, so the work starts by measuring. One week on your real store ranks what costs the most and ends with a fixed price for the fix. If the platform itself is the constraint, we say so, and half the fee goes toward the eCommerce Architecture Review instead.
Questions we get about performance work
How much does the work cost?
It is priced from your own data. The first week, the Performance Audit, costs $2,250 and ends in a fixed price for the whole fix. That fee credits in full toward the fix from $7,500, within 60 days.
How long does the fix take?
Most fixes take from two to three weeks, and a long fix list takes longer. The timeline is set at the end of the first week together with the price, and the list is worked in order of what each item costs you, so the fixes that pay back most land first.
Will it stay fast after you leave?
That is the point of the release gates. Without a gate in CI, ordinary development undoes performance work within a few releases, and nobody notices until a chart moves.
What happens after the fix?
Thirty days of follow-up. We watch the revenue templates against the baseline from the first week, the release gates, and the alerts on checkout and payment callbacks. If something breaks checkout, we respond within an hour during the working hours we agree with you. Cover outside them is agreed around your season and billed separately. Anything our changes broke, we fix at no charge. After thirty days the gates and alerts stay with named owners on your team, or the store moves to our Support & Maintenance.
Do you do conversion optimisation?
No. This is engineering on the stack: templates under load, caching architecture, checkout state and payment paths. Testing button colours is someone else's job, and we are not good at it.
What if the platform is the problem?
Then optimising it is money spent on something you are going to replace. We will say so at the end of the first week, and half the fee for that week goes toward the eCommerce Architecture Review, which decides whether to migrate, optimise or wait.
Which platforms do you work on?
Magento and Adobe Commerce, Shopify Plus, Sylius, Shopware, BigCommerce and WooCommerce. If you run something else, ask on the first call.
Tell us which pages are slow and what it is costing you
If fixing it would not pay back for you right now, we will say so on the first call, before you spend anything.
