Frequent 404 errors with cached JS and CSS files

  • sarldsecom

    (@sarldsecom)


    3 years, 1 month ago

    Our 404 monitor is detecting a significant number of 404 errors for Breeze’s minified and optimized files. I have verified the file permissions, and Breeze is successfully generating the files when I check them myself, and successfully renders whether I’m logged in or not, using a different browser. Although I rarely come across 404 errors myself, it seems to occur frequently for our customers. The 404 errors are specifically related to these files :

    /wp-content/cache/breeze-minification/js/breeze_*.js
/wp-content/cache/breeze-minification/css/breeze_*.css

    It appears that either these files are being deleted too aggressively or they are still being referenced in cached data after the cache has been purged. In either case, here is our current setup:

    Cloudflare settings

    • Browser Cache TTL : Respect Existing Headers
    • Caching Level : Standard

    .htaccess

    ExpiresActive On
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 2 hours"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 2 hours"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 hours"

    Breeze Settings

    • Cache system / Gzip compression / Browser Cache all enabled; Purge Cache After 1440 min; rest is disabled
    • File optimisations are all enabled

    Cloudways server settings

    • Varnish Cache Lifetime : 24 hours (same as Breeze settings)
    • Redis enabled

    Other significant settings

    • XML-RPC disabled except for Jetpack IPs and localhost (we tried to disable it, issue remains)
    • Redis and Object Cache Pro enabled (we tried to disable it, issue remains)
    • Woocommerce installed

    The most straightforward workaround to this issue would be to delay deletion of generated CSS and JS files by at least the cache lifetime if this isn’t already the case. Is it a known issue among Breeze developers ?

    • This topic was modified 3 years, 1 month ago by sarldsecom.
Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author adeelkhan

    (@adeelkhan)

    3 years, 1 month ago

    While enable the optimization of option of CSS minification and JS minification, Breeze creates its own cache file of CSS and JS and call the application CSS and JS from that created file.
    Could you please confirm the CSS and JS file created under the following path is called at same path at front end?
    /wp-content/cache/breeze-minification/js/
    /wp-content/cache/breeze-minification/css/

    Thread Starter sarldsecom

    (@sarldsecom)

    3 years, 1 month ago

    Hi,

    Yes absolutely, I can confirm that. In fact, it seems like it’s working fine most of the time, but our 404 monitor still registers errors for Breeze cache files that aren’t in their folders anymore. I have tried to replicate the issue without success but it seems like some of our customers are still encountering it. These files might get deleted too early by the plugin.

    Just to make sure, are the folders purged every x minutes as set in the “Purge Cache After” setting, or are files independently removed x minutes after their creation date ?

    • This reply was modified 3 years, 1 month ago by sarldsecom.
    • This reply was modified 3 years, 1 month ago by sarldsecom. Reason: Ask about removal logic
    Plugin Author adeelkhan

    (@adeelkhan)

    3 years, 1 month ago

    Basically Internal Cache purge Automatically after X minutes. Cache files will remove once internal cache remove/created while update/create post/page as well as any event performs by Breeze settings.

    Thread Starter sarldsecom

    (@sarldsecom)

    3 years, 1 month ago

    Okay, if I understand well, that’s why. For horrifiq.com we use the default value of 1440 minutes (1 day) for Purge Cache.

    Let’s imagine without any post/page update, then it will remove the cache every day at let’s say 5am. But files are created all around the day, when people visit the website. So, it is possible that a file has been created at 4:50 am and is deleted just 10 minutes later.

    We tested this tweak (set to 3 days instead of 2) to prevent files from being deleted if they’re less than 3 days old, and it seems to solve the 404 errors for us. The disadvantage is that a lot of cache files accumulate in 3 days but we’d rather lose 1-2gb of space than customers.

    You might want to implement this into Breeze, while of course allowing admins to enable or disable it if they experience 404 errors.

    Plugin Author adeelkhan

    (@adeelkhan)

    3 years ago

    From what I understand, do you want another option in Breeze that can provide the feature to delay the purging cache file feature?

    Thread Starter sarldsecom

    (@sarldsecom)

    3 years ago

    If my assumptions are correct, yes I think this would be a good workaround for this issue that you could implement. There are probably a lot of people using Breeze who are not monitoring their 404 errors and who would benefit from this.

    Plugin Author adeelkhan

    (@adeelkhan)

    3 years ago

    Thanks for your feedback and will be added in our feedback list.

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Frequent 404 errors with cached JS and CSS files’ is closed to new replies.

  • 7 replies
  • 2 participants
  • Last reply from: adeelkhan
  • Last activity: 3 years ago
  • Status: not resolved