Reducing Total Blocking Time with Deferred and Async JavaScript Loading

Deferred JavaScript loading is a method of reducing Total Blocking Time (TBT) by properly delaying JavaScript files that block the browser from rendering page content. In short, by adding defer or async to non-critical script files, you allow the main thread to be blocked less; thus, users see the page faster, can click earlier, and the Core Web Vitals metrics improve. To implement deferred JavaScript loading on your site, you first need to identify which files are critical, typically prefer defer for scripts with dependencies, and mostly async for independent third-party scripts. After making these changes, you should measure TBT values using tools like PageSpeed Insights, Lighthouse, and Chrome DevTools.

In modern websites, performance issues often stem not from images but from uncontrolled JavaScript usage. If an e-commerce site loads product filters, live chat, ad pixels, analytics codes, comment plugins, A/B testing tools, and theme scripts all at once, the browser's main thread can become occupied for extended periods. This situation is particularly evident on mobile devices. Even if a user sees the title on the screen, they may not receive a response when tapping the menu; in Lighthouse reports, Total Blocking Time appears high.

In this guide, we will cover what the defer and async attributes do, when to use each, how to implement them in WordPress and custom software projects, what to pay attention to during measurement, and realistic TBT gains step by step. Recommendations for sites hosted on the Hostragons infrastructure align with general web standards; we will also discuss how the right hosting, CDN, SSL, and caching decisions support JavaScript optimization. Hostragons Web Hosting Packages

What is TBT and Why is it Closely Related to JavaScript?

TBT stands for Total Blocking Time and measures the blocking of the main thread that delays the page from becoming ready for user interaction. In Lighthouse lab tests, a high number of long tasks exceeding 50 milliseconds between First Contentful Paint and Time to Interactive increases the TBT value. For example, if a JavaScript task takes 180 ms, 130 ms of that contributes to the blocking time after the first 50 ms.

This metric is critical from a user experience perspective. If a visitor taps on the menu, add to cart button, or search box after the page opens, and the browser is still executing JavaScript, the interaction is delayed. Users interpret this as freezing, slow response, or a broken site. In the 2026 SEO standards, while Google does not reduce page experience to a single score, sites that offer fast and stable interactions gain advantages in both user satisfaction and conversion rates.

Common Signs of High TBT Values

• TBT value exceeds 300 ms in mobile PageSpeed Insights reports.
• Seeing warnings in Lighthouse reports like "Reduce JavaScript execution time" or "Minimize main-thread work."
• Menu, slider, filters, or form fields responding late even though the page is visible.
• High cost of third-party ads, live chat, or analytics scripts in reports.
• Scrolling and clicking delays, especially on entry-level Android devices.

As a good target, keeping the TBT value below 200 ms is considered healthy for most content sites. In more complex e-commerce or SaaS interfaces, achieving this goal may require more than just defer and async; code splitting, removing unnecessary packages, improving server response time, and critical CSS adjustments may also be necessary. Still, deferred JavaScript loading is one of the first optimizations to be implemented in most projects that will yield quick results.

What are Defer and Async?

When a script tag is used in HTML without any attributes, the browser halts HTML parsing, downloads the JavaScript file, executes it, and then continues rendering the page. This behavior is sometimes necessary for critical scripts; however, when used for every file, it creates unnecessary waiting. The defer and async attributes change this behavior by tying the downloading and execution of the file to different rules.

How Does Defer Work?

A script file added with defer is downloaded in the background while HTML parsing continues; however, its execution occurs after the HTML document has been parsed. Additionally, multiple files using defer maintain the order in which they are written in HTML. Therefore, it is often a safe choice for JavaScript files that depend on each other. For instance, if a library is loaded first, followed by a theme script that relies on it, defer would be appropriate.

An example usage would look like this: <script defer src=/js/app.js></script>. In this case, the app.js file is downloaded without blocking the initial rendering of the page and executed in order when the DOM is ready. Modern browsers widely support defer, making it a reliable optimization tool for traditional script files.

How Does Async Work?

A script added with async is also downloaded while HTML parsing continues; however, it is executed as soon as the downloading is complete. During this time, HTML parsing may halt briefly. async does not guarantee order between files; the first one downloaded executes first. Therefore, it is more suitable for independent analytics, advertising, tracking pixels, external widgets, or social media scripts.

Example usage: <script async src=/js/analytics.js></script>. This file should not wait for another local script to run first. If analytics.js depends on a variable defined later in the page or another library like jQuery, using async could lead to errors. Therefore, while async is fast, it requires careful classification.

Comparison Table of Defer and Async

The practical rule is this: If your file must run in order, start with defer. If your file is completely independent, consider async. If you are unsure, first experiment with defer in a staging environment, test console errors, and critical interactions. Staging Environment and Backup Guide

Step-by-Step Implementation Plan for Deferred JavaScript Loading

Randomly adding defer or async to every script tag may seem to boost scores in the short term, but it can disrupt critical functions like payment, search, menus, form validation, or cart on a production site. A healthy implementation should follow a measurement, classification, small changes, testing, and monitoring cycle.

1. Measure Current Performance

Establish a baseline before you start. Record mobile and desktop scores with PageSpeed Insights. Note TBT, First Contentful Paint, Largest Contentful Paint, and Speed Index values in the Lighthouse report. Examine the main thread in Chrome DevTools Performance tab; long yellow blocks often indicate the costs of JavaScript parsing, compiling, and execution.

You can prepare a sample starting table: mobile TBT 780 ms, JavaScript execution time 2.8 seconds, main-thread work 4.5 seconds. If after optimization your mobile TBT drops to 280 ms, you will have achieved approximately a 64% improvement. Such tangible records make it easier for the team to see which changes worked.

2. Create a Script Inventory

List all JavaScript files loaded from the page's source code or the Network tab. Identify the source, size, when each is needed, and their dependencies. Grouping the files can simplify your work:

• Critical scripts: Code that is immediately necessary for the initial view or basic navigation.
• Dependent local scripts: Theme, slider, filter, gallery, and application modules.
• Independent third-party scripts: Analytics, ads, pixels, chat, and social media components.
• Unnecessary or old scripts: Files leftover from unused plugins.
• Conditionally loaded scripts: Those needed only on specific pages, such as form validation on the contact page.

Sometimes the best optimization is not to add defer but to remove an unnecessary script altogether. A 90 KB compressed file can generate costs exceeding 300 ms on mobile devices when parsing and execution are included. Therefore, it's better to clean up what is unnecessary first and then delay the remaining files.

3. Identify Files for Defer Implementation

Generally, main theme scripts, menu behaviors, slider codes, product gallery modules, and application bundle files are good candidates for defer. However, an important condition here is that the script should not be overly dependent on old blocking methods like document.write and that it is acceptable for it to run after the DOM is ready.

A WordPress theme may have jQuery migrate, the main theme file, and plugin scripts that contain complex dependencies. Making the jQuery core async can be risky for most sites; many plugins expect jQuery to load in order. Instead, it is safer to apply controlled defer to files dependent on jQuery or to use optimized loading options at the plugin level. WordPress speed optimization guide

4. Choose Files for Async Implementation

Google Analytics, ad tags, Facebook Pixel, LinkedIn Insight Tag, some external chat widgets, and social sharing codes are candidates for async. However, not all third-party scripts are the same. Some live chat tools may want to create a user session as soon as the page loads, while some advertising systems may expect a specific container's order. Therefore, it is essential to check the documentation.

Making an independent analytics code async usually does not harm user experience. Nevertheless, to reduce the risk of data loss, check for trigger conditions in real-time reports. If you are using a tag manager, organize trigger conditions instead of lumping all tags into a single container. For example, a comment tracking script should not load on pages without a comment form, and a product interaction script should not load on pages that are not product pages.

5. Add Conditional and Event-based Loading

Using defer and async is a good start; however, loading JavaScript files based on user behavior can have a more significant impact on TBT. A live chat box can load not as soon as the page opens, but when the user has stayed for 5 seconds or clicks the help button. Embed code for maps can load when the user scrolls to the contact section. A video player script can be called when the user presses the play button.

This approach is particularly effective for content sites and corporate websites. Because a visitor doesn't need every widget on every page. Removing 200 KB of JavaScript from the initial load can reduce TBT values by hundreds of milliseconds on weak mobile processors.

6. Test and Gradually Roll Out

Instead of applying changes directly to the live site, experiment in a testing environment. Conduct manual tests on critical pages like the homepage, category page, product or service page, contact page, login form, and checkout flow. Check for errors in the browser console. Especially errors like "Cannot read property," "is not defined," and "undefined function" indicate sorting or dependency issues.

Proceed in small groups when moving to live. First, optimize independent third-party scripts, then move on to theme scripts. After each change, repeat the Lighthouse report using the same network and device simulation. Do not rely on a single measurement; averaging three tests yields healthier results.

Notes on Implementing Defer and Async in WordPress Sites

In the WordPress ecosystem, JavaScript files are loaded via the wp_enqueue_script function through themes and plugins. By 2026, modern WordPress versions can define script strategies more controlled. However, older themes, page builder plugins, and incompatible optimization plugins may cause conflicts.

If you are using a performance plugin, instead of deferring all JavaScript with a single click, create an exclusion list. Payment pages, membership logins, admin toolbar, authentication, and captcha scripts can be sensitive. On a site using WooCommerce, cart fragments, payment gateway scripts, and variation selectors must be thoroughly tested. WooCommerce Hosting Solutions

A practical ordering for WordPress might be: first remove unused plugins. Then conditionally load plugin files that are necessary only on specific pages. Next, experiment with defer in theme and plugin scripts. Finally, use async or deferred loading on independent third-party codes. This method reduces the risk of experiencing significant breaks all at once.

Considerations for Custom Software and Framework Projects

JavaScript optimization in modern frameworks like React, Vue, Angular, Next.js, or Nuxt is not merely about adding defer to HTML tags. Package size, code splitting, tree shaking, dynamic importing, and hydration costs are critical to TBT. If a single large bundle file is 700 KB, even using defer, the main thread may still be blocked for an extended period during execution.

In custom software projects, use route-based code splitting. When the user is on the homepage, the admin panel, graphics library, or advanced editor code should not be downloaded. Heavy components should be called dynamically as needed. Identify unused dependencies using package analysis tools. Consider lighter alternatives instead of large date, graphics, or animation libraries.

Projects using server-side rendering or static generation should also be cautious. Even if HTML arrives quickly, activating hundreds of components simultaneously during hydration can increase TBT values. Avoiding unnecessary client-side JavaScript in non-interactive content is central to the performance approach of 2026.

The Relationship Between Hosting, Server Response Time, and JavaScript Performance

TBT is directly related to the time it takes for JavaScript to execute in the browser; however, hosting infrastructure indirectly affects the results. Slow TTFB, lack of compression, absence of HTTP/2 or HTTP/3 support, poor caching, and latency due to distant locations can cause JavaScript files to arrive later. When files arrive late, the page lifecycle extends and the user experience deteriorates.

A quality hosting infrastructure supports optimization with Brotli or Gzip compression, effective browser caching, up-to-date PHP versions, fast disk technology, and CDN integration. Proper installation of the SSL certificate is also crucial for modern browser features, HTTP/2, and secure third-party integrations. Hostragons SSL Certificates Hostragons Domain Lookup

For example, the same JavaScript file may be 320 KB without compression, but can drop to around 95 KB with Brotli. This does not directly reduce the TBT value by the same proportion; because TBT measures execution costs. However, download time shortens, resource prioritization eases, and the overall loading experience improves. Therefore, defer, async, caching, and correct hosting should be considered together.

Measurement and Validation Checklist

To determine whether the optimization was successful, looking only at the PageSpeed score is not sufficient. The following checklist helps you evaluate the real impact more accurately:

• Was the mobile TBT value compared before and after optimization?
• Did the most costly files decrease in the JavaScript execution time report?
• Did the number of long tasks drop in the Chrome DevTools Performance recording?
• Are there any JavaScript errors in the console?
• Do the menu, search, filter, form, cart, and payment flows work smoothly?
• Are third-party analytics and advertising tags firing correctly?
• Are INP and interaction delay improving in real user data?
• Were the changes retested after clearing the cache?

A key point here is to distinguish between lab and field data. TBT is a Lighthouse lab metric. In real user experience, Interaction to Next Paint (INP) has become more decisive. However, a drop in TBT often contributes to an improvement in INP, as there is less blocking in the main thread.

Common Mistakes and How to Avoid Them

Making all scripts async at once

This is one of the most common mistakes. Since async does not guarantee order, it can create random errors in dependent files. A structure that appears smooth on one page may break on a slow connection or a different browser. Using defer in files with dependencies is a safer starting point.

Wrongly deferring jQuery and dependent plugins

Especially on WordPress sites, many plugins rely on the order of jQuery. Making the jQuery core async can result in plugin codes executing before jQuery loads. The solution is to visualize the dependency network and add critical files to the exclusion list.

Leaving third-party scripts uncontrolled

A site owner might forget to optimize ad, chat, and analytics codes while optimizing their own theme files. However, in Lighthouse reports, the heaviest tasks often come from third-party sources. Removing unused tags, triggering conditionally, and deferring when necessary can provide significant gains.

Installing plugins without measurement

Performance plugins can be beneficial; however, each additional tool used without measurement can bring new JavaScript and CSS loads. First, diagnose the problem, then choose the tool. Validate with test reports that the plugin actually reduces TBT.

Ignoring caching and minification conflicts

If minification, concatenation, defer, and async are applied simultaneously, the file order may change. This situation can cause unexpected errors in the production environment. Especially if CDN, server caching, and application caching are used together, clear all layers after changes.

A Realistic Optimization Scenario

Let's assume a medium-sized corporate website has 18 JavaScript requests on the homepage. Of these, 5 are for theme and menu behaviors, 4 for sliders and animations, 3 for forms and maps, and 6 for analytics, pixels, and live support codes. The initial Lighthouse mobile TBT value is measured at 920 ms.

In the first step, two unused animation plugins are removed, reducing the compressed JavaScript load by 140 KB. TBT drops to 760 ms. In the second step, theme and slider files are deferred; dependency order is tested. TBT becomes 480 ms. In the third step, the map script is loaded only when scrolled to the contact section, live support is initiated 7 seconds later, and analytics and pixel codes are made async. The final measurement shows TBT drops to 210 ms.

This scenario demonstrates the importance of a layered approach rather than a single magic setting. defer and async are powerful tools; however, the best results are achieved together with removing unnecessary code, conditional loading, proper caching, and quality infrastructure.

Conclusion: A Balanced and Tested JavaScript Strategy for Lower TBT

Implementing deferred JavaScript loading on your site is one of the most practical and effective ways to reduce TBT. defer offers a safe solution for scripts that should run in order and after the DOM is ready; async is ideal for flexibly loading independent third-party scripts. For successful optimization, you should first measure, classify scripts, remove unnecessary files, gradually test changes, and monitor real user experiences.

Using a fast, secure, and scalable infrastructure on Hostragons helps you achieve a more stable web performance alongside JavaScript optimization, caching, and SSL configurations. If you want to improve your site's TBT value, start by extracting your current report and then proceed with small but measurable steps. You can explore Hostragons solutions for suitable hosting and performance infrastructure. Hostragons Web Hosting Packages

Frequently Asked Questions

Can defer and async be used together?

If defer and async are used together in a classic script tag, modern browsers may prioritize async; this eliminates the order guarantee. Therefore, it is not recommended to use both in the same file in practice. It is safer to choose defer for dependent files and async for independent files.

Does deferred JavaScript loading directly increase SEO rankings?

It does not guarantee direct ranking improvement on its own; however, it supports SEO success by improving page experience, interaction speed, and Core Web Vitals performance. Faster responding pages can enhance user satisfaction, conversion, and perceived crawl quality.

Is it safe to add defer to every JavaScript file?

No. Some scripts may need to run during the initial phase of the page or may depend on certain files loading in order. Therefore, the purpose, dependencies, and execution time should be checked for each file; changes should be tested in a staging environment.

Are defer and async sufficient to reduce TBT?

They can provide significant improvements for small to medium-sized sites; however, sites using heavy frameworks, containing numerous third-party codes, or having large bundle files may require additional measures. Code splitting, removing unused JavaScript, conditional loading, caching, and robust hosting infrastructure should be addressed together.

Which scripts should I avoid making async on a WordPress site?

Plugin files dependent on jQuery, payment and cart scripts, form validation, authentication, and critical theme functions should not be made async randomly. If the order is disrupted in these files, user operations may be hindered. defer should be tested first, and an exclusion list should be created if necessary.