1 Introduction

In the Internet age, web page loading speed has become a key factor affecting user experience and SEO ranking. Among them, TBT (Total Blocking Time) is an important indicator to measure web page performance.

---

TBT measures the time that the browser is unable to respond to user interactions while loading a web page due to script execution. Obviously, the main factor affecting TBT is the JavaScript scripts in the web page: the browser needs to load and execute all JS scripts to complete the rendering of the page and the loading of other content (CSS also affects rendering, but the impact is less than JS). Therefore, the higher the number and complexity of scripts (and CSS) on the web page, the more likely it is that the time to complete the loading will be affected.

---

In the figure below, the TBT time exceeds 710 milliseconds, which directly leads to a significant drop in Google’s PageSpeed Insights score:

When the TBT time is short, the score rises significantly. In the figure below, when the other parameters are similar to the figure above, the score rises directly to 80 after the TBT is greatly reduced to 90 milliseconds. This shows how important TBT time is in the eyes of Google:

---

Note: PageSpeed Insights' scoring criteria are not friendly to sites that use CDN. The evidence is that the scores of consecutive tests may vary greatly. This is because the CDN's cache mechanism and geographical distribution will affect the loading time of the website. At different test times, PageSpeed Insights will obtain resources from different server nodes, and the response speed of these nodes will 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, so it is best to test several times and take the highest score (in fact, the average score is relatively accurate).

One more thing to say, although it is possible to get a higher PageSpeed Insights score directly by building a website directly with a VPS with good connectivity, it is really not recommended to run naked on the Internet.

---

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 (preload content by monitoring mouse hover), etc. In addition, there are some tools with similar functions, such as Umami (website visit traffic statistics), which are also implemented by inserting front-end scripts in the website code and matching back-end services.

These inserted scripts (whether dynamically generated by plug-ins or directly embedded in the source code) may have a negative impact on the performance of web page loading, especially when multiple scripts are loaded in parallel, they will occupy browser computing resources, delay page rendering, and increase TBT time (the web page cannot respond to user operations before all JavaScript is executed). In addition, these scripts consume a large number of threads and memory, which may cause the interactivity of the page to decrease, especially in low-performance devices or network environments, affecting the user's access experience.

So, if we can separate these inserted scripts from the loading process of the web page itself and load and manage them in the cloud, theoretically we can reduce the blocking of the main thread of the page, optimize the script loading order and achieve asynchronous loading, thereby reducing the burden on the browser. In this way, we can not only speed up the resource loading process, but also reduce the impact on web page rendering, thereby effectively reducing TBT time.

So, is there a way to put the insertion script in the cloud? Yes, that is Cloudflare's Zaraz.

2 Cloudflare Zaraz deployment

2.1 Introduction to Zaraz

Cloudflare Zaraz is a service that manages and accelerates third-party scripts and code through the Cloudflare edge network. It allows website administrators to strip multiple external scripts (such as analytics, advertising, social sharing, etc.) from the loading process of the web page and execute them through Cloudflare's edge network (the principle is: for the browser, it doesn't matter whether the script is loaded from the web page code or from somewhere else).

Zaraz Advantages:

1. Centralized management

Zaraz makes website script management more centralized and efficient, especially when multiple third-party scripts need to be integrated (such as Google Analytics, Ggoogle AdSense, UMami, instant.page, etc.). Users can easily manage and optimize the loading of these scripts on the Cloudflare edge network through Zaraz, and never forget what script was run and where the script was inserted after a while as before.

2. Asynchronous loading

Zaraz's core advantage lies in "asynchronous loading", which avoids scripts blocking page rendering, thereby improving visitors' subjective experience, especially in terms of first screen loading speed. Even if the loading speed is slow in some areas without Cloudflare data centers, Zaraz can still reduce the negative impact on user experience by ensuring that page content is rendered first. In addition, Zaraz can also effectively optimize performance scores such as PageSpeed Insights to help websites improve their overall performance (although in areas without Cloudflare data centers, Zaraz may take a little longer to load due to network latency, but due to its asynchronous loading design, this has little impact on page rendering, and the overall user experience is still positive).

2.2 Introduction to Zaraz configuration template

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

The most important thing is the "Custom HTML" configuration template in the red box above, which allows you to Custom HTML code or JavaScript The code is inserted into the page through Custom HTML Plugins, "theoretically", allow you to inject any HTML or JavaScript code into a page without directly modifying the WordPress theme files! This sounds pretty cool, right? !

With Zaraz, WordPress websites can achieve more efficient performance optimization, reduce dependence on redundant plug-ins, simplify code management, while maintaining a high degree of flexibility and scalability.

So, in this article, I will sort out the various code insertion plug-ins and scripts in WordPress where the current blog is located, and migrate all the scripts suitable for migration to Zaraz.

2.3 Sort out the insertion scripts suitable for migration to Zaraz

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

In theory, these can be achieved through Zaraz Zaraz can centrally manage and optimize the code of these inserted classes to reduce their impact on page loading, especially for Asynchronous loading and Lazy Loading Optimization.

However,Completely migrate all CSS and JS It is not realistic to go to Zaraz for the following reasons:

1. The boundaries of performance and load optimization:

• Zaraz Mainly targeting third parties Code or script,For example Google Analytics,Advertising script,Webmaster Tools For most Customized themes or plugin scripts, they usually play a more important role in the page loading process, and migrating to Zaraz may affect their normal execution, especially some Scripts that must be executed before the DOM is fully loaded(such as certain CSS styles, key JS functions).

2. Peculiarities of custom CSS and JS:

• Website Local CSS and JS(especially when it comes to theme styles, interactive effects, etc.) usually Critical Rendering Path These files may need to be loaded early to ensure the correct rendering of the page. Placing them on Zaraz may cause them to load late, thus affecting the user's First Render Experience.

3. Zaraz’s positioning and scope of application:

• Zaraz More suitable for Centralized management of third-party scripts,For example Google Fonts,Advertising script,Statistics script For these scripts, Zaraz Asynchronous loading and Lazy Loading to optimize performance.

• For CSS/JS files of local themes or plugins, it is recommended to keep them loaded on the origin server or CDN, especially for those files that are critical to page rendering.

Summarize:

• Migrate third-party scripts(such as Google Analytics, advertising, webmaster tools, etc.) to Zaraz is beneficial to performance, especially in Asynchronous loading and Centralized management There are significant optimizations.

• For CSS and JS files of local themes or plugins, migrating to Zaraz may affect the load order and critical rendering path, so these documents recommend Keep it on the origin server or CDN.

Based on the above principles, I finally decided to migrate the following four plug-in scripts to Zaraz using asynchronous loading to minimize the blocking effect on page rendering:

1. Font Awesome plugin (Free), using the "Custom HTML" template, the corresponding CDN URL is:

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

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

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

2. Umami, using the "Custom HTML" template, the corresponding URL is:

https://umami.tangwudi.com/tangwudi

Umami is a third-party analysis tool for page access traffic. It has nothing to do with page rendering and can be placed at the end of the page for asynchronous loading.

3. Google AdSense, using the "Custom HTML" template, the corresponding URL is:

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

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

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

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

4. Google Analytics, using Zaraz’s official template

The processing method for Google Analytics scripts is not exactly the same as other scripts. It depends on the scenario: if you have high requirements for the real-time and accuracy of Google Analytics (for example, relying on Google Analytics to collect user behavior data in real time to optimize advertising, conduct A/B testing, or adjust strategies in real time), it is recommended to put it in the early stage of page loading. Although this will slightly affect page performance, it can ensure that data is collected and analyzed accurately and timely, avoiding delays that lead to missing or incorrect data, which in turn affects decision-making and optimization effects; if the real-time requirements are not high, or if you don’t pay much attention to the immediacy of data (such as personal blogs), you can use Zaraz to asynchronously load Google Analytics, thereby reducing its interference with page rendering and increasing page loading speed (suitable for sites with high performance requirements).

---

In fact, I wanted to migrate instant.pagee's js scripts to Zaraz at first, but later I thought it was not appropriate: Instant.page relies on loading and executing scripts as early as possible to speed up the user experience by preloading the pages to be visited, which requires the scripts to be executed before the page DOM is fully loaded. However, Zaraz loads scripts asynchronously and may cause the execution order to be inconsistent with expectations, thus affecting the triggering timing of Instant.page and its effect. In addition, Zaraz does not guarantee instant execution, which conflicts with Instant.page's sensitivity to timing, so I finally gave up the migration.

---

2.4 Officially start the migration

2.4.1 Migrate Font Awesome to Zaraz

I previously installed the Font Awesome plugin (Free account) directly in WordPress. The implementation of this plugin is 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 in the tag:

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

As shown below:

After migrating to Zaraz, this script is still used (Zaraz does not provide a ready-made template for FontAwesome), but the defer parameter needs to be added to make it execute after the HTML parsing is completed, so as to ensure that the page loading will not be blocked. The final script is as follows:

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

The specific steps are as follows:

Replace the CDN address of the Font Awesome plugin in section 2.3 with<script>Label method:

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

Fill in the HTML Code box in the image below:

Finally, the configuration is completed:

After that, disable the Font Awesome plugin locally in WordPress and delete the line of code that the plugin inserts into the "header.php" file of WordPress (note that for this type of plugin that directly inserts code into the theme file to implement its functions, disabling the plugin will not automatically delete the code inserted into the theme file, so manual operation is required), then clear the browser cache (if CDN is used, it is best to clear the CDN cache as well) and reload it. Filter the word zaraz in the developer tools and you can see the following results:

At the same time, Font Awesome related scripts are still loaded normally as before when using the Font Awesome plugin:

2.4.2 Migrate Umami to Zaraz

Recreate a new tool Umami and follow the process in the first part again. 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 the added operation is as follows:

Then, as before, delete the umami script code in the original site, clear the browser cache (if CDN is used, it is best to clear the CDN cache as well) and reload it, and finally confirm in the "Network" of the developer tools that the umami script is still loaded normally:

2.4.3 Migrate Google AdSense to Zaraz

Recreate a new tool Google AdSense and follow the process in 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 in the original site, clear the browser cache (if using CDN, it is best to clear the CDN cache as well) and reload it, and finally confirm that the publisher ID can still be seen in the "Network" of the developer tools:

2.4.4 Migrate Google Analytics 4 to Zaraz

I previously used the Rank Math SEO plugin to implement Google Analytics 4. Since Google Analytics 4 has a ready-made configuration template on Zaraz, I will not use the "Custom HTML" method this time (it's a good idea to use a ready-made one). Instead, I will use the official configuration template. Follow the steps below:

Configuration is complete:

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

---

The measurement ID for Google Analytics 4 is obtained from the following location in the Google Analytics dashboard:

---

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

Note: In fact, you can also add only one third-party tool, and then add each script in the form of operation to the third-party tool, but it generally does not make sense (unless there is a special need), it is better 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:

At the same time, you can also see the usage of Zaraz under the "Monitoring" tab:

4 Conclusion

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 the blocking time during page loading, significantly improving page performance and user experience. For example, after migrating the four third-party scripts mentioned earlier in the article to Zaraz, my blog's PageSpeed Insights score has improved again, and the TBT time has been further reduced to 50 milliseconds (TBT ≤ 50 ms: Generally considered excellent, indicating very good interactivity during page load):

The most important metric is "removing rendering-blocking resources", which can no longer be reduced:

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

---

"Remove rendering-blocking resources" usually refers to JavaScript and CSS files that block page rendering, or resources that need to wait for these files to load and execute before continuing to render the page. If this item shows 0 ms, which 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 order in which external resources are loaded, and users can see page content faster.
* Appropriate strategies have been adopted (e.g. via Cloudflare Zaraz, asynchronous loading, etc.) 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 only need to load it once on Zaraz, of course, except for scripts bound to access domain names), thereby improving maintenance efficiency and providing detailed debugging and statistical tools to optimize script loading timing and performance.

However, as mentioned before, Zaraz is only suitable for running some third-party scripts that do not directly affect the rendering of the core content of the page. It is not a panacea, so everyone must carefully consider when choosing the scripts to migrate to Zaraz, otherwise improper selection may lead to counterproductive effects.

In addition, the Zaraz free plan provides a quota of 1 million events per month, which is not enough for a personal site: