Skip to main content
    SnapSiteScan

    SnapSiteScan verdict

    Your server is the bottleneck

    When server response time is the largest measured cause of a slow page, no amount of front-end optimisation will fix it: the browser cannot start rendering until the first byte arrives.

    Ownership

    Hosting or backend

    This is a server-side bottleneck, not a front-end one. The cause may sit in hosting, caching, the application layer or the database — but it is set before the first byte of HTML is sent, so compressing images or splitting JavaScript bundles cannot move it.

    What happens if you do nothing?

    Every visitor waits the full server delay before anything at all appears — on every page, on every visit, including from users who already have your files cached. A one-second server delay is a one-second delay added to your entire site.

    Do this first

    1. 1

      Measure the server alone, without the browser

      Request the raw HTML and time it. If that request alone takes more than half a second, the browser is not the problem and no front-end task on the backlog is worth starting.

    2. 2

      Put a cache in front of the page

      Full-page caching or a CDN edge cache turns a dynamic response into a static one. On shared hosting and CMS platforms this is usually the single biggest available win, and it needs no code changes.

    3. 3

      Escalate to whoever owns the hosting

      Send them the measured server response time and ask one question: is the page cached at the edge, and if not, why not? That is a hosting decision, not a development task.

    4. 4

      Only then look at the database and application layer

      Slow queries, uncached API calls and cold serverless starts are real causes — but they are worth investigating only after caching has been ruled out.

    How do you know this verdict is yours?

    • Time to First Byte (server response time) above 600 ms in the scan.
    • First Contentful Paint is high even though the page is visually simple.
    • Desktop and mobile scores are both low by roughly the same amount.
    • The gap between the start of the load and the first paint is mostly empty in the waterfall.

    Not worth your time given this verdict

    • Image compression — it does not affect the delay before the first byte.
    • Removing unused CSS or JavaScript.
    • Font loading strategy.
    • Any Lighthouse finding measured in kilobytes rather than milliseconds.

    Deprioritising a finding is a prioritisation call, not a claim that it never matters.

    When to stop

    When should you stop working on this?

    Stop when server response time is consistently under 300 ms. Below that, further backend tuning is invisible to visitors and the remaining gain has moved to the front end.

    Send this to your team

    The message that ends the discussion

    Heads up: our page speed problem is server-side, not front-end. Server response time is the largest measured cause, so it sits with hosting, caching or the application layer. Front-end work will not fix this. Next step is full-page or edge caching, then we re-measure.

    Quick answer

    My site is slow because of server response time — what do I actually do?

    When server response time is the largest measured cause of a slow page, no amount of front-end optimisation will fix it: the browser cannot start rendering until the first byte arrives. This is a server-side bottleneck, not a front-end one. The cause may sit in hosting, caching, the application layer or the database — but it is set before the first byte of HTML is sent, so compressing images or splitting JavaScript bundles cannot move it.

    Owner
    Hosting or backend
    First action
    Measure the server alone, without the browser

    What to do next: Request the raw HTML and time it. If that request alone takes more than half a second, the browser is not the problem and no front-end task on the backlog is worth starting.

    Not sure which verdict is yours?

    Run a scan and SnapSiteScan will name the dominant cause, the owner and the first action for your page — using the same model as this page.

    Scan your site

    The other verdicts