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

    Investigate with the front-end team first. The script breakdown may point to your bundle, a theme, a plugin or third-party code; the team controlling that code owns the repair. Faster hosting alone does not remove main-thread execution.

    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

      Inspect legacy-code evidence and your supported browser requirements before adjusting transpilation or polyfills. A modern build can reduce unnecessary output, but compatibility must be tested.

    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.

    From Lighthouse finding to a testable change

    Lighthouse evidence: Reduce JavaScript execution time (bootup-time); Minimize main-thread work (mainthread-work-breakdown); Reduce unused JavaScript

    Execution-time and main-thread findings can describe the same work. SnapSiteScan groups this overlapping evidence into one main-thread cause instead of adding both savings. Use the script breakdown to distinguish parsing, execution and other main-thread activity; transferred bytes alone do not establish execution cost.

    A scoped code example

    <!-- Only for a noncritical external classic script. -->
<script src="/noncritical-widget.js" defer></script>

    When this recommendation does not apply

    defer waits until HTML parsing completes and preserves order among deferred classic scripts; async does not preserve that order. Neither makes expensive execution free. Do not defer a dependency without checking its consumers. Module scripts already defer by default. If execution still dominates, remove unused code, split bundles or shorten long tasks.

    Verify the result, not the estimate

    Test navigation, forms and interactive widgets. Rescan & Compare the same URL/device and inspect lab TBT plus the original execution-time audit. Lower lab TBT does not prove lower field INP; review available CrUX observations separately.

    How First Fix and Rescan & Compare work · Run a scan and keep a before/after report

    Official technical reference

    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?

    Reprioritise when fresh same-device runs no longer identify this as the dominant cause and interaction tests work. Lab TBT below 200 ms is a useful diagnostic target, not proof of field INP; remaining work depends on the evidence.

    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. Investigate with the front-end team first. The script breakdown may point to your bundle, a theme, a plugin or third-party code; the team controlling that code owns the repair. Faster hosting alone does not remove main-thread execution.

    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 to find an eligible First Fix from the returned Lighthouse evidence. Review its applicability, make one change, then use Rescan & Compare in the report to check fresh measurements. If no eligible finding remains, no fix is invented.

    Scan your site

    The other verdicts