Skip to content

Magento speed and Core Web Vitals

Magento performance work that makes pages load faster

Shoppers don't wait for slow category pages, and Google notices too. We profile your store under real conditions, sort the bottlenecks by how much they cost you and fix them in the code, the cache and the servers. That covers server response, full page cache, database and search, and Core Web Vitals on the front end. Every change is tried on staging and measured before and after on the same pages, so you can see exactly what each one bought you. A good score on a quiet Tuesday is easy. We aim for a store that stays quick on your busiest day.

  • Measured before and after on the same pages
  • Server response and Core Web Vitals both covered
  • Varnish, Redis, OpenSearch and PHP-FPM tuning
  • A report that explains each change

Measured

Each fix timed on the pages that earn you money

Peak-ready

Busy stores steadied under load

Before / after

Same pages, same conditions

Who it is for

Busy Magento 2 and Adobe Commerce stores failing Core Web Vitals

Big catalogues where category and search pages drag

Stores that slow down or fall over during campaigns and peak season

Teams wasting hours every week in a slow admin

The problem

It's hardly ever one thing. The full page cache never hits because some module sets a cookie on every response. An extension runs a query for each product on category pages. Indexers sit stuck in processing. Redis has no memory cap, OpenSearch was sized for a store half your size, and PHP-FPM hasn't got enough workers. On the front end, the theme loads two megabytes of JavaScript before anyone can tap a button, which is why INP is red. Speed plugins and generic audits won't find any of this. Profiling will.

signs-you-need-this.log

  • ›Category and search pages take more than two seconds to respond
  • ›Search Console reports failing LCP or INP
  • ›The admin is so slow that staff put off editing products
  • ›Nobody knows the full page cache hit rate, or it's low
  • ›Indexers stay stuck in processing
  • ›The store slows down or falls over during campaigns
How we work

We measure before every change and measure again after it. You'll see where the time is going before we spend any of yours.

  1. Step 01

    Baseline

    We measure server response, cache hit rates, slow queries, PHP traces in New Relic or Blackfire, and Core Web Vitals from real visitors on home, category, product, search, cart and checkout.

  2. Step 02

    Sort by impact

    Each problem gets a rough size for impact and effort. We agree the order with you, so the first fixes land on the pages that bring in the most money.

  3. Step 03

    Fix the back end

    Queries, plugins and observers that fire too often, full page cache and Varnish rules, Redis and sessions, OpenSearch sizing, PHP-FPM and OPcache, cron and indexer schedules.

  4. Step 04

    Fix the front end

    JavaScript and CSS weight, render-blocking files, image formats and sizes, third-party tags and the long tasks behind poor INP. If Luma can't get you there, we'll scope a Hyvä migration.

  5. Step 05

    Measure again and report

    We test the same pages in the same conditions and hand you a before-and-after report, with the reason for each change and a list of things to keep an eye on.

Interactive · Before and after

Drag the handle to see the kind of numbers that usually move after a round of tuning.

After

Largest Contentful Paint1.6s
Interaction to Next Paint140ms
Time to First Byte0.3s
Checkout step (p75)2.1s
Full page cache hit rate94%

Before

Largest Contentful Paint4.2s
Interaction to Next Paint480ms
Time to First Byte1.9s
Checkout step (p75)7.8s
Full page cache hit rate31%
⟷

Drag to compare · Representative figures from a typical performance engagement

Why Scopebit

01

We profile, we don't install plugins

Installing a speed extension and calling it done isn't our style. We trace where the milliseconds go and fix that code or setting.

02

Server and theme together

A fast server with a heavy theme still fails Core Web Vitals. A light theme on a slow server still loses on time to first byte. So we work on both.

03

A straight answer on Hyvä

Hyvä can make a dramatic difference on the front end, and it's popular in the UK and the Netherlands for good reason. It's also a theme rebuild. We'll tell you whether tuning Luma will do or whether Hyvä is worth the money.

04

Quick on your busiest day

We've steadied busy stores under heavy load. A good Lighthouse score on a quiet afternoon is nice. A store that stays quick on Black Friday is what pays.

From our clients

Completed the job with quality and on time. Deep knowledge of Magento. Highly recommended.
E-commerce managerMagento 2 payment gateway project

Reviews from real clients. We leave their names off.

FAQ

Tell us what you're planning for the store.

You'll speak to one of the developers. We'll tell you which route we'd take, what usually goes wrong on projects like yours and where we'd start.

Happy to sign an NDA · Everything tested on staging first · The code is yours