Skip to main content
    SnapSiteScan

    SnapSiteScan verdict

    JavaScript is your bottleneck

    When JavaScript is the largest measured cause, the page usually appears quickly and then refuses to respond, because the browser is busy parsing and executing code instead of reacting to the visitor.

    Ownership

    Front-end development

    This is a code problem, and it belongs to whoever builds the front end. Your host cannot fix it, and a faster server will not change it.

    What happens if you do nothing?

    Visitors see the page, tap a button, and nothing happens. That reads as broken rather than slow, and it is the failure mode most likely to lose a sale that was already half-made.

    Do this first

    1. 1

      Delete before you optimise

      Find the largest bundle and ask what would break if it were removed. Sliders, chat widgets, animation libraries and analytics wrappers are removed far more often than they are missed.

    2. 2

      Load the rest later

      Anything below the first screen — carousels, maps, tabs, modals — should load on interaction or on scroll, not during the initial page load.

    3. 3

      Stop shipping code for browsers nobody uses

      Legacy transpiler output and polyfills routinely add 20–40% to a modern bundle. Changing the build target is a one-line change with no visible risk.

    4. 4

      Break the long tasks that remain

      Any single task over 50 ms blocks input. Splitting hydration and deferring non-critical work is what moves Interaction to Next Paint.

    How do you know this verdict is yours?

    • Total Blocking Time above 600 ms.
    • Large 'unused JavaScript' or 'legacy JavaScript' findings measured in hundreds of kilobytes.
    • The page looks finished long before it can be used.
    • Mobile score is far worse than desktop, because phones execute the same code several times slower.

    Not worth your time given this verdict

    • Upgrading hosting — the delay is happening on the visitor's device, not yours.
    • Image formats, unless images also appear as a top cause.
    • Minification alone: it shrinks bytes but barely reduces execution time.

    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 Total Blocking Time is under 200 ms and the page responds to a tap immediately. Chasing the last few kilobytes has no measurable effect on a visitor.

    Send this to your team

    The message that ends the discussion

    Our slowness is JavaScript execution, not hosting. The page paints fine and then blocks input. First step is removing or deferring the largest bundles, not upgrading the server.

    Quick answer

    Lighthouse says JavaScript is slowing my site down — what should I fix first?

    When JavaScript is the largest measured cause, the page usually appears quickly and then refuses to respond, because the browser is busy parsing and executing code instead of reacting to the visitor. This is a code problem, and it belongs to whoever builds the front end. Your host cannot fix it, and a faster server will not change it.

    Owner
    Front-end development
    First action
    Delete before you optimise

    What to do next: Find the largest bundle and ask what would break if it were removed. Sliders, chat widgets, animation libraries and analytics wrappers are removed far more often than they are missed.

    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