Minification / Cacheing

/ SprUng, Websites - more cheats, wordpress - more cheats / 15 minutes of reading

how to test page speed – https://pagespeedtweaks.com/fast-velocity-minify/

https://onlinemediamasters.com/wp-fastest-cache-settings/ – wp fastest cache plugin settings / review –

https://premium.wpmudev.org/blog/best-caching-plugins-wordpress/ – alternative cache programs

https://docs.wp-rocket.me/article/670-hosting-compatibility
WP Engine

  • WP Rocket is the only caching plugin that is allowed on their system. We worked closely with their team to meet their requirements.
  • The page caching feature of WP Rocket is automatically disabled to prevent conflict with WP Engine’s caching. All other features such as LazyLoad, minification etc. are available.
  • WP Rocket automatically detects if you use WP Engine and auto-purge their Varnish caching when your WP Rocket cache is purged.
  • WP Rocket will automatically be allowed on your staging site even if you have a Single license. Staging won’t count as an additional site.
  • If you are using WP Engine’s CDN service, you still have to enable the CDN option in WP Rocket, and enter your CDN URL so the plugin can detect it and function correctly. If you’re not sure what your CDN URL is, you can find it by following the instructions in WP Engine’s doc.
  • WP Engine has deprecated the use of the htaccess file. They apply those related optimizations in their server configuration instead. WP Rocket does not require the use of the htaccess file on WP Engine – all features will still work as expected.
  • WP Rocket will not create an advanced-cache.php file on WP Engine sites.

https://docs.wp-rocket.me/article/46-how-to-check-if-wp-rocket-is-caching-your-pages

How to check if WP Rocket is caching your pages

WP Rocket by default delivers cached pages for visitors who are not logged-in WordPress users. When you’re checking if caching works as expected, make sure one of the following conditions is true:

  • Either: You’re logged out, so you’re just an anonymous visitor to your WordPress site.
  • Or: You’ve enabled User Cache on the Cache tab, so WP Rocket will create a dedicated cache for logged-in users on your site.

If you are on a Managed WordPress host, page caching may be disabled by design. Please check our hosting doc for host-specific notes. Steps 1, 2 and 3 below will still be relevant.

Now that we’ve made sure you’re visiting a page that indeed is expected to be served from cache, here’s how you can identify it really is cached:

1. Caching footprint

Open the browser’s source view of the page and scroll to the bottom. At the very end you should see an entry like this:

Not seeing a footprint? Are you perhaps using Cloudflare? Cloudflare’s HTML minification would remove the footprint.

2. Minified files

This methodology works if you have Minify CSS files or Minify JavaScript files on the File Optimization tab enabled.

Open the browser’s source view of the page and look at the <head> section. Most of the URLs that end on .css, or .js should include this part:

/wp-content/cache/min/

This means that WP Rocket’s file optimization is working; usually, the page would also be cached.

3. Wappalyzer

Wappalyzer is a free service that lets you identify technology on websites. You’d just install one of their browser extensions that will show you if WP Rocket is running on a website.

Go to Wappalyzer to install browser extension

4. Cache folder on the server

Using either (S)FTP, or your web host’s file manager panel, you can visit the cache folder in your WordPress install directly, and make sure that cache files are generated correctly.

  1. Make sure you’re logged out, then visit several pages on your site, so they get cached.
  2. Access your WordPress file system and navigate to: 
{your-wordpress-root-folder}
  ┗ wp-content
    ┗ cache
      ┗ wp-rocket

Inside of that folder, you should see a folder named like your domain. This is the folder where you should find cached .html and/or .html_gzip files, along with folders for each page on your site. These are the cache files. 

It should look something like this (with www.wordpress.dev being our example site URL): 

Caching doesn’t work, now what?

After using all these methods, if you determine that WP Rocket is NOT caching your site, here’s how to troubleshoot:

Pages not cached, or Minify CSS/JS not working

https://docs.wp-rocket.me/article/99-pages-are-not-cached-or-css-and-js-minification-are-not-working

Pages not cached, or Minify CSS/JS not working

WP Rocket by default delivers cached pages for visitors who are not logged-in WordPress users. When you’re checking if caching works as expected, make sure one of the following conditions is true:

  • Either: You’re logged out of WordPress
  • Or: You’ve enabled User Cache on the Cache tab

If you are on a Managed WordPress host, page caching itself may be disabled by design. Please check our hosting doc for host-specific notes. Other optimizations should still be applied and the below tips will still help.

If you believe that WP Rocket is not caching your pages or is not minifying your CSS and JS files (after you have enabled those options), it might be that the minimum requirements for the plugin to function have not been met. Or it could be that you have previously installed other caching plugins, and even if you deleted them via the WordPress dashboard, they have left files and configuration behind.

In this article

Writing permissions

In order to function correctly, WP Rocket needs be able to create and write to certain files and folders within your WordPress install. The following files and folders are associated with, or written to by WP Rocket:

{wordpress root folder}
┣━.htaccess
┣━wp-config.php
┗━wp-content
  ┣━advanced-cache.php
  ┣━cache
  ┃ ┣━busting
  ┃ ┣━critical-css
  ┃ ┣━min
  ┃ ┗━wp-rocket
  ┗━wp-rocket-config

.htaccess

{wordpress root folder}
┗━.htaccess

On Apache servers, the .htaccess file needs to be writable for WP Rocket (CHMOD 0644). After activation there should be a large block of code present from WP Rocket, beginning at the very top of the file:

# BEGIN WP Rocket v{version number}

... lots of code in here ...

# END WP Rocket

... other code down here

Note that an htaccess file is not required for caching and file optimizations to work. But it is used to apply other best practices such as browser caching and GZIP compressions.

wp-config.php

{wordpress root folder}
┗━wp-config.php

The wp-config.php file needs to be writable for WP Rocket (CHMOD 0644). Make sure that the following line is present at the top of wp-config.php, after the opening <?php tag. If it is too far down in the file, WP Rocket will not work!

define( 'WP_CACHE', true ); // Added by WP Rocket

Also, make sure there is no reference to another caching plugin. For example, WP Super Cache leaves this line behind:

define( 'WPCACHEHOME', '{/path/to/wordpress/root/}wp-content/plugins/wp-super-cache/' ); //Added by WP-Cache Manager

advanced-cache.php

{wordpress root folder}
┗━wp-content
  ┗━advanced-cache.php

Make sure that advanced-cache.php in the wp-content folder references only WP Rocket.

WP Rocket configuration folder

{wordpress root folder}
┗━wp-content
  ┗━wp-rocket-config

Make sure a folder named wp-rocket-config is present in wp-content. If it isn’t, create it, and make sure WP Rocket can write to it.

Cache folder (and subfolders)

{wordpress root folder}
┗━wp-content
  ┗━cache
    ┣━busting
    ┣━critical-css
    ┣━min
    ┗━wp-rocket

Make sure that WP Rocket has writing permissions for the cache folder (CHMOD 0755), and that it contains the 4 subfolders depicted above. All of these WP Rocket needs to be able to write to. If these folders don’t exist you should create them manually.

Cleaning up the cache folder

If you had any other caching plugin previously enabled, it may have left behind its own folders. We recommend to delete those.

WP Super Cache creates a wp-cache-config.php file in wp-content which should be deleted.

W3 Total Cache creates the following files and folders in wp-content which should be deleted:

wp-content         (keep!)
┣━cache            (keep!)
┃ ┣━config         (delete)
┃ ┣━db             (delete)
┃ ┣━minify         (delete)
┃ ┣━object         (delete)
┃ ┗━page_enhanced  (delete)
┣━db.php           (delete)
┣━object-cache.php (delete)
┗━w3tc-config      (delete)

(It may create other folders based on individual settings.)

Note: While it’s fine to delete any files and folders of caching plugins you don’t use anymore, even some themes may create a subfolder in the cache folder. You should always keep those.

WP Rocket Settings

  1. Go to WP Rocket Settings > Advanced Rules > Never Cache URLs
    Make sure there aren’t any unexpected exclusions. For example, / will exclude the homepage from being optimized: 

  2. Settings can be controlled on a page-by-page basis as well. Go to the edit screen of an affected page and check the WP Rocket Options box at the side. Check if the page has been excluded, or if certain options have been deactivated: 

Multisite and domain mapping

If you have a multisite installation using domain mapping, try logging into your admin area using the mapped domain instead of the original domain, and then de-activate and re-activate WP Rocket. This will enable WP Rocket to detect the correct domain and activate caching.

Other plugins/theme disabling caching

Sometimes another plugin or your theme may set the constant DONOTCACHEPAGE. What this does is override all caching plugins by blocking caching from working. So this would need to be removed and the developer of that plugin informed.

Here are a few plugins we are aware of that add a DONOTCACHEPAGE constant:

  • Ezoic Integration plugin: their WordPress plugin blocks caching, use their nameserver integration method instead
  • GeoIP Detection: has a specific option to disable caching on pages that contain their shortcode.
  • Ad inserter pro: has an option to disable caching
  • Cartflows: prevents caching on the step custom post type
  • Mailster: the option “disable form caching” prevents caching.
  • s2 Member
  • WooCommerce Klarna Gateway

You can see if the constant is what’s causing cache problems by installing this helper plugin which will allow WP Rocket to apply caching even if the DONOTCACHEPAGE constant has been defined somewhere else:

📥  Download (.zip): WP Rocket | Force Page Caching
Developers: You can find the code for this plugin on GitHub.

SSL Cache

As of WP Rocket 3.3.4, SSL caching is automatically enabled on new installations.
On existing installations that don’t currently use SSL but enable it later on, make sure you update your WordPress URL settings to use HTTPS and WP Rocket will automatically enable SSL caching.

See this article for more info:
Using SSL with WP Rocket

Theme compatibility

  1. Make sure your theme contains a closing html tag: </html>
  2. Make sure your current theme references wp_footer() . 
  3. If it is missing, adding it to the footer.php template, right before the closing </body> tag, usually resolves the issue:

After making any of these adjustments, de-activate and re-activate WP Rocket once. Then verify if WP Rocket is working by following this article:
How to check if WP Rocket is caching your pages

Other server requirements

  • mod_expire and mod_deflate should be enabled for browser caching and GZIP compression respectively (ask your webhost to enable these)
  • curl_exec function should be enabled if you are using a version of WP Rocket before 3.5. From 3.5+, this is not required.

Error: It seems that the advanced-cache.php file is not ours

If you’re seeing this error message in your WP admin:

you should check the following in order to resolve it. 

1) Check that your  advanced-cache.php file contains the correct define mode: 

define( 'WP_ROCKET_ADVANCED_CACHE', true );

2) If the define mode is ok, check the file permissions: 

CHMOD should be defined as 644 or 664.

Now refresh the admin page and check if the error message is gone.

3) If you still see the error, probably the issue lies in your wp-settings.php file. 

If you have manually edited the wp-settings.php file so that it doesn’t make any reference to the advanced-cache.php file, it will create the error. In the example below, the file was edited to remove some code:

To solve it, you have to restore the block of code referring to the advanced-cache.php file :

In general, it is a bad practice to edit WordPress core files directly as it can create problems. This is just one example. 

https://docs.wp-rocket.me/article/19-resolving-issues-with-minification

Resolving Issues with File Optimization

So you have activated one or more options to minify or combine files or un-render-block CSS/JS, and your website is toast? Broken layout? Misplaced items? Links or forms not working?

Here is the one simple step to fix all of those:

1. Deactivate all the options!

Seriously, do it. Uncheck all options on the File Optimization tab, and save changes. Your pages will still load (nearly) as fast as before, and your website will be back as beautiful as ever again.

Heads up! If the issue has NOT gone away at this point, it is caused by something else than file optimization, and you don’t need to follow this tutorial any further.

2. First aid

Which option causes the issue exactly?

Re-activate your options one by one and check your website in a logged out window after each step. Once the issue re-appears, you know which option exactly causes it. Now you can simply keep that option deactivated, or continue troubleshooting.

Does your website currently display a “coming soon” page to visitors?

If so, file optimization will not work. Continue to configure File Optimization once your website or staging site can be viewed even when you are not logged-in as a WordPress user.

Does minification actually work?

In this article we assume that the technical process of generating optimized files works as it should. If that is not the case, for example if you do not see any minified files on your server, check out this document:
Pages are not cached or CSS and JS minification are not working

Learn the basics of how to understand “PageSpeed”!
Before you continue troubleshooting, we strongly recommend you educate yourself on how to understand the “performance grade” from Google PageSpeed Insights, GT Metrix and other tools.

Read these 2 articles before you proceed:
Google Page Speed Grade does not improve
How to correctly measure your website’s page load time

Skipping this step can result in a waste of your time, energy, and even money.

3. Troubleshooting File Optimization

By now, you have completed these steps:

  • You have excluded other possible causes for the issue you’re seeing.
  • You know which option(s) exactly causes the issue.
  • You have actually decided to troubleshoot instead of just leaving some options deactivated.

Let’s get on with it then!

We are going to assume you have a basic idea about these things:

  • what “minification” is;
  • what “concatenation” is;
  • what the “HTML document” is and how to read it (at least basically);
  • what a “file URI” is and how to find it in the browser;
  • what the “development tools” (or “dev tools”) in the Chrome or Firefox browser are, and how to open them.

Should you actually be doing this? If any of the terms listed above are complete news to you, you may not be the person who should worry about troubleshooting here, unless you are keen to educate yourself about some of the more technical aspects of websites.
None of the things covered in this article are actually mandatory in order to have a faster website. However, if you choose to go on, be sure to bring the required tech skills.

Minify HTML

  • Can reduce page size.
  • Strips all (or most) of the line-breaks and unnecessary spaces from the HTML document.
  • If you notice any issues with Google Analytics or any other scripts using CDATA comments in the source code, try if deactivating HTML minification solves the issue.

Did you know? If you need to exclude any files from the following options, you will need to find the original URIs unprocessed by WP Rocket. To do this while the plugin is active you can load the unoptimized page with original URIs intact, by adding the query string ?nocache to any URL. For example:

https://example.com/your-sample-page-or-post/?nocache

Minify CSS files
Minify JavaScript files

  • Can reduce page size.
  • Strips all (or most) of the line-breaks and unnecessary spaces from CSS or JavaScript files.
  • No general known issues.
  • You can exclude specific file URIs from the minify/combine process by copy-pasting them into the respective exclusion fields in your settings.
  • If you exclude files, make sure you exclude original file URIs, not the ones generated by WP Rocket! The file URI you enter in the exclusion field must not contain /cache/min or /cache/busting.

Combine CSS files
Combine JavaScript files

  • Can reduce the number of HTTP requests.
  • Combines all CSS and JavaScript files into one (larger) file per file type; 1 for CSS, and 1 for JS.
  • Combines inline JS and 3rd party scripts.
  • Can improve PageSpeed Insight grade by including JS content of 3rd party into the merged files.
  • Should not be used when site runs on HTTP/2. See this article:
    Configuration for HTTP/2
  •  Can cause issues when themes/plugins have not defined correct dependencies for enqueued scripts or stylesheets.
  • You can exclude specific file URIs from the minify/combine process by copy-pasting them into the respective exclusion fields in your settings.
  • If you exclude files, make sure you exclude original file URIs, not the ones generated by WP Rocket! The file URI you enter in the exclusion field must not contain /cache/min or /cache/busting.
  • Follow these tutorials in order to find the file URIs you need to exclude:
    JS issues: Find the right JS files to exclude from optimization
    CSS issues: Resolving issues with CSS minify/combine

Heads up! In order to prevent issues related to external JavaScript, you can exclude it from the process as described here:

Optimize CSS delivery
Load JavaScript deferred

  • Can improve loading time and performance grade.
  • Reduces the number of initial HTTP requests.
  • Can reduce the number of render-blocking inline scripts.
  • Can reduce issues with jQuery errors or “JS variables not defined” by respecting the JS variable declaration order.
  • Can cause numerous issues when not done correctly. Make sure you read this article about it:
    Render-blocking JavaScript and CSS (PageSpeed)
  • Requires advanced knowledge of website development. Render-blocking resources may vary on each and every page of your website. So getting this to work can become a highly complex task while the result may not even make your website load that much faster. Skipping this option might be your best choice unless you’re an experienced web developer who already knows how to handle render-blocking resources in general.

Did you know? If you only have an issue on a few pages, a simple solution is to deactivate the problematic option(s) on those specific pages. Please see this guide for more info.

https://docs.wp-rocket.me/article/1131-resolving-issues-with-css-minify-combine

Resolving Issues With CSS Minify / Combine

To resolve display issues that may occur when CSS Minify /Combine is active, please take the following steps:

  1. Install the Blue Button Chrome Extension: https://chrome.google.com/webstore/detail/blue-button-the-webpage-x/ahbcoeleapdfhmlnjglbiaddohfncace?hl=en-GB
  2. Visit the page on your site with the CSS issue, and add ?nocache to the URL, e.g example.com/about?nocache.
    This bypasses WP Rocket, so that you can find the original URLs (unmodified by WP Rocket) of all CSS files. 
  3. Click the Blue Button in your Chrome toolbar, then click Stylesheets:


    This gives you a list of all CSS files loaded on that page. 

  4. Copy the list of files, then go to WP Rocket Settings > File Optimization and paste the list into the Excluded CSS Files field:
  5. Save the settings and check your site, in a logged-out or incognito window. It should now be displaying correctly.
  6. Now remove each file from the list, one-at-a-time. After each removal, save the settings and check your site. Repeat this until the website is broken again.
  7. When the website breaks, replace the last removed file back into the list and move onto the next file.

Note: this method can also be used for issues with JS Minify/Combine (by choosing Scripts in Blue Button), but the 

https://docs.wp-rocket.me/article/915-find-the-right-js-files-to-exclude-from-minification

Find the right JS files to exclude from minification

JavaScript minification can be quite hard to troubleshoot, especially when you have a lot of files. We describe a process in our doc , which is essentially a process of elimination. However, sometimes it’s possible to more directly identify and exclude the problematic files.

Heads up! If you have File Optimization→Basic Settings→Remove Query Strings enabled, make sure to disable it while troubleshooting. 

In this example, we refer specifically to using the Chrome browser.

  1. Open Developer Tools. You do that either by right-clicking and choosing Inspect Element, or at the top of the window go to: View→Developer→Developer Tools

  2. Find the red error message indicator on the right-hand side:

  3. Click it to open the Console, then click the file referenced in the error notice:

  4. This takes you directly to the code in the file that is related to the error. Look for the red underline and copy part of that code:

  5. Open a new browser tab and load the un-cached version of the page. You do that by adding ?nocache to the URL—this will load an un-cached, un-minified version of the page. It is necessary in order to find the original URLs of the files.

    An un-cached URL would look something like:   https://example.com/?nocache or: https://example.com/some-page/?nocache

  6. Open Developer Tools, then click the 3 dots on the right side and select Search All Files:

  7. Paste the problematic code in the search box and it will locate the file in which that code is found:

  8. It’s not possible, unfortunately, to copy the filename from this screen. So to do that, click on the Network tab (reload the page if necessary to pull in the files). Then search for the file in the list:

    Once you’ve located the file, right-click on the filename, select Copy, then Copy Link Address.

  9. Paste this into the  Exclude JavaScript Files text field in the File Optimization tab of WP Rocket. If you need to exclude all files from a specific sub-folder, you can use a wildcard (see first line in the text field on the screenshot):

    After saving this you can visit your site again, reload the page and check that there are no more JavaScript errors reported in the console.

https://docs.wp-rocket.me/article/108-render-blocking-javascript-and-css-pagespeed

Render-blocking Javascript and CSS (PageSpeed)

Note: For further information on Google PageSpeed Insights and why you should not bother chasing a “grade” please read this guide:
Google PageSpeed Grade does not Improve

What is render-blocking JavaScript and CSS?

Before the browser can display a web page, it has to render its HTML. During this process, whenever the browser encounters an element that references a script, or stylesheet, it has to stop, request the file, wait for it to download from the server, and execute it before it finally can continue parsing the HTML. With most WordPress themes and plugins loading not only one, but multiple CSS and/or JavaScript files, this process can delay the time to first render of the page quite significantly.

Therefore it is recommended to delay (“defer”) the loading of non-critical files until the browser is done rendering the page. This requires adjustments to the HTML source of a page itself, as well as intimate knowledge of which file is required at what point during the rendering process. Sounds tricky? It sure is!

Nonetheless, tools like Google PageSpeed Insights makes it sound so easy:

“Eliminate render-blocking JavaScript and CSS in above-the-fold content”

Like many of PageSpeed Insights’ suggestions, this one is quite generic, and can be hard to implement—even with a streamlined plugin like WP Rocket!

WP Rocket has 2 options to address the PageSpeed recommendation:

You can find them in the Files Optimization tab, under CSS Files and JavaScript Files:


By enabling these options you may see an improvement in your performance grade on GTmetrix, Pingdom Tools, and Google PageSpeed Insights. Results will vary from site to site. Always remember to test the effect on the speed of your site. 

Critical CSS Generation Errors

Please see our guide on troubleshooting errors with the generation of critical CSS

https://docs.wp-rocket.me/article/1267-troubleshooting-critical-css-generation-issues

Troubleshooting Critical CSS generation issues

Basic requirements for the generation tool to work:

  1. Your site must be publicly accessible for the tool to work, that means it won’t work for locally hosted sites or sites blocked from the public by htaccess authentication, “maintenance mode” plugins or similar. 
  2. The following IPs have to be allowlisted by your server, firewall or security plugin :
    • 167.114.226.142
    • 54.37.31.6
  3. WP-cron or a real server-side cron job must be able to run.

Slow or no progress

If the generation appears to be running very slowly, i.e. it takes a long time for the progress indicator to update, it’s likely that our tool is temporarily overloaded. In these cases it’s best to try again in a few hours when the load may be lighter.

Error notices

If it’s not possible for our tool to generate the critical path CSS for any content type on your site, you will see a notice with the details. 

Some errors can be temporary, so it’s worth trying the generation again. If the issues persist, please proceed with the troubleshooting below. 

If you get any error message on every content type (see screenshot below as an example), it’s likely our tool is being blocked by your site. Please make sure your site is publicly accessible and our IP addresses have been allowlisted in any security plugin or firewall. 

Find which URL is accessed per content type

Our tool accesses the most recent URL for each content type on your site. If you see an error for a specific content type, you can find out which specific URL is being accessed:

  • Install and activate this helper plugin: WP Rocket | CPCSS Debug Helper
  • Go to: Settings > CPCSS Helper
  • There you will see which URL we’re accessing for each content type
  • Visit the problematic URLs to check if they are valid pages.

Invalid response code

Our external tool sends a request to a page on your site. If it does not receive a 200 “OK” response, you will see an error with the response.

The most common reasons are:

  • The URL is not publicly accessible, e.g. it 404s
  • A security layer on your site is blocking access – this often results in a 400 or 403 error. 

User has blocked requests through HTTP

External HTTP requests have been blocked on your site: 

  • Check your wp-config.php file for this line:  define( 'WP_HTTP_BLOCK_EXTERNAL', true );
  • Check if a security plugin is blocking external HTTP requests
  • Make sure you add these IPs to your “allow list”: 167.114.226.142, 54.37.31.6

Job not found

  • This is usually a temporary error. Please try the regeneration again in a few minutes.

URL unreachable

This error notice will display the specific URL(s) that the tool cannot access.

  • Visit the URL in your browser to ensure it’s accessible.
    • If it is, it’s likely being blocked by a security firewall or plugin, so please allowlist our IPs.
  • If the URL results in a 404 error, or any other error prevents it displaying in your browser, that means our tool will not be able to reach it either.
    • Resolve the issue with that page and try the generation again.
  • If it’s for a post type that has not been declared to be public, it will not work. Some post types are not designed to be visible on the front end of your website. For example, post types that manage affiliate links. A post type may be used to manage each link, but they are not viewable as a webpage since they redirect elsewhere. 

No valid stylesheets available

You could see this message if:

  • There aren’t any stylesheets added within <link> tags.
  • The linked stylesheets are empty
  • There’s only Inline CSS on your site. The tool does not use existing inline CSS when generating the critical path since it could result in duplicated CSS.

Styles contain one or more errors

  • One of the recovered style sheets is invalid, preventing the generation of the critical path CSS.
  • Check that your stylesheets are valid and accessible. 

CloudFlare protection prevents the service from accessing the website

  • Allowlist the IP addresses of our tool in Cloudflare (or any other similar firewall service)

An error prevents the generator from retrieving its contents

Sometimes this error can be temporary, try it again.

If the error persists it could be related to a timeout on the page:

  • There’s a 30 second timeout on specific file requests
  • There’s a 1 minute timeout on the page as a whole

SSL error

The SSL certificate of the website is not valid so our service cannot access it.

Connection refused

The most common reasons are:
  • The port (80 or 443) is not open on the destination machine.
  • The port (80 or 443) is open on the server, but its backlog of pending connections is full.
  • A firewall is blocking access.

Too many redirections

If there are more than 2 redirects when accessing a given page, the connection is interrupted to avoid loops.

Timeout

If the duration between the request and the first byte (TTFB “Time To First Byte”) exceeds 20 seconds the connection will be closed.

Unable to reach the following url

Our tool was unable access the requested page. Wait a few minutes, then try the generation again.

Unable to generate the critical path. The service may be overloaded. Please try again later.

When several Timeouts follow each other, this can cause an overload of the queue and cause our generator to crash. When this happens, the queue is then purged. Websites that were in the queue receive this error. Try the regeneration again in a few hours when the load may be lighter.

5 Ways to Accelerate Your Site, in Addition to WP Rocket


Disclaimer: this article is targeted to a public with an intermediate to advanced technical knowledge. This is a guest post and opinions are those of the author, not necessarily WP Rocket. Services mentioned are not necessarily official WP Rocket endorsements.

Have you found the perfect WP Rocket configuration for your site but you wish to go even further with your optimization? In this article we’re going to give you 5 suggestions to locate and solve the most common causes of slowness for a website, even if you’re already using WP Rocket. And if your site is already fast, these points will help boost its speed!

5 ways to identify why your site is slow, even if WP Rocket is working

1. Identify a poorly coded plugin with a client-side analysis

The first move to identify the critical causes of slowness for your site, is a front-end scan of your page with one of the available web performance tools.

In order to get a more accurate result, before launching your test you should deactivate your cache plugin.

The Tools

  • Pingdom
  • Dareboost
  • WebPagetest
  • Yslow (install it on your browser)

For my tests, I’m going to use Pingdom, since it’s fast to use and presents the results in an easily readable format.

Now, to identify the reason for a long loading time, you have to sort the Pingdom “waterfall”, choosing ” load time” from the menu.

Case Studies

Example 1, external widgets

Loading time for my first case study was 4.75 s.

From the first look at the Pingdom waterfall, I could immediately locate the cause of the problem. Read carefully the lines of this table :

Did you find it ?

Of course, you got it, this website is using an old “Facebook like box” integrated through an iframe. That’s a real performance-killer for this site:

Whenever you encounter a similar case, you should always ask yourself: which is the best choice for my users? Should I give priority to a widget for my Facebook page or should I provide a better user experience with a page that loads 3x faster? 

Why don’t you substitute that widget with a visible link on the header of your site? If your theme includes some icon fonts like FontAwesome, you can obtain an attractive result without burdening your page with an image.

After this correction, loading time for this site dropped to 0.95 s.

There are countless widgets using external scripts, for example the share buttons from Shareaholic, just to mention one.

In these cases, not even a performance plugin like WP Rocket can work miracles to reduce the slowness of these external widgets. An upstream optimisation is fundamental to obtain the optimal performance.

Example 2, poorly coded plugins

Loading time for this second case study was 2.88 s.

From the Pingdom waterfall, I can see a script taking a lot of time to load.  


In a movie, the script tells the actor what to do. With coding, it’s the same: the script describes the process that should be executed. And sometimes, this can result in a huge load time and slow down your site.

Instantly, I could identify which plugin is integrating the JavaScript through a poorly coded script: take a look at the URL : /wp-content/plugins/{plugin name}/js/…

After some Google research, I found that this was a known issue for this plugin and it was solved with a plugin update. As an alternative, I could have removed the plugin and substituted it with another one. There are often multiple plugins offering the same solution.

After these corrections, loading time for this site dropped to 0.59 s.

Generally speaking, it’s a good practice to review your WordPress plugins on a regular basis and deactivate any which are not really useful for your site’s functioning.

2. Identify and get rid of slow MySQL requests

The tools

There are many plugins that provide useful info about resource consumption:

  • Query Monitor
  • Debug Objects
  • P3 Profiler (even if it seems abandoned by its author)

Slow MySQL queries

Before launching a complex website, it can be useful to run a diagnostic in order to verify we didn’t invite any greedy plugin to our table.

At the moment I’m working on a site using WooCommerce and WPML together. Before activating WP Rocket, I ran a diagnostic with Query Monitor and I detected a few slow queries :

My feeling was right. It seems I forgot to make a few optimisations on theWPML side. I ended up deactivating some WPML options such as the Auto register strings for translation. This allowed me to properly optimise WPML, so that all queries are executed in the most efficient way.
These kinds of optimizations will make your cache plugin run even more efficiently!

Allocated WordPress memory

WordPress in itself is a relatively light CMS, but it can quickly become a resource hog once we install certain plugins.

By default, WordPress grants 40M of RAM memory for each process.

If your site runs some advanced plugins, it will be necessary to increase the memory. To do this, you can add this line in your wp-config.php file :

define( ‘WP_MEMORY_LIMIT’, ‘128M’ );

Your WordPress site will now be able to breathe. In any case, remember that, for optimal performance, a reliable and well configured webhost is still fundamental.

– MORE IN ARTICLE – https://wp-rocket.me/blog/5-ways-to-accelerate-website-beyond-wprocket/

How does wordpress rewrite media urls –

+++++++======++++++++++++++++++++++++++++++++====++++++++++++++++

How Does WordPress Rewrite Media Files URLs
I am using a plugin which moves uploaded files to a remote location and reroutes any requests to those files because in the postmeta table, the meta_value for _wp_attached_file is still the local file location. Even though it’s safer to do it that way, I really don’t like the whole filter-at-load-time business because when the plugin is running, the home page is taking 20s to load.

Even though I have manually rewritten the values to replace them with the S3 bucket full URLs ( hxxps://s3.amazonaws.com/url/to/image.ext ), in the media library and on the front-end WordPress still tries to find them on the local server ( hxxps://1ocalhost/url/to/image.ext ).
WordPress seems to be replacing everything before ‘wp-content’ with ‘hxxp://localhost/’. How do I change this behaviour?

Viewing 5 replies – 1 through 5 (of 5 total)
WP saves the media paths to post meta as the media is uploaded. You can alter any related meta data just before it is saved with the filter ‘wp_update_attachment_metadata’.

FWIW, ‘rewrite’ is a poor choice of words in this context as the term has a very specific meaning in server administration that is unrelated to what you are asking. WP does not rewrite any physical file paths. If a physical file is requested, WP is not even involved, so it cannot rewrite anything. WP determines the default media path from a particular hidden option or defined constant. If neither are defined, the default is constructed from the constant ABSPATH and the value set for the site url option. Determining the media path this way would not be considered a rewrite.

But I knew what you meant, so it’s all good

Kajuzi (@kajuzi)
1 year, 7 months ago
I can’t believe you’ve just chosen to correct my semantics and not given a solution
I can’t use wp_update_attachment_metadata() because I’m not uploading these files. They have been uploaded already.
My question still remains: How do I keep the correct uURL in the database and make sure that the remote file path is not converted to a local one when the file is requested

Moderatorbcworkz (@bcworkz)
1 year, 7 months ago
I was answering the primary question in the topic title. Sorry I didn’t answer every question in your post. It wasn’t my intention, it just happens. I sometimes fail at good reading comprehension.

I’m not sure there is a single all encompassing solution. The solution will depend on what specific access is being done. Anyway, if the entire uploads location is at S3, go to the semi-hidden options screen at /wp-admin/options.php. Locate the ‘upload_url_path’ option and set it to the S3 equivalent of your usual httр://example.com/wp-content/uploads local location. There is no valid equivalent you can use for the related ‘upload_path’ option unless you have a local mirror. Anything that depends on full local paths will need to be addressed separately. The URL path option should cover most situations.

Kajuzi (@kajuzi)
1 year, 6 months ago
Thank you very much. This is exactly what I wanted.
Unfortunately, because of some images in some funny locations that are not being uploaded to S3, I can’t use this simple solution

Moderatorbcworkz (@bcworkz)

1 year, 6 months ago
If code is using get_option() to retrieve what is stored in ‘upload_url_path’, what is returned can be dynamically filtered with the filter ‘option_upload_url_path’. There are frequently other filters for other WP functions that return URLs. It’s a matter of knowing which functions are used in your situation.

Scroll to Top