Critical Rendering Path: Defer JavaScript for Speed

A page can download its HTML quickly and still leave visitors staring at an empty screen. Stylesheets, synchronous scripts, font choices, and expensive JavaScript can all delay useful pixels after the server has responded.

The fix is not to add defer to every script and hope. Map the dependencies that produce the first useful screen, move unrelated work out of that path, and measure whether the change improved rendering without breaking interactions.

Separate network delay from rendering delay

The critical rendering path connects document delivery, parsing, style calculation, layout, and painting. JavaScript can interrupt that chain by blocking parsing, changing styles, or monopolizing the main thread when the browser needs to render.

Use the API Response Latency & Status Tester below to establish a rough baseline for an accessible public endpoint. The API latency tester measures browser-observed request timing, which may include connection setup and network effects. Cross-origin restrictions can prevent a result; it is not a server profiler or a substitute for a page trace.

If the document arrives promptly but the largest content element appears much later, investigate render delay rather than immediately migrating hosting. If the document itself is slow, inspect server response time, redirects, and caching first. Improving the wrong stage produces impressive-looking edits with little user benefit.

Identify what actually blocks the first screen

Capture a cold-load trace with browser developer tools. Disable the cache for one pass, apply a representative network profile, and inspect the document, stylesheets, scripts, fonts, and hero image. Follow the initiator chain to see why each resource started when it did.

A classic script without async or defer can pause parsing while it downloads and executes. Stylesheets generally block rendering, and already encountered blocking stylesheets can also delay script execution. Dependency order matters: a tiny initializer that waits on a large library can become the real bottleneck.

The web.dev critical rendering path guide provides the underlying model. Use it to distinguish required rendering work from merely early network traffic. A resource appearing near the top of the waterfall is not automatically critical.

Set a reproducible baseline

Record Largest Contentful Paint, the relevant resource timings, and long tasks around startup. Repeat the load at least five times and compare medians rather than celebrating the fastest run. Keep the device, network profile, route, and cache condition consistent.

Write down the visible LCP element. If it is a hero image, script changes may help indirectly, but image discovery or transfer size may remain the limiting factor. A baseline should explain what visitors wait for, not just collect a score.

Choose defer, async, and modules deliberately

Use defer for classic external scripts that depend on the parsed document or need ordered execution. Deferred scripts download alongside parsing and execute in document order after parsing, before the document's DOMContentLoaded event.

Use async for genuinely independent scripts. They execute when ready and do not preserve document order. A dependent plugin and its library should not both receive async simply because parallel downloads sound faster.

<!-- Ordered classic scripts that need the parsed document -->
<script defer src="/assets/vendor.js"></script>
<script defer src="/assets/site.js"></script>

<!-- Independent measurement; still subject to consent policy -->
<script async src="/assets/measurement.js"></script>

<!-- Modules are deferred by default -->
<script type="module" src="/assets/account.js"></script>

This example illustrates alternatives, not a requirement to ship every script. A module script is deferred by default unless its loading behavior is changed, such as by adding async. Adding defer to an inline classic script does not produce the external-script behavior shown above.

Check the MDN script element reference when handling special cases. Before changing attributes, list assumptions about global variables, DOM availability, and initialization order. A broken checkout is not a performance improvement.

Deliver critical styles and discover important assets early

Deferring scripts leaves render-blocking CSS untouched. Remove unused styles, avoid long stylesheet import chains, and keep the CSS required for the initial viewport reasonably small. Large shared bundles can make a simple marketing route pay for an entire application.

Inlining a modest amount of critical CSS can remove a request dependency, but it also adds HTML bytes and complicates caching. Prefer a maintainable extraction process over hand-maintained copies that drift from the real stylesheet. Do not hide the entire document while waiting for JavaScript to add a ready class.

Make the main image discoverable in HTML rather than injecting it after a client-side request. Give it dimensions to reserve space. Use preload selectively when discovery is genuinely late; indiscriminate preloads compete for bandwidth and can slow the resources that matter most.

For adjacent asset work, follow the responsive image pipeline guide. Match image candidates to actual display sizes instead of shipping a desktop-sized hero to every phone.

Audit font dependencies

Choose an appropriate font-display policy, reduce unnecessary font weights, and avoid making readable text depend on a large font family arriving first. A fallback font with reasonably similar metrics reduces the layout instability that can follow a font swap.

The goal is useful content sooner, not simply fewer blocking labels in developer tools. Compare the visible page at several moments during loading so a technically faster setup does not introduce flashes or distracting layout jumps.

Move work later without moving the problem

Downloading later does not guarantee executing cheaply. A deferred 300-millisecond task can still block input just after the page becomes visible. Split heavy work, reduce dependencies, and load optional interfaces when users approach or request them.

A dynamic import can keep an infrequently used dialog out of the initial bundle. Show an immediate loading state after activation and handle loading failure. Do not make essential navigation depend on a delayed callback that may never run under sustained activity.

Review third-party scripts individually. Record their owner, purpose, bytes, execution cost, and consent requirements. Removing one unused widget can outperform several rounds of attribute tuning. The web.dev long-task guidance explains why breaking up main-thread work matters after download completes.

Recheck endpoint behavior with the latency measurement tool, then validate the complete page separately. Endpoint timing cannot prove improved LCP, responsiveness, or layout stability. Use the performance and SEO collection for related investigations rather than treating one metric as the whole experience.

Finish with a real-device smoke test: open navigation, submit a form, dismiss consent, and trigger lazy-loaded features. Compare field metrics when available, segmented by route and device class. Functional correctness and consistent gains matter more than one excellent laboratory run.

Key takeaways

• Measure delivery and rendering separately so the fix targets the actual bottleneck rather than the most visible request.
• Use defer for ordered classic dependencies, async for independent work, and module defaults deliberately.
• Reduce critical CSS and discover important images early; script attributes cannot repair every dependency chain.
• Treat deferred execution as real main-thread work. Split heavy tasks and remove unnecessary third-party code.
• Verify user-visible gains with repeated traces, real-device interactions, and field measurements where available.