1 Introduction

In the internet era, webpage loading speed has become a key factor affecting user experience and SEO rankings. Among these, TBT (Total Blocking Time) is an important metric for measuring webpage performance.

---

TBT measures the time during webpage loading when the browser is unable to respond to user interaction due to script execution. Obviously, the main factor affecting TBT is the JavaScript scripts on the webpage: the browser needs to load and execute all JS scripts to complete page rendering and load other content (CSS also affects rendering, but to a lesser extent compared to JS). Therefore, the greater the number and complexity of scripts (and CSS) on a webpage, the more likely the loading completion time will be affected.

---

In the figure below, the TBT exceeds 710 milliseconds, directly causing a significant drop in Google's PageSpeed Insights score:

Conversely, when the TBT is low, the score rises significantly. In the figure below, while other parameters remain similar to those in the figure above, after the TBT is significantly reduced to 90 milliseconds, the score directly increases to 80. This shows how important TBT is in Google's eyes:

---

Note: PageSpeed Insights' scoring criteria are actually not very friendly to sites using CDNs. The proof is that scores from consecutive tests can vary greatly. This is because the CDN's caching mechanism and geographical distribution affect the website's loading time. At different testing moments, PageSpeed Insights retrieves resources from different server nodes, and the response speeds of these nodes vary due to network conditions, CDN cache updates, or regional differences. Therefore, score fluctuations are very common, especially when the site's resources rely on external CDNs. Thus, it is best to test multiple times and take the highest score (actually, looking at the average score is relatively more accurate).

As a side note, although building a website directly on a VPS with good connectivity is highly likely to yield a higher PageSpeed Insights score, running a site "naked" (without protection) on the internet is really not recommended.

---

For websites built with WordPress (taking my own blog as an example), the core function of many plugins is actually to insert scripts, such as Google Analytics (traffic analysis), Disqus comment plugin (third-party comment system), Instant.page plugin (preloading content by monitoring mouse hover), etc. In addition, there are other tools with similar functions, such as Umami (website traffic statistics), which also work by inserting front-end scripts into the website code while pairing them with back-end services.

These inserted scripts (whether dynamically generated by plugins or directly embedded in the source code) can negatively impact webpage loading performance. Especially when multiple scripts load in parallel, they consume browser computing resources, delay page rendering, and increase TBT (the webpage cannot respond to user actions before all JavaScript execution is complete). Furthermore, these scripts consume a lot of threads and memory, which may reduce page interactivity, especially on low-performance devices or in poor network environments, affecting the user experience.

So, if we could decouple these insertion scripts from the webpage's own loading process and have them loaded and managed by the cloud, we could theoretically reduce page main thread blocking, optimize script loading order, achieve asynchronous loading, and thereby reduce the browser's burden. In this way, we can not only speed up the resource loading process but also reduce the impact on page rendering, effectively lowering TBT.

So, is there a way to move these insertion-type scripts to the cloud? Yes, and that is Cloudflare's Zaraz.

2 Cloudflare Zaraz Deployment

1 Introduction to Zaraz

Cloudflare Zaraz is a service that manages and accelerates third-party scripts and code through Cloudflare's edge network. It allows website administrators to decouple multiple external scripts (such as analytics, ads, social sharing, etc.) from the webpage's loading process and execute them via Cloudflare's edge network (the principle is: for the browser, whether a script is loaded from the webpage code or pushed in from somewhere else makes no difference).

Zaraz Advantages:

Centralized Management

Zaraz makes website script management more centralized and efficient. Especially when integrating multiple third-party scripts (such as Google Analytics, Google AdSense, Umami, instant.page, etc.), users can easily manage and optimize the loading of these scripts on Cloudflare's edge network through Zaraz, avoiding the old issue of completely forgetting what scripts were running and where they were inserted after some time.

Asynchronous Loading

The core advantage of Zaraz lies in ”asynchronous loading,” which prevents scripts from blocking page rendering, thereby improving the visitor's subjective experience, especially regarding above-the-fold loading speed. Even if the loading speed is slower in certain regions without Cloudflare data centers, Zaraz can still reduce the negative impact on user experience by ensuring page content is rendered with priority. In addition, Zaraz can effectively optimize performance scores like PageSpeed Insights, helping websites improve their overall performance (although in regions without Cloudflare data centers, Zaraz may cause slightly longer loading times due to network latency, its asynchronous loading design minimizes the impact on page rendering, keeping the overall user experience positive).

2 Introduction to Zaraz Configuration Templates

Cloudflare Zaraz provides some common third-party script insertion configuration templates by default, as shown in the figure below:

And the most critical one is the ”Custom HTML” configuration template in the red box in the figure above, which allows you to insert custom HTML code 或 JavaScript code into the page, through the Custom HTML plugin. ”Theoretically,” you can inject any HTML or JavaScript code into the page without directly modifying WordPress theme files! Doesn't that sound pretty awesome?!

With Zaraz, WordPress websites can achieve more efficient performance optimization, reduce reliance on redundant plugins, simplify code management, and maintain high flexibility and scalability.

Therefore, in this article, I will sort through the various code-insertion plugins and scripts in my current WordPress blog and migrate all suitable scripts to Zaraz.

3 Identifying Insertion Scripts Suitable for Migration to Zaraz

When loading a page normally, if you use developer tools, you can see that numerous JS and CSS files are loaded:

Theoretically, all of these can be migrated and managed through Zaraz . Zaraz can centrally manage and optimize these inserted codes, reducing their impact on page loading, especially for asynchronous loading 和 and lazy loading optimization.

However,Completely migrating all CSS and JS to Zaraz is not realistic for several reasons:

Boundaries of performance and loading optimization:

• Zaraz It mainly targets third-party code 或 and scripts, such as Google Analytics、Ad scripts、Webmaster tools etc. For most Custom theme or plugin scripts, which usually play a more important role during the page loading process. Migrating them to Zaraz may affect their normal execution, especially some scripts that must execute before the DOM is fully loaded(such as certain CSS styles, critical JS functions).

The specificity of custom CSS and JS:

• The website's local CSS and JS(especially involving theme styles, interactive effects, etc.) are usually critical rendering path part of, and these files may need to be loaded as early as possible to ensure proper rendering of the page. Placing them on Zaraz may cause their loading to be delayed, thereby affecting the user's first paint experience.

Zaraz's positioning and scope of application:

• Zaraz More suitable for centralized management of third-party scripts, such as Google Fonts、Ad scripts、analytics scripts etc. For these scripts, Zaraz, through asynchronous loading 和 and lazy loading , optimizes performance.

• For local theme or plugin CSS/JS files, it is recommended to keep them loading on the origin server or CDN, especially for those files that are crucial for page rendering.

Summary:

• Migrating third-party scripts(such as Google Analytics, ads, webmaster tools, etc.) to Zaraz is beneficial for performance, especially in asynchronous loading 和 centralized management where there is significant optimization.

• For Local theme or plugin CSS and JS files, migrating to Zaraz may affect the loading order and critical rendering path, so it is recommended that these files be kept on the origin server or CDN。

Based on the above principles, I finally decided to migrate the functions of the following 4 injected scripts to Zaraz using asynchronous loading, with the standard of minimizing the blocking impact on page rendering:

Font Awesome plugin (Free), using the ”Custom HTML” template, corresponding CDN URL:

https://kit.fontawesome.com/xxxxxxxxxx.js

Font Awesome's icon fonts are visual elements of the page, but relatively speaking, icon fonts are not that conspicuous, so even if loaded asynchronously, the impact is not significant.

Note: The xxxxxxxxxx in xxxxxxxxxx.js is your Font Awesome account ID.

Umami, using the ”Custom HTML” template, corresponding URL:

https://umami.tangwudi.com/tangwudi

Umami is a third-party analytics tool for page traffic, unrelated to page rendering, and can be loaded asynchronously at the very end of the page.

Google AdSense, using the ”Custom HTML” template, corresponding URL:

https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=xxxxxxxxxxxxxxx" crossorigin="anonymous

Ads are usually loaded after the page renders to avoid interfering with the fast display of the page, so they can also be loaded asynchronously at the very end of the page.

Note 1: The xxxxxxxxxxxxxxx in the above address isGoogle AdSense account's ”Publisher ID”

Note 2: Zaraz only has a Google Ads template, and that one is for advertisers.

Google Analytics, using Zaraz's official template

The handling of the Google Analytics script is not exactly the same as other scripts and needs to be judged based on the scenario: If you have high requirements for the real-time performance and accuracy of Google Analytics (such as relying on Google Analytics to collect user behavior data in real-time to optimize ad delivery, conduct A/B testing, or adjust strategies in real-time), it is recommended to place it early in the page load. Although this will slightly affect page performance, it ensures that data is collected and analyzed accurately and timely, avoiding data loss or errors caused by delays, which in turn affects decision-making and optimization results. On the other hand, if you do not have high requirements for real-time performance, or do not care much about the immediacy of data (such as a personal blog), you can use Zaraz to load Google Analytics asynchronously, thereby reducing its interference with page rendering and improving page load speed (suitable for sites with high performance requirements).

---

Actually, at the very beginning, I also wanted to migrate the instant.page JS script to Zaraz, but on second thought, it was not appropriate: Instant.page relies on loading and executing the script as early as possible to speed up the user experience by preloading the pages about to be visited, which requires the script to start executing before the page DOM is fully loaded. However, Zaraz loads scripts asynchronously and may cause the execution order to be inconsistent with expectations, thereby affecting the triggering timing of Instant.page and consequently its effectiveness. In addition, Zaraz does not guarantee instant execution, which conflicts with Instant.page's sensitivity to timing, so in the end, I gave up on the migration.

---

4 Officially Starting the Migration

4.1 Migrating Font Awesome to Zaraz

Previously, I installed the Font Awesome plugin (Free account) directly in WordPress. The implementation method of this plugin was in the header.php file of WordPress.<head>Insert the CDN link provided by Font Awesome and the JS named after your Font Awesome account ID into the tag:

<script src="https://kit.fontawesome.com/xxxxxxxxxx.js" crossorigin="anonymous"></script>

As shown in the figure below:

After migrating to Zaraz, you still use this script (Zaraz does not provide a ready-made template for FontAwesome), but you need to add the defer parameter so that it executes after the HTML parsing is complete. This ensures that page loading will not be blocked. The final script is as follows:

<script defer src="https://kit.fontawesome.com/xxxxxxxxxx.js" crossorigin="anonymous"></script>

Just follow the step-by-step image tutorial below for the specific steps:

Take the CDN address corresponding to the Font Awesome plugin in section 2.3 of the article as a<script>tag format:

<script defer src="https://kit.fontawesome.com/xxxxxxxxxx.js" crossorigin="anonymous"></script>

Fill it into the HTML Code box in the image below:

Finally, the configuration is complete:

After that, disable the Font Awesome plugin locally in WordPress, and delete the line of code inserted by the plugin in WordPress's ”header.php” file (note that for plugins that directly insert code into theme files to achieve functionality, disabling the plugin will not automatically delete the code inserted in the theme files, so manual operation is required), then clear the browser cache (if a CDN is used, it is best to clear the CDN cache as well) and reload. Filter for the word "zaraz" in the developer tools, and you can see the following results:

At the same time, the Font Awesome-related scripts still load normally just as they did when using the Font Awesome plugin before:

4.2 Migrating Umami to Zaraz

Recreate a new tool Umami, and repeat the process of the first part. The corresponding HTML Code is as follows:

<script defer src="https://umami.tangwudi.com/tangwudi" data-website-id="填写自己umami站点的ID" data-domains="填写自己站点的域名"></script>

The final part of adding actions is shown in the image below:

Then, as before, delete the Umami script code from the original site, clear the browser cache (if a CDN is used, it is best to clear the CDN cache as well) and reload. Finally, confirm in the ”Network” tab of the developer tools that the Umami script is still loading normally:

4.3 Migrating Google AdSense to Zaraz

Recreate a new tool Google AdSense, and repeat the process of the first part. The corresponding HTML Code is as follows:

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxxxxxxxxxxx" crossorigin="anonymous"></script>

The final operation part is as follows:

Then, as before, delete the Google AdSense script code from the original site, clear the browser cache (if a CDN is used, it is best to clear the CDN cache as well) and reload. Finally, confirm in the ”Network” tab of the developer tools that you can still see the publisher ID:

4.4 Migrating Google Analytics 4 to Zaraz

My previous Google Analytics 4 functionality relied on the Rank Math SEO plugin. Since Google Analytics 4 has a ready-made configuration template in Zaraz, I won't use the ”Custom HTML” catch-all method this time (no point in wasting a ready-made one), but will switch to using the official configuration template instead. Follow the graphic process below:

Configuration complete:

After that, turn off the Google Analytics 4-related features in Rank Math, then clear the cache (if a CDN is used, it is best to clear the CDN cache as well) and reload.

---

The Google Analytics 4 Measurement ID can be obtained from the following location on the Google Analytics dashboard:

---

After completing all configurations, all third-party tools on Zaraz are as follows:

Note: Actually, you could also add just one third-party tool and then add each script as an action within that single third-party tool. However, this usually doesn't make much sense (unless there are special requirements), and it looks much cleaner to create a new third-party tool for each script.

3 Other Settings

In the ”Settings” tab of Zaraz, there are general settings and advanced settings:

Meanwhile, you can also see the usage of Zaraz under the ”Monitoring” tab:

4 Summary

Migrating third-party scripts to Zaraz can bring multiple benefits: First, it simplifies script updates and modifications through centralized management, avoiding the trouble of finding and modifying scripts in multiple theme files; second, Zaraz's asynchronous loading method helps reduce blocking time during page loading, significantly improving page performance and user experience. For example, after migrating the 4 third-party scripts mentioned earlier in the article to Zaraz, my blog's PageSpeed Insights score improved again, and the TBT time was further reduced to 50 milliseconds (TBT ≤ 50 ms: usually considered excellent, indicating very good interactivity during page loading):

Most importantly, another key metric, ”Eliminate render-blocking resources,” has now been reduced to the absolute minimum:

This shows that the strategic goal of ”migrating third-party scripts to Zaraz to reduce blocking of the page's main thread” has been fully achieved.

---

“Eliminate render-blocking resources” usually refers to JavaScript and CSS files that block page rendering, or resources that must wait for these files to load and execute before the page can continue rendering. If this item shows 0 ms, it means that in Google's view:
* The loading order of all resources on the page has been optimized (for example, using async or defer to load scripts).
* Page rendering is no longer blocked by the loading order of external resources, allowing users to see the page content faster.
* Appropriate strategies (such as through Cloudflare Zaraz, asynchronous loading, etc.) have been adopted to reduce blocking resources.

---

In addition, Zaraz can also help sites corresponding to multiple subdomains under the same second-level domain share script configurations (for example, if you need to load the same script on multiple subsites at the same time, you now only need to load it once on Zaraz, except of course for scripts bound to specific access domains), thereby improving maintenance efficiency and facilitating the optimization of script loading timing and performance by providing detailed debugging and statistical tools.

However, as mentioned before, Zaraz is only suitable for running some third-party scripts that do not directly affect the rendering of core page content, and it is not a silver bullet. Therefore, everyone must carefully weigh their options when choosing scripts to migrate to Zaraz, otherwise improper choices may lead to counterproductive results.

In addition, the Zaraz free plan provides an allowance of 1 million events per month, which is more than enough for personal sites~~: