Should JavaScript Be in Head or Body? A Practical Guide

Find the best practice for placing script tags: head vs body, with defer and async, plus migration tips to keep HTML pages fast and reliable.

JavaScripting Team

February 18, 2026·5 min read

DOM Frontend Syntax HTML Browser Compatibility

Quick AnswerDefinition

The placement of script tags shapes render-blocking and page speed. In short, the answer to 'should javascript be in head or body' is nuanced: put essential scripts in head using defer, and move non-critical scripts to the end of body or load them with async. This approach balances fast initial render with timely script execution.

Rendering implications of should javascript be in head or body

The placement of <script> tags in HTML changes how quickly the page can render and when JavaScript executes. The guidance around should javascript be in head or body is nuanced and depends on what your scripts do and how quickly you need the DOM to become interactive. According to JavaScripting, the key is to minimize render-blocking time while ensuring essential scripts load early enough to enable critical functionality. In practice, this means distinguishing between critical UI initialization and analytics or widget code. The following examples illustrate common patterns and their effects on page rendering.

HTML

<!-- Blocking script in head (bad for perceived load) -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Test Page</title>
  <script>
    // Simulate long task that blocks rendering
    for (var i = 0; i < 1e7; i++) {}
  </script>
</head>
<body>
  <h1>Hello World</h1>
</body>
</html>

HTML

<!-- Head with defer + end-of-body external script (recommended for many cases) -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Test Page</title>
  <script defer src="main.js"></script>
</head>
<body>
  <h1>Hello World</h1>
  <script src="analytics.js" async></script>
</body>
</html>

In the first example, a long inline script in head blocks DOM construction, delaying render and user-perceived speed. The browser cannot show content until the script finishes.
In the second example, defer ensures main.js executes after parsing, while the async analytics.js loads in parallel without blocking, improving perceived performance. This aligns with the core question of should javascript be in head or body by prioritizing the critical path.

Why this matters: render-blocking scripts directly affect LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift). When you place scripts strategically, you improve metrics that influence user experience and search visibility. In real-world projects, you typically move non-critical scripts to the end of body or load them with async, while keeping essential initialization in a deferred head script.

Takeaway: the best practice is not a single answer for all sites; it’s a strategy-based choice driven by script criticality, inline initialization needs, and performance goals.

blockData

Steps

Estimated time: 45-90 minutes

1
Audit scripts by priority
List all scripts in the project and categorize them as critical (must load early) or non-critical (can defer/async). Evaluate inline vs external scripts and any third-party widgets.
Tip: Use a small, representative page to test 2 loading strategies before refactoring an entire site.
2
Choose loading strategy
Decide where each script will live: head with defer for critical init, end of body for non-critical scripts, and async for analytics widgets.
Tip: Prefer external scripts with defer to preserve order and minimize blocking.
3
Implement changes
Update HTML to reflect the chosen strategy. Add defer to head scripts and relocate non-critical scripts to the end of body or mark them async.
Tip: Keep inline scripts minimal; use small bootstrap logic if needed.
4
Test rendering impact
Open the page in multiple devices, measure First Contentful Paint and Time to Interactive, and compare against baseline.
Tip: Use Performance API or Lighthouse for consistent metrics.
5
Roll out and monitor
Deploy changes to staging first, then production, with monitoring for regressions in load times and interaction readiness.
Tip: Have a rollback plan if performance degrades.

Pro Tip: Defer works best for scripts that rely on DOM readiness but don’t block initial rendering.

Warning: Avoid placing large inline scripts in head; even small blocks can delay rendering on slower connections.

Note: Use module/nomodule pattern for progressive enhancement on older browsers.

Pro Tip: Test on a low-latency network sim to get closer to real user conditions.

Prerequisites

Required

HTML5 basics (semantic structure, head/body sections)
Required
JavaScript fundamentals (ES6+)
Required
Code editor (e.g., VS Code)↗
Required
Modern browser with DevTools
Required

Optional

Optional tooling: local server (e.g., http-server)↗
Optional

Keyboard Shortcuts

Action	Shortcut
Save file	`Ctrl`+`S`
Open Command Palette	`Ctrl`+`⇧`+`P`
Format document	`Ctrl`+`⇧`+`F`
Run local serverFrom project root	`npx http-server .`

Questions & Answers

Should I always place scripts at the end of the body?

Not always. Critical scripts needed for initial render may benefit from being in head with defer. For analytics or widgets, end-of-body loading minimizes render-blocking. Always measure performance to confirm the impact.

What is the difference between defer and async?

Defer preserves script order and runs after parsing. Async loads in parallel and executes as soon as available, potentially out of order. Use defer for dependent initialization and async for independent widgets.

Can I inline small scripts in head for speed?

Inline scripts reduce requests but block rendering while executing. If you must inline, keep the code tiny and load larger logic externally with defer or async.

Is module script different for head placement?

Module scripts are executed in a strict mode and can be deferred naturally. They can be placed in head with type="module" or end of body, but be mindful of browser support and hydration costs.

How can I measure the impact of script placement?

Use Lighthouse, Web Vitals, and the Performance API to compare metrics like First Contentful Paint (FCP) and Time to Interactive (TTI) before/after changes. Re-run tests after each migration step.