Magento 2 performance optimization

Yes, measurably and in writing. Every Full Optimization project ships with a Lighthouse 90+ guarantee and a target of 50%+ TTFB reduction. We capture before/after metrics on staging every day during the project (Lighthouse, WebPageTest, RUM if you have it) so you can see the curve flatten in real time. If we miss the agreed targets at go-live, we keep tuning at no extra charge until we hit them. The audit-only tier doesn’t include the fix, it’s a diagnose-and-prioritise report you can hand to any developer to execute.

Three quick checks: (1) Run your homepage through PageSpeed Insights, if the mobile score is below 70, you’re leaving conversion money on the table. (2) Check Search Console > Core Web Vitals, any URL flagged as “Poor” is a Google ranking liability. (3) Time-to-first-byte, if your TTFB is over 800ms on a warm cache, your stack is misconfigured. The free 30-min audit covers all three plus a slow-query log review, you get a written report whether or not you go ahead with the fix.

Mobile: 90+ is the floor we target on every project. 95+ is achievable on Hyvä-based stores with disciplined image strategy and minimal third-party scripts. Below 70 mobile means real revenue impact, Google research and our own client data both show conversion drops sharply once mobile Lighthouse falls under 70. Desktop typically lands 5-10 points higher than mobile because the Lighthouse network throttle is more punishing on mobile. Don’t obsess over the desktop score, mobile is what Google ranks and what most of your customers see.

Yes, checkout is one of the most common Full Optimization scopes. Typical wins: (1) defer all non-essential third-party scripts (chat, analytics, A/B test tools) until after the order is placed, (2) tune the shipping-method and tax-calculation API calls (parallelise where possible, cache where allowed), (3) trim the KnockoutJS view-models that ship with Luma checkout, (4) if you’re open to it, drop in Hyvä Checkout, one-page Alpine.js checkout that loads in < 1s and ships natively in 2.4.9. Checkout-only Lighthouse scores typically jump from 40-60 to 85-95 after this work.

No, that’s the whole reason we use blue-green deploy. The optimised configuration is built and warmed up next to production, then we cut over in < 30 seconds. The old config stays warm for 72 hours, so if anything regresses we flip back instantly. We also do a regression QA pass on staging covering: critical extension flows (search, faceted nav, custom checkout steps, payment gateways), the admin panel, and any custom REST/GraphQL endpoints. The audit catalogues every extension on your store and flags risky ones before any work starts, you sign off the scope, not us.

Core Web Vitals signals start flowing into Search Console within 28 days, that’s the rolling window Google uses for the field-data dataset (CrUX). Visible ranking movement typically takes 6-12 weeks as Googlebot re-crawls and CWV updates feed into the page-experience signal. Stores in competitive SERPs (fashion, electronics, B2B supply) usually see the biggest lift, speed is a tie-breaker against equally-relevant competitors. We do a Screaming Frog crawl pre and post launch and share the URL diff so you can spot any Core-Web-Vital regressions early.

Three categories. (1) Best value: Hetzner dedicated (CCX or AX line), obscene CPU per dollar, fixed cost, you own the box. Pair with our managed config. (2) Fully managed: Hyvä Cloud, Cloudways, or Sonassi, pricier per month but no DevOps load on your team. (3) Enterprise: Adobe Commerce Cloud if you need the SLA & support contract; AWS behind a custom Terraform stack if you have an in-house DevOps team. We’re hosting-agnostic, the optimisation is portable across all of these. The audit includes a hosting recommendation specific to your traffic shape and budget.

If your Luma frontend is your bottleneck (slow LCP, big JS bundle, KnockoutJS-heavy checkout), yes, Hyvä gets you to Lighthouse 90+ for less effort than re-tuning Luma to the same level. If your bottleneck is backend (slow DB queries, OpenSearch misconfigured, Varnish not in front, third-party-script-heavy theme on a fast CDN), Hyvä won’t fix that, backend tuning will. The audit tells you where your time is actually being spent. If it turns out Hyvä is the answer, we have a separate Hyvä migration service, this performance project would be a stepping-stone or a bundle.

Three layers, each handling different traffic. Varnish sits in front of Magento, it caches full HTML for cacheable pages (category, PDP, CMS) and serves them in < 50ms without ever waking up PHP. FPC (Full Page Cache) is Magento’s own page cache, used as a fallback when Varnish misses. Redis handles two separate jobs: (a) the default-cache for config, layout, blocks, and (b) PHP session storage. We tune all three: Varnish VCL with hole-punching for cart/customer state, FPC tag invalidation, Redis maxmemory + eviction policy, separate Redis databases for cache vs sessions. Done right, your origin only sees logged-in / cart traffic, everything else is served from cache.

Yes, admin tuning is part of every Full Optimization. Common culprits: (1) the indexer running on schedule but not actually completing between runs, (2) bloat in quote, quote_address, and sales_order_grid tables (we run cleanup with a safety-net backup), (3) the admin grid loading the entire product collection because of a missing index, (4) third-party admin extensions running expensive observers on every page load. After tuning, admin pages typically load in 1-2s instead of 8-15s, and the indexers actually keep up with catalogue changes.

Two compounding revenue effects. (1) Conversion lift: stores typically see 8-25% uplift within 90 days post-optimisation, before any UX changes. Google’s own research shows every 100ms of LCP improvement = ~1% conversion gain in retail. (2) SEO lift: rankings improve over 6-12 weeks, which compounds the conversion gain because you’re also getting more traffic. Plus a one-off cost saving: most stores can downgrade hosting after the optimisation (CPU/RAM headroom that was masking the inefficiency is no longer needed), we’ve seen 30% hosting bill drops. On a $1M/yr store, even a conservative 8% conversion lift covers the Full Optimization fee in under a month.

Yes, Lighthouse 90+ on mobile and desktop on the agreed key pages (homepage, top category, top PDP, checkout step 1) at go-live. It’s in the contract. If we miss it, we keep tuning at no extra charge until we hit it. The audit-only tier doesn’t carry the guarantee, it’s a diagnostic report. The Express Audit + Full Optimization combo does. The Lighthouse target is measured on the staging environment with the production traffic profile (no GTM blocking, no ad-blockers, throttled to Lighthouse’s mobile network), the same way Google measures it. We won’t cheat the score by removing necessary scripts, we’ll defer / tree-shake / replace them with lighter alternatives.