JavaScript Performance Optimization: Reduce Blocking & Improve INP

JavaScript can make a website interactive, but too much JavaScript—or JavaScript loaded at the wrong time—can slow rendering, occupy the browser’s main thread and delay clicks, taps, menus, forms and other interactions.

The goal is not to remove JavaScript from a modern website. The goal is to ship only the JavaScript a page needs, load it at the right time and keep execution work short enough that the browser can respond quickly.

This guide explains how to diagnose JavaScript performance in PageSpeed Insights and Chrome DevTools, how to use defer and async correctly, how to identify long tasks and unused code, how third-party scripts affect responsiveness, and what Blogger users can safely optimize.

Last verified: September 27, 2026. Browser support, DevTools UI, framework behavior and third-party scripts can change.

---

---

1. Why JavaScript Can Slow Down a Website

A JavaScript file has more than a download cost.

After the browser receives the file, the code may need to be decompressed, parsed, compiled and executed. That CPU work can compete with rendering and user interactions, especially on slower phones or pages that load large script bundles.

---

2. JavaScript Performance and Core Web Vitals

JavaScript can affect more than one Core Web Vital, but the relationship is different for each metric.

For the broader metric framework, field-vs-lab distinction and full LCP/INP/CLS workflow, use the Core Web Vitals Optimization Guide.

Interaction to Next Paint (INP)

INP measures page responsiveness to user interactions such as clicks, taps and keyboard input.

A good INP is currently 200 milliseconds or less at the 75th percentile of page loads in field data, evaluated separately for mobile and desktop. Values above 200 ms and up to 500 ms need improvement; above 500 ms is poor.

Heavy script evaluation, long event handlers, repeated main-thread work and large startup bundles can delay the browser’s response to an interaction.

If real-user INP is failing, use the dedicated INP Optimization Guide to identify the slow interaction and separate input delay, processing duration and presentation delay before changing JavaScript architecture. web.dev recommends field data/RUM where available because CrUX can show the metric without always revealing the exact interaction that caused it.

Largest Contentful Paint (LCP)

JavaScript can influence LCP when scripts compete for bandwidth, delay discovery of an important image, render above-the-fold content on the client or keep the main thread too busy to render promptly.

JavaScript is only one possible LCP cause. Server response time, images, CSS, fonts and resource priority can also matter.

Cumulative Layout Shift (CLS)

JavaScript can contribute to CLS when it inserts content above existing content, changes dimensions after initial rendering or injects widgets without reserved space.

The fix is usually to make layout changes predictable and reserve space rather than simply delaying the script.

---

3. Long Tasks and the Browser Main Thread

The browser’s main thread handles important work such as JavaScript execution, style calculation, layout and event processing.

If JavaScript occupies the main thread for too long, an input event may have to wait before the browser can process it.

A task lasting more than 50 milliseconds is classified as a long task for main-thread diagnostics. The portion beyond 50 ms is the task's blocking period. That does not mean every 51 ms task creates poor INP; prioritize tasks that overlap important interactions, startup or rendering.

User clicks
    ↓
Main thread busy with JavaScript
    ↓
Input waits
    ↓
Event handler runs
    ↓
Rendering work
    ↓
Next paint

A page can therefore look visually complete while still feeling slow when the user tries to interact with it.

Yield Between Non-Critical Chunks of Work

Breaking a large JavaScript function into several smaller functions does not automatically create separate browser tasks. If all those functions run synchronously from the same callback, the browser still sees one continuous task.

For work that can be split, yielding gives the browser a chance to process higher-priority work such as user input and rendering.

async function saveSettings() {
  validateForm();
  showSpinner();
  updateUI();

  if (globalThis.scheduler?.yield) {
    await scheduler.yield();
  } else {
    await new Promise(resolve => setTimeout(resolve, 0));
  }

  saveToDatabase();
  sendAnalytics();
}

scheduler.yield() is designed specifically for yielding to the main thread and prioritizes the continuation of the current task. As of this verification it is still listed as limited availability rather than Baseline across all major browsers, so feature detection or a fallback is still required.

Move Suitable Computation to a Web Worker

CPU-heavy work that does not need direct DOM access can sometimes run in a Web Worker. Worker code executes on a separate thread, reducing main-thread congestion. The trade-off is communication and serialization overhead, and DOM manipulation still has to occur on the main thread.

---

4. Start With Measurement, Not Guesswork

Removing or delaying a script without understanding its role can break navigation, forms, consent flows, analytics, ads, affiliate tracking or other important features.

Use a diagnostic sequence instead:

1. Run PageSpeed Insights and review field data first when it exists.
2. Inspect JavaScript requests in Chrome DevTools Network.
3. Record a Performance trace and review the current Performance → Insights area for relevant findings.
4. Use Coverage to investigate potentially unused code after exercising important states.
5. Change one meaningful bottleneck.
6. Retest functionality and performance.

Chrome removed the old standalone Performance Insights panel starting in Chrome 132; current guidance points developers to the Insights experience inside the main Performance panel.

Repeat important tests under comparable conditions. A fast desktop trace can hide work that becomes expensive on a lower-powered phone. Chrome DevTools now supports CPU-throttling calibration for low- and mid-tier mobile approximations; use throttling for investigation but still validate important flows on real hardware when practical because desktop throttling cannot perfectly reproduce mobile CPU architecture.

---

5. Use PageSpeed Insights as a Starting Point

PageSpeed Insights can help surface JavaScript-related opportunities and diagnostics. Exact audit names can change, but common investigation areas include:

• Unused JavaScript.
• Excessive main-thread work.
• Long tasks.
• Third-party impact.
• Resources delaying rendering.

---

6. Inspect JavaScript in Chrome DevTools Network

Open Chrome DevTools, select the Network panel, reload the page and filter requests by JavaScript.

Ask:

• Which JavaScript files are the largest?
• Which scripts come from third-party domains?
• Are duplicate libraries being loaded?
• Are old widgets or marketing scripts still present?
• Does every page load a script that only one page type needs?
• Are scripts competing with images, fonts or CSS early in the load?

---

7. Record a Chrome DevTools Performance Trace

In the Performance panel, record a page load and then record representative interactions such as:

• Opening a mobile menu.
• Submitting a form.
• Opening a modal.
• Filtering results.
• Using a search box.
• Expanding an accordion.

Inspect the main thread for long tasks and red long-task markers. Then examine the flame chart, call stack, Bottom-up/Call tree views and current Performance Insights findings to identify which script and activity consumed the time.

This is more useful than simply knowing that the page has “too much JavaScript.”

---

8. Use Coverage Carefully to Find Unused Code

Chrome DevTools Coverage can show how much loaded CSS and JavaScript was actually used during the recorded session. Current DevTools still lets you choose per-function or per-block scope and continue recording while you interact with the page.

A high unused percentage can indicate an opportunity to remove code, split a bundle or load a feature only when needed.

---

9. Use defer When a Script Can Wait for HTML Parsing

A normal external script can pause HTML parsing while the browser fetches and executes it.

For many site scripts, that is unnecessary.

The defer attribute lets the browser continue parsing HTML while the script downloads. Deferred scripts execute after HTML parsing is complete, and their document order is preserved.

<script src="/js/navigation.js" defer></script>
<script src="/js/site.js" defer></script>

defer is often a good fit for external classic scripts that need the DOM but do not need to execute during parsing. Deferred classic scripts execute after parsing finishes and before DOMContentLoaded, while preserving their relative order. The attribute does not turn an inline classic script into a deferred script.

---

10. Use async for Independent Scripts

The async attribute lets an external script download without blocking HTML parsing. However, when the script finishes downloading, its execution can interrupt the parser.

Execution order is not guaranteed relative to other async scripts, which makes async most appropriate for independent code that does not depend on DOM order or another script finishing first.

<script async src="https://example.com/independent-script.js"></script>

async is appropriate when a script is independent and does not rely on a specific execution sequence. It prevents the download from blocking parsing, but execution can still interrupt the parser when the file becomes ready.

For analytics or other vendor integrations, follow the vendor’s current installation guidance rather than rewriting the snippet without understanding its requirements.

If the main problem is parser-blocking scripts, stylesheet blocking or the critical rendering path rather than JavaScript execution cost itself, use the Render-Blocking Resources Guide.

---

11. defer vs async: Which Should You Use?

ES Modules Are Deferred by Default

A script loaded with type="module" behaves as deferred by default. Adding the classic-script defer attribute is therefore unnecessary for normal module execution, while adding async changes the timing/order behavior. Do not mechanically combine module loading and async without understanding dependencies.

<script type="module" src="/js/app.js"></script>

---

12. Remove Unused JavaScript Before Trying to Optimize It

The cheapest JavaScript is JavaScript you do not send.

Common sources of unnecessary code include:

• Old analytics or marketing tags.
• Multiple libraries that solve the same problem.
• Site-wide bundles containing code used only on one template.
• Slider, popup, chat, sharing or form scripts loaded where the feature does not appear.
• Legacy code left behind after a redesign.
• Large utility libraries used for only one or two small functions.

Removing unused JavaScript can reduce transfer size, parsing/compilation work, memory use and main-thread activity. Even code that never becomes user-visible can still impose download and processing cost when it ships in the initial bundle.

---

13. Split Large JavaScript Bundles

If one bundle contains code for every feature in an application, visitors may download and process code they do not need for the current page.

Code splitting breaks that bundle into smaller pieces so the initial page can load only what is needed.

Possible candidates include:

• Pricing calculators.
• Charting libraries.
• Advanced search interfaces.
• Account dashboards.
• Code editors.
• Heavy ecommerce modules.

The principle is simple: do not make every visitor pay the startup cost of every feature.

Use Dynamic import() for On-Demand Chunks

Dynamic import() can load a JavaScript module only when that feature is needed. It is a practical code-splitting boundary for modern bundlers and native ES-module workflows.

button.addEventListener('click', async () => {
  const { openCalculator } = await import('/js/calculator.js');
  openCalculator();
});

Loading less code at startup can reduce main-thread contention, but dynamic import() is not automatically cheap: importing one very large module can still create a large evaluation task exactly when the user interacts. Split around meaningful feature boundaries and consider whether a predictable on-demand chunk should begin loading slightly before interaction rather than simply moving a monolith later.

---

14. Lazy-Load Features That Are Not Needed Immediately

Lazy loading is not only for images.

JavaScript for below-the-fold or interaction-triggered features can sometimes be loaded later.

Good candidates can include:

• Video players below the fold.
• Maps.
• Advanced calculators.
• Comment systems.
• Chat widgets.
• Social sharing interfaces.
• Large gallery or modal components.

Do not lazy-load something simply because it is large. If the feature is required immediately—or if loading it only after the user clicks creates a noticeable wait—delaying it can make the experience worse. Consider preloading/preconnecting only when measurements show the dependency is predictable and important.

---

15. Break Up Long Main-Thread Tasks

A large synchronous JavaScript task can prevent the browser from responding to user input.

Where application code performs a large amount of work, divide it into smaller units and yield back to the browser between non-critical chunks. Modern browsers that support scheduler.yield() can use it for prioritized continuations; keep a fallback for browsers without support.

Also reduce unnecessary work inside interaction handlers. A click callback that performs expensive loops, recalculates a large DOM tree and triggers repeated layout work will remain slow even if the file downloads efficiently.

---

16. Audit Third-Party JavaScript Aggressively

Third-party scripts deserve special attention because you often have less control over their code, caching policy, release changes and execution cost. web.dev recommends loading third-party scripts asynchronously unless they genuinely must execute before rendering, but async/defer do not eliminate CPU cost once the script executes.

Examples include:

• Analytics platforms.
• Advertising scripts.
• Tag managers.
• Consent platforms.
• Live chat.
• Heatmaps.
• Session recording.
• A/B testing.
• Affiliate tracking.
• Social embeds.
• Video players.

For deeper governance of ads, analytics, tag managers, consent tools, chat, heatmaps and other externally controlled code, use the Third-Party Script Performance Guide. Keep this page focused on JavaScript execution and loading strategy.

---

17. Third-Party Script Audit Checklist

---

18. Be Careful With Tag Managers

A tag manager can simplify deployment, but it can also become a container for years of forgotten scripts.

Periodically audit:

• Old tags.
• Triggers.
• Custom HTML.
• Duplicate analytics properties.
• Expired experiments.
• Tools that are no longer used.

Restrict tags to the pages and conditions where they are actually required.

---

19. Avoid Excessive DOM Work

JavaScript that writes styles and then immediately reads layout-dependent values in the same task can force synchronous layout. Repeating this pattern is often called layout thrashing and can increase the presentation delay portion of an interaction.

Useful improvements include:

• Batch DOM updates.
• Avoid unnecessary layout reads between repeated writes.
• Reduce the number of elements queried or updated.
• Avoid rebuilding a large DOM subtree when a small targeted update is enough.

This is an execution problem, not merely a file-size problem.

If the trace shows large DOM trees, heavy style calculation or repeated layout work, continue with the DOM Size & Rendering Performance Guide.

---

20. Optimize High-Frequency Event Listeners

Scroll, resize, pointer, keyboard and input events can fire frequently.

A heavy callback attached to one of these events can consume substantial main-thread time.

Depending on the interaction, techniques such as throttling, debouncing, scheduling, passive listeners where semantically appropriate, or more specialized browser APIs can reduce unnecessary repeated work.

Also inspect recurring setInterval() and setTimeout() callbacks that repeatedly wake the page and perform expensive work.

---

21. Minification Helps, but It Is Not a Complete Strategy

Minification can reduce JavaScript transfer size by removing unnecessary characters and shortening code.

Compression such as Brotli or gzip can reduce transfer size further.

Those techniques are useful, but they do not solve:

• Expensive execution.
• Unused code.
• Long tasks.
• Duplicate libraries.
• Unnecessary third-party scripts.

Prioritize architectural improvements before treating minification as the main optimization. Transfer-byte reductions matter, but JavaScript parse/evaluation and runtime work can remain expensive even after compression.

For transfer compression of JavaScript, CSS and HTML, use the Brotli & Gzip Compression Guide. Compression reduces bytes on the wire; it does not remove execution cost.

---

22. Do Not Self-Host Third-Party JavaScript Automatically

Self-hosting can improve control in some cases, but it can also create maintenance, security, licensing and update problems.

Before self-hosting a vendor script, verify:

• The vendor permits it.
• You have a reliable update process.
• You understand security implications.
• The performance benefit is measured.
• The integration will continue functioning correctly.

---

23. JavaScript SEO: Performance and Indexing Are Different Problems

JavaScript does not automatically make a page difficult for Google Search to process. On March 4, 2026, Google explicitly removed outdated documentation language that implied JavaScript-loaded content inherently makes Search access harder, noting that Google Search has rendered JavaScript for years.

Google currently describes JavaScript processing as crawling → rendering → indexing. Pages returning 200 are queued for rendering unless directives prevent indexing; non-200 responses may not be rendered. Googlebot also will not render JavaScript from pages or resources blocked by robots.txt. Server-side rendering, static rendering or hydration can still help performance and non-Google crawlers that do not execute JavaScript.

Important pages still need:

• Crawlable URLs and real crawlable <a href> links.
• Correct HTTP status codes.
• JavaScript/CSS resources required for essential rendered content that are not accidentally blocked.
• Consistent canonical signals.
• Useful rendered content that matches the page’s purpose.
• Navigation and internal links that remain discoverable after rendering.

If JavaScript sets a canonical URL, keep it consistent with the canonical in the original HTML. Google recommends HTML as the preferred place to set the canonical and warns against changing it to a different target during rendering. If the source HTML contains noindex, do not assume JavaScript can reliably remove it later—Google may skip rendering when it encounters the original noindex directive.

A JavaScript implementation can therefore be indexable while still providing a poor user experience because it ships too much code, creates long tasks or delays interaction feedback.

---

24. Blogger-Specific JavaScript Optimization

Blogger gives site owners less control over the server and build pipeline than a custom application or self-hosted WordPress site, but useful optimization opportunities still exist.

Audit Theme Scripts

Open the Blogger theme HTML and identify scripts added by the theme, custom modifications, widgets, analytics tools or past experiments.

Make a theme backup before removing or changing any script.

Audit Layout Gadgets

Widgets added through Blogger’s Layout interface can introduce scripts that load across many pages.

Remove unused gadgets and confirm whether each widget really needs to be site-wide.

Avoid Duplicate Libraries

A custom widget may include a library that the theme already loads. Duplicate versions increase network and execution cost and can introduce compatibility problems.

Load Page-Specific Features Only Where Needed

If a heavy script is used only on one page, avoid adding it globally in the theme when a page-specific implementation is possible.

Test Theme-Level defer Changes Carefully

Changing script attributes in a Blogger theme can affect every page and every template state. A global defer or async edit therefore needs functional testing before publication.

Test:

• Homepage.
• Article pages.
• Labels.
• Navigation.
• Search.
• Comments.
• Forms.
• Mobile layout.
• Analytics.
• Ads and monetization integrations.

Keep Essential Blogger Functionality Intact

Some scripts are platform-managed or tied to Blogger features, comments, widgets, consent/ads or theme behavior. Do not remove unfamiliar code merely because an audit shows JavaScript activity or because one Coverage session reports it as unused.

---

25. What Should You Optimize First?

---

26. Prevent JavaScript Performance Regressions

A JavaScript cleanup can be undone by the next theme update, marketing tag, plugin, experiment or feature release.

Set practical limits for JavaScript transfer size, third-party script count and long-task/runtime behavior, then verify important templates during releases. The Web Performance Budgets & Regression Monitoring Guide covers that ongoing process.

---

27. Safe JavaScript Optimization Workflow

1. Choose a representative page. Start with a high-traffic template or a page showing poor responsiveness.
2. Record a baseline. Save PageSpeed Insights field/lab context separately and capture a DevTools performance trace under repeatable lab conditions.
3. Inventory scripts. Identify first-party and third-party JavaScript and note each script’s purpose.
4. Find the biggest bottleneck. Prioritize unused scripts, long tasks, oversized bundles, parser-blocking scripts or interaction callbacks with expensive rendering work.
5. Make one meaningful change. Remove, defer, split, conditionally load, yield, or move suitable computation off the main thread.
6. Test functionality. Check menus, forms, search, consent, ads, analytics, affiliate tracking and comments.
7. Measure again. Repeat the same lab workflow.
8. Monitor field data. Core Web Vitals field data reflects real users and needs enough visits/time to accumulate; do not treat an immediate Lighthouse change as field validation.

---

28. Before-and-After Verification Checklist

• Record the URL, date and major change.
• Run PageSpeed Insights before and after.
• Check DevTools Network for script count, transfer and load order.
• Record a DevTools Performance trace for page load and representative runtime interactions.
• Review the Performance panel's current Insights findings where relevant.
• Inspect long tasks, their blocking periods and the functions/scripts responsible.
• Check whether interaction delay comes from input delay, callback processing or presentation delay.
• Inspect forced reflow/layout warnings when DOM reads and writes are mixed.
• Check Coverage after exercising important features.
• Verify navigation and mobile menus.
• Verify forms and search.
• Verify analytics and conversion measurement.
• Verify consent management where required.
• Verify ads without modifying restricted vendor code.
• Verify affiliate links and tracking flows.
• Check the browser console for new errors.
• Test on a real mobile device where practical.
• Monitor Core Web Vitals field data over time.

---

29. Common JavaScript Optimization Mistakes

• Deferring every script: dependencies and execution order can break.
• Chasing a perfect Lighthouse score: lab score and field Core Web Vitals are not the same thing.
• Removing code based only on Coverage: the tested session may not have triggered every feature.
• Optimizing transfer size while ignoring execution: a small script can still create expensive runtime work.
• Keeping every marketing tool forever: old third-party scripts accumulate over time.
• Loading page-specific features globally: one heavy component should not automatically become a cost for every article.
• Treating async as “never parser blocking”: download is asynchronous, but execution can interrupt parsing when the script becomes ready.
• Using dynamic import for one huge chunk: delayed code can still create a long evaluation task when the user needs it.
• Yielding after every tiny operation: excessive scheduling overhead can waste time without improving responsiveness.
• Moving DOM work to a Web Worker: workers cannot directly manipulate the page DOM.
• Assuming async/defer removes execution cost: they change loading/execution timing; expensive code can still create long main-thread tasks when it runs.
• Using noindex in source HTML and removing it with JavaScript: Google may skip rendering after seeing the original noindex directive.

---

30. JavaScript Performance Decision Matrix

---

31. JavaScript Performance and Server Response Time

JavaScript optimization cannot correct every performance bottleneck.

If the initial HTML document is slow to arrive, the browser cannot begin processing the page as early as it otherwise could.

Backend response time is a separate diagnostic layer. If your page spends too much time waiting before the first response bytes arrive, use the TTFB Optimization Guide rather than trying to solve server latency with frontend JavaScript changes.

---

Frequently Asked Questions

Does JavaScript hurt SEO?

JavaScript does not automatically hurt SEO. Google Search renders JavaScript, but pages still need crawlable URLs/resources, meaningful status codes, correct indexability/canonical signals, crawlable links and useful rendered content. Separately, excessive JavaScript can still hurt performance and user experience.

Is defer better than async?

Neither is universally better. defer waits until HTML parsing finishes and preserves script order. async is for independent scripts; its download does not block parsing, but execution can interrupt the parser as soon as the script is ready.

Should I use scheduler.yield() for long tasks?

It can be useful when a long sequence contains non-critical work that can continue in another task. Current compatibility is still limited across major browsers, so use feature detection or a fallback and do not yield after every tiny operation.

Are ES modules deferred automatically?

Yes. Scripts loaded with type="module" are deferred by default. Adding async changes the execution behavior.

When should I use a Web Worker?

Consider a worker for CPU-heavy JavaScript that does not need direct DOM access. Measure the messaging/serialization overhead and keep DOM updates on the main thread.

Should I remove all unused JavaScript reported by PageSpeed Insights?

No. Treat the report as an investigation starting point. Some code may be required only after an interaction or page state that the test did not exercise.

Can JavaScript cause poor INP?

Yes. Long tasks, heavy event callbacks, script evaluation, recurring timers and other main-thread work can delay interactions. JavaScript is not the only possible cause of poor INP, but it can be an important one.

Should I delay analytics scripts?

Only if the analytics provider supports the implementation and you understand the measurement trade-offs. Delaying analytics can change what gets recorded, so verify vendor guidance and validate data after any change.

Does minifying JavaScript improve Core Web Vitals?

It can reduce transfer size, but the real effect depends on the page. Minification does not eliminate expensive execution, unused code, long tasks or unnecessary third-party scripts.

Does better hosting fix JavaScript performance?

Not by itself. Hosting can improve backend response time, but it cannot automatically remove long JavaScript tasks, duplicate libraries, unnecessary third-party scripts or heavy client-side execution.

Should Blogger users edit every theme script?

No. Blogger themes can include platform-managed and theme-dependent scripts. Identify the purpose of a script, back up the theme and test all important functions before changing or removing it.

---

Final Takeaway

Effective JavaScript optimization is not about adding defer everywhere or chasing a smaller file at any cost.

Start by measuring what the browser downloads and what occupies the main thread.

Remove scripts that no longer provide value, avoid shipping page-specific code globally, use defer or async only when their execution model fits the script, split large bundles, lazy-load non-critical features and reduce long tasks that interfere with interactions.

The strongest improvements usually come from sending less code, executing less code and doing less main-thread work rather than trying to make unnecessary JavaScript slightly faster.

---

The Performance Optimization Series

JavaScript is one piece of the performance puzzle. The full series:

• CSS Performance Optimization: Reduce Render Blocking & Unused CSS
• Web Font Performance Optimization: Preload, font-display & CLS
• Preload, Preconnect & Fetchpriority: Resource Hints Optimization Guide
• Browser Caching Guide: Cache-Control, max-age, ETag & 304
• WebP Image Optimization for WordPress: Quality, AVIF & LCP
• Cumulative Layout Shift (CLS): Causes, Debugging & Optimization