Troubleshooting Concatenated CSS or JavaScript Delivery Methods

This article explains how Jetpack Boost delivers concatenated CSS and JavaScript files, how to check which delivery method is in use, and how to troubleshoot issues with direct delivery and PHP-served fallback.

Jetpack Boost (v3.9.0 and later) optimizes WordPress performance by concatenating and minifying CSS and JavaScript files, delivering them directly from your web server for faster load times.

When direct delivery is not possible, a fallback system using PHP keeps content accessible while optimization continues.

How to check which delivery method is in use

To determine which delivery method your site is currently using, follow these steps:

1. Open a page on your website in a browser.
2. View the page source (right-click → View page source).
3. Look for CSS or JavaScript file URLs:
   • If they are loaded from /wp-content/boost-cache/static/, your site is already set up for direct delivery of these files.
   • If they are served from /_jb_static/, WordPress is handling the delivery. This can slow down requests slightly because PHP processes these files. Concatenating multiple files into one is still beneficial, but you may want to find out why direct delivery is not working on your site.

Custom permalinks and file regeneration

Jetpack Boost relies on WordPress’s custom permalinks system to regenerate these concatenated files. If a file is missing, WordPress detects the issue and triggers a regeneration process in Jetpack Boost. The plugin periodically checks whether WordPress detects missing files in the wp-content directory. If this check fails, files are served using the /_jb_static/ method via PHP.

Manual testing

If your site is using /_jb_static/ to serve the concatenated files, you can run a manual test by attempting to access a non-existent URL within the /wp-content directory. The URL should look like a file the plugin uses, such as /wp-content/boost-cache/static/1234.css. Look for a WordPress 404 error page. If you instead see a standard web server 404 error, this confirms there is an issue requiring resolution.

When does the automatic 404 test run?

The plugin performs a check when both Concatenate modules (JS and CSS) are disabled and you enable one of them. It also runs once daily. This keeps monitoring of your site’s file delivery ongoing.

The automatic 404 test never runs on WordPress.com or Pressable. On those hosts, Jetpack Boost always uses PHP-served delivery through the /_jb_static/ method, because the web server may answer 404s for missing wp-content files before WordPress loads. Since WordPress never sees the 404, the test cannot produce a reliable result there.

How to fix issues with wp-content

The issue likely stems from the underlying web server configuration tied to custom permalinks.

Fixing on Apache

On Apache servers, mod_rewrite rules manage this, and they may be disabled in the wp-content directory. Check for a hidden .htaccess file within the wp-content directory. If present, look for the following directive:

RewriteEngine Off

Removing or commenting out this line may resolve the issue. If you are unfamiliar with these configurations, contact your hosting provider for assistance.

If there is no .htaccess file in the wp-content directory, your hosting provider may have disabled the web server settings this plugin relies on. If that is the case, the plugin falls back to using WordPress techniques to serve the concatenated CSS or JavaScript. This is slightly slower, but it is still beneficial to your site.

Fixing on non-Apache servers

For non-Apache servers like Nginx, consult your server’s documentation or contact your hosting provider for guidance on modifying configuration files in /etc/nginx/.

Developer options: disable 404 testing

The following section is for developers. Changing these options incorrectly can break the delivery of your site’s CSS and JavaScript. If you are unsure, contact your hosting provider before making changes.

To disable the is_404() testing, define the constant JETPACK_BOOST_DISABLE_404_TESTER in an mu-plugin. Here is an example of how to set that constant:

<?php

if ( ! defined( 'JETPACK_BOOST_DISABLE_404_TESTER' ) ) {
    define( 'JETPACK_BOOST_DISABLE_404_TESTER', 1 );
}

After disabling the tester, and if you are certain that is_404() works in the wp-content directory, you can set the jetpack_boost_static_minification site option to 1. Set it to 0 to use the older way of serving these files.

Do not set this option on WordPress.com or Pressable

Do not set the jetpack_boost_static_minification option to 1 on WordPress.com or Pressable. On those hosts the 404 test never runs, so forcing static delivery leaves Jetpack Boost with no way to detect that the web server answers 404s for missing wp-content files before WordPress loads. If the host answers those 404s at the web server level (for example, Pressable’s Lightweight 404 toggle), your site’s CSS and JavaScript will break.

Starting in Jetpack Boost 4.7.0, the plugin ignores the jetpack_boost_static_minification option on WordPress.com and Pressable and always uses PHP-served delivery there. On those hosts, setting the option has no effect after you upgrade to 4.7.0 or later.

If you already set this option to 1 on WordPress.com or Pressable and your site’s CSS or JavaScript is broken, set jetpack_boost_static_minification back to 0 to restore PHP-served delivery.

If you manage a host that answers its own 404 routing and you want to override this behavior, use the jetpack_boost_minify_use_static_cache_urls filter. This is the supported override for hosts that know their own 404 handling.

Summary

In most cases where direct delivery is not working, a .htaccess file in your /wp-content directory is the cause. Reviewing that configuration should restore expected 404 test behavior and let your files be delivered directly. On WordPress.com and Pressable, PHP-served delivery is expected and is the correct behavior.