## Problem/Motivation
Since #784626: Default all JS to the footer, allow asset libraries to force their JS to the header(https://www.drupal.org/project/drupal/issues/784626), Drupal has defaulted all JavaScript to footer placement. This was a sound decision for the pre-HTTP/2 era when it was introduced — it prevented render-blocking on slow connections and underpowered devices.
However, the web landscape has fundamentally changed since this decision was made. Footer placement and `defer` share the same core tradeoff: they protect against **network latency** at the cost of **CPU efficiency**. In 2026, the network bottleneck that justified this tradeoff has largely disappeared for the majority of users, while the CPU cost has become the more relevant concern — particularly on long, content-heavy pages.
### The CPU cost of footer/deferred JS on long pages
When all JS is placed in the footer, the browser must:
1. Parse the entire DOM before executing any scripts
2. Hold all downloaded scripts in memory while waiting for parse completion
3. Execute all scripts in a single burst after DOM parse finishes
On short pages, this burst is trivial. But on long pages (e.g. views listings, commerce product pages, content-heavy nodes), this creates a **CPU spike** at the worst possible moment — right when the page has "finished" loading and the user expects interactivity.
The alternative — scripts executing inline as the parser encounters them — spreads the CPU workload evenly. Parse a section, execute a script, parse more, execute another. The CPU never has to deal with a spike. This is essentially **streaming** vs **batch processing**, and streaming is almost always gentler on resources.
### The landscape has shifted
**Network speeds have made render-blocking negligible:**
- Global median mobile download speed reached 61.52 Mbps in 2025, up from ~30 Mbps in 2021 (Ookla/DataReportal). At these speeds, a typical JS bundle downloads in under 20ms.
- Global median fixed broadband exceeds 95 Mbps. In Australia alone, NBN fixed-line services now deliver 100.6% of plan speeds during busy hours (ACCC Broadband Performance Report, October 2025), with the new default tier jumping to 500 Mbps for FTTP/HFC connections.
- HTTP/2 adoption covers ~71% of websites (HTTP Archive 2024 Web Almanac), with HTTP/2 + HTTP/3 together handling over 90% of Cloudflare's global traffic. Multiplexed connections mean script downloads no longer block other resource fetches.
- HTTP/3, built on QUIC, is now used for ~21% of global requests to Cloudflare (Radar 2025 Year in Review), with browser support exceeding 95%. HTTP/3 eliminates head-of-line blocking entirely.
**Device CPUs have outpaced the problem footer placement was solving:**
- Since the iPhone 6S (2015, Apple A9), single-core performance has improved by approximately 588%, with multi-core gains exceeding 1,000% (Geekbench 6 data compiled by NotebookCheck, October 2025). A synchronous script parse that might have blocked for 50-100ms on a 2015 device now takes 3-5ms.
- Even mid-range Android devices in 2025 significantly outperform flagship devices from the era when footer JS was made the Drupal default.
- The "slow device" population that footer placement was designed to protect has shrunk dramatically. The vast majority of web users are on hardware where synchronous script execution in `` is imperceptible.
**The Lighthouse/synthetic testing trap:**
PageSpeed Insights and Lighthouse reward footer/defer placement because they model worst-case synthetic scenarios. However, real-world user experience on modern hardware and networks often benefits more from immediate script availability (faster interactivity, no flash of unstyled/non-functional content) than from the theoretical FCP improvement that footer placement provides.
## Proposed resolution
This is a meta issue to discuss whether Drupal core should reconsider its blanket footer-JS default. Possible directions:
### Option A: Change the default to `` placement
Make `header: true` the default for library definitions, with `header: false` as the opt-in for non-critical scripts (analytics, tracking, etc.). This reverses the current model where developers must explicitly opt into header placement for critical UI scripts.
### Option B: Introduce a `defer` attribute option alongside placement
Rather than footer placement (which delays execution until after the full DOM parse), allow libraries to specify `defer: true` or `async: true` as attributes. `defer` still downloads in parallel and executes in order, but the browser can begin execution as soon as both the script is downloaded AND the DOM is parsed — which on modern connections means near-instant execution. This would give developers more granular control than the binary header/footer choice.
### Option C: Provide a global configuration option
Allow site builders to choose a default JS strategy (footer, header, defer, async) at the site configuration level, recognising that the optimal strategy depends on the site's audience and content patterns.
### Option D: Keep the default but improve documentation
At minimum, update the documentation to acknowledge that footer placement is a tradeoff rather than a universal best practice, and that sites targeting modern audiences on fast connections may benefit from header placement of critical UI scripts.
## Remaining tasks
- Community discussion on which option(s) to pursue
- Performance benchmarking comparing footer vs header vs defer on representative Drupal pages of varying length
- Analysis of real-world Core Web Vitals data from sites that have moved JS to header
## Related issues
- #784626: Default all JS to the footer, allow asset libraries to force their JS to the header(https://www.drupal.org/project/drupal/issues/784626) — Default all JS to the footer (the original issue from 2010, committed for D8)
- #2989324: Allow CSS to be added at end of page by rendering assets with placeholders(https://www.drupal.org/project/drupal/issues/2989324) — Allow CSS to be added at end of page by rendering assets with placeholders
Comments