EveryHost: Magento Dedicated Hosting UK
    Peak season 2026 · part 2 of 4: Fast

    Your homepage is not the problem

    Peak breaks in the places full page cache cannot reach

    By Simon Bumford, Founder of EveryHost••7 min read

    TL;DR

    Homepage speed is the metric everybody reports because it is easy to measure and it is full page cached. It is also the page least likely to fail you in November. The revenue is lost further down, in the logged-in journey where cache does not apply and every request hits PHP and the database.

    This is part of the Magento Black Friday readiness checklist. Black Friday 2026 is 27 November. If you want to change anything structural, the deadline that binds is 2 October.

    Why the homepage misleads you

    A Magento homepage served from full page cache is essentially a static file. It will look excellent in any test, at any hour, under almost any load, because Varnish is answering and Magento is not involved.

    The moment a customer logs in or puts something in the basket, that stops being true. Cache is bypassed, every request goes through PHP, and the database starts doing real work.

    So a store can genuinely show a 1.2 second homepage and still lose the sale at the payment step under load. If your reporting only covers the homepage, you are measuring the one page that was never at risk.

    What to test instead

    Load test the logged-in journey: add to cart, view cart, checkout, payment step. That is where the money is and where the failure is.

    Check your full page cache hit rate under load, not at rest. A hit rate that collapses when traffic rises is the single most common peak failure we see.

    Look at field data on mobile, not lab data on your laptop. A mid-range Android on a normal connection is what most of your customers are actually using.

    Know your headroom. If nobody can tell you what the server does at four times normal traffic, you do not know whether you are ready. You are hoping.

    The components that quietly decide it

    Indexers on Update by Schedule, never Update on Save. Update on Save during a peak catalogue change is a well known way to take a store down at the worst moment.

    Cron actually running, and message queue consumers actually alive. Installed is not the same as running, and Magento fails quietly here.

    OpenSearch or Elasticsearch healthy and sized for your catalogue. It is mandatory since 2.4 and it is the component most often left on defaults, which is fine until it is not.

    Redis or Valkey with cache and sessions on separate instances rather than sharing one. Sharing works until the day it does not, and that day is usually a busy one.

    What to do with the answer

    If your headroom is thin, you have two options and only one of them is available in November. You can add capacity, or you can shed load by turning things off.

    Decide in advance what you would switch off. Live chat, review widgets, personalisation, non-essential third party scripts. Write the list now while you are calm.

    If the answer is that you need to move, the honest last sensible start date is around 2 October. After that you are learning a new environment during your busiest fortnight.

    Frequently Asked Questions

    There is no threshold that guarantees anything, and chasing a green score on the homepage is the wrong target. Measure the pages that carry the transaction: category, product, cart and checkout, using field data from real users on mobile. A good homepage with a slow checkout loses more money than the reverse.

    Look at your own peak from last year and plan for meaningfully more than your best hour, not your best day. Averages hide the problem: it is the single busiest hour, usually the evening of Black Friday itself, that breaks things. If you have no history, four times your normal peak hour is a reasonable place to start testing.

    Sometimes, and often not. If the bottleneck is a low cache hit rate, an unhealthy search cluster, indexers on the wrong mode or a slow third party payment call, a bigger server buys you very little for a lot of money. Measure first. That is the whole point of testing the logged-in journey rather than guessing.

    A CDN helps with static assets and with getting cached pages closer to your customers, and it does nothing for the logged-in journey, which is the part that fails. It is worth having and it is not a substitute for knowing what your origin does under load.

    Free Peak Readiness Check

    We will measure your store's real-world mobile performance, check what a logged-in journey actually costs, and tell you where your headroom is. Free, and you do not need to be a customer.

    Back to the full checklist.