W3 Total Cache Minify Plugin Settings: How to Choose the Embedding Type? My Troubleshooting Experience and Lifesaving Advice

Struggling to choose the right embedding type for W3 Total Cache Minify? This article shares a webmaster's real-world experience and provides a step-by-step guide to accurately select the correct Minify embedding type, avoiding website style mishaps and loading crashes. It also includes a foolproof setup solution that even beginners can easily apply.Wordpress Accelerate without crashing!

I was optimizing a website and when I opened the Minify settings in W3 Total Cache, I was completely dumbfounded. The dropdown menu for the embedded type had four options: Default (Block), Use JS for Non-Blocking, Use "Asynchronous" for Non-Blocking, and Use "Delayed" for Non-Blocking.

I thought about it for a moment, what is all this about?

Trust me, you're not alone. These four options will likely leave even a novice bewildered, let alone someone who's been using WordPress for years. This article presents the pitfalls I've encountered and the lessons I've learned directly. You don't need to consult the documentation; just follow my instructions.

What exactly are these four embedding types?

Let's first talk about what kind of character these four options are.

Default (Blocked)This is called Default blocking. It's the most straightforward approach: the browser stops when it encounters a script, downloads and executes it completely, and then continues rendering the page. Sounds reliable, right? But the trade-off is that your initial page load will be blocked; users will have to wait for the script to finish running before they can see anything.

Using JS for non-blockingThis is quite interesting. Instead of directly writing `<script>` tags on the page, it first outputs a small script, and then dynamically injects the scripts that need to be loaded into the page using JavaScript after the page is running. This way, the page can be rendered first, and the scripts can load gradually. Sounds great, right? However, the problem is that this dynamic injection process might disrupt the original execution order of the scripts. If some scripts on your page heavily rely on the execution order, problems may arise.

Use "asynchronous" for non-blockingThis involves adding the `async` attribute to the `<script>` tag. The script will download asynchronously in the background and execute immediately after downloading, without the page waiting for it. However, the downside is that the execution order is completely uncontrollable; whichever script finishes downloading first executes first, regardless of the order you specified in the code.

Using "delay" for non-blockingThis is what adding the `defer` attribute means. The script will wait until the entire page has been parsed before executing, and importantly, it will maintain the original order you wrote it. This is quite user-friendly, as it neither blocks the first screen nor disrupts the order.

Which one should I choose?

To put it simply, these four options are like a multiple-choice question:Do you want speed or order?

My suggestion is as follows:

If your website is small, has few scripts, and you don't have extremely high requirements for loading speed, using the default (blocked) setting is the easiest option. Although it's a bit slower, it won't cause any problems.

If you want to improve first-screen speed and your scripts don't have strong dependencies like "A must execute before B", prioritize...Using "delay" for non-blocking(defer). This is almost the most ideal solution at present, as it neither blocks rendering nor disrupts the order.

If you try defer and still find that some functions have problems, then consider...Using JS for non-blockingThis solution is more radical, but its compatibility is slightly worse.

Use "asynchronous" for non-blocking(async) is the option I least recommend. Because the execution order is completely messed up, it's easy to crash unless you're absolutely certain that your scripts are all running independently.

Two big pitfalls I fell into

Talk is cheap. I've written down two mistakes I made; you can check them against your own experience to see if you can avoid them.

The first pitfall: Custom WordPress themes cannot be previewed in real time.

For a while, when customizing a theme, after clicking save, the preview wouldn't refresh. I'd make some changes, refresh the page, and it would still be the same.

After some investigation, I discovered that Minify's compression function was the culprit. The solution is simple:

Access the W3 Total Cache pluginGeneral settings,turn up"compression"Uncheck that option. Then click the small arrow below "Save Settings" in the upper right corner and select "..."Save settings and clear cacheThis step is crucial; if you don't clear the cache, you'll still be seeing the old version.

After you're done, go back to theme customization, and the live preview will be back to normal.

The second problem: The Astra theme search box doesn't respond when clicked.

I encountered this problem quite a while ago. I was using the Astra theme, and one day I suddenly found that the search box wasn't responding no matter how I clicked it. At first, I thought it was a problem with the theme itself, but later I discovered that it was caused by W3TC's Minify settings.

The solution is as follows:

Go to W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings, and change the embedding type to one of these two:

1. Previously, non-blocking was achieved using JavaScript.
2. After, use JS for non-blocking

Similarly, clearing the cache and refreshing the page will allow the search box to work properly.

As for why these two options were chosen instead of others, I've done some research. Simply put, the Astra theme's front-end components are quite sensitive to the timing of script execution, and certain non-blocking methods can cause event binding to fail. Using the "non-blocking with JS" mode ensures that the script executes only after the page has finished loading, while avoiding the disordered execution seen with async.

List of places to be visited

Finally, here's a checklist you can follow directly:

The first step is to clarify your goal. Do you want the fastest initial page load, or do you prioritize stability and error-free operation? This will determine which embedding type you should use.

The second step is not to change everything at once. First, find a less important page to test it, observe it for a day or two, and only promote it to the entire site if you are sure there are no problems.

Third, always clear the cache after each modification. W3TC's caching mechanism will prevent you from seeing the latest changes, so the "clear cache and test again" step is absolutely essential.

Fourth, use your browser's developer tools or tools like PageSpeed ​​Insights to compare the loading speed before and after. Let the data speak for itself, not just your gut feeling.

Write at the end

To be honest, when I first saw this embedded type setting, I was stunned for a long time. The default blocking mode seemed too slow, while asynchronous mode didn't guarantee the order, and deferring might cause compatibility issues. I felt unsure about which option to choose.

But I later realized it's a trade-off. You can't have both the fastest and the most stable; you always have to sacrifice one. My experience is to use defer first, which is currently the safest non-blocking solution, and then use a callback if problems arise.

If you encounter similar problems, or if you still have other issues after following my method, feel free to discuss it. Website development is all about trial and error; no one is an exception.

Thank you for reading my article. See you next time.