The newest update for W3 Total Cache is here and we will continue to deliver more speed for your WordPress websites while continually improving the user experience.
In this release we’ve added query string based URL structures to cache AMP pages using a query string, filter of minify options (added support for ‘postprocessor’ option usage programmatically), lazyload picture tag support, removed the footer link “Support Us” option, improved wp_die handling, lazyload handling of content in script tags, lazyload handling of feeds, printing tags coming from feeds, handling of modified posts before wp_rewrite initialized and handling of .htaccess files in regard to EOF (End of File).
Nginx rules have also changed a lot to avoid “location” block conflicts. That change may cause problems on some systems using non-default WordPress rules – keep a backup of your original rules to ensure you minimize issues.
We’ve also fixed Varnish purging and HTML minification of data tags equaling 0.
In our public repository on GitHub, you can review our source code, post issues, and even submit pull requests if you are interested in contributing to the project. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present.
We are always looking for ways to improve W3 Total Cache with new features, UI improvements, and of course, improvements to the user experience. If you like what we have done, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.
Once again, we are sending a big thanks to all of our supporters, including those who are active in the community forums helping out end-users.
In previous W3 Total Cache versions, rules for the Nginx server were not correct when the option “Prevent caching of objects after settings change” in Performance > Browser Cache > General was enabled along with “Rewrite URL structure of objects”. Having both of these enabled caused PHP fallback to be used for all minify assets when utilizing the Disk: Enhanced page cache engine.
W3 Total Cache 0.12.0 removes “location” block conflicts for URL postfix rewrites and adds header directives for all other “location” blocks.
In 0.12. version security headers will also work correctly now, which wasn’t the case before as Minify set to disk was not rewriting when Browser Cache with Prevent Object Caching was used in Nginx
That change may, however, due to problems on some systems using non-default WordPress rules so keep a backup of your original rules to ensure you minimize issues.
Particularly WordPress Networks (WPMU) deployed in subfolders instead of in the root directory of the domain, i.e. myhost.com/myfolder/ for WordPress set up and myhost.com/myfolder/my-blog2/ for subdirectory network blogs.
We are constantly improving W3 Total Cache— and listening to your feedback has allowed us to continue offering a top-notch product.
In this latest release, we are proud to introduce some new features and improvements which will help you further increase the speed and performance of your website.
The first new addition that we would like to highlight is Image Lazy Loading, a completely new and highly requested feature to W3 Total Cache that came directly from our users.
Lazy loading images
Lazy loading images mean that images on websites are loaded asynchronously— after the above-the-fold content is fully loaded all other images are only fetched when they appear in the browser’s viewport. Lazy loading defers the loading of resources on the page until they are actually needed, instead of getting them as soon as the page loads. Loading resources ensures that nothing is gathered until the moment the user actually needs them.
If you’ve used Google Page Speed Insights and examined some opportunities for improvement, you may have seen some suggestions to Defer offscreen Images.
With lazy loading, you are reducing the number of images needed to load the page initially. Fewer resource requests mean fewer bytes to download and reduced competition for the limited network bandwidth available to users.
Lazy loading image has a positive impact on performance by reducing the initial page load time, page weight, and system resource usage.
Improved Statistics
We are also excited to announce the new and improved Statistics page that will help our Pro users get the most out of their caching and locate additional areas of optimization. The improved Statistics page allows you to check the Hit rates and overall effectiveness of every configuration enabled in your General settings.
Enabling the Debug mode for each setting In Performance > General Settings > Debug gives you more detailed information by clicking on a link of the desired setting in Statistics Page.
If for example, Object Cache is disabled, it won’t be available in Statistics
In Performance > General Settings > Statistics you can enable Statistics and customize your desired settings:
Please note that this consumes additional resources and is not recommended to be run continuously.
Example of the Statistic Page (Page Cache):
Other Improvements
We’ve also made some more general improvements in this update to enhance the overall user experience:
Fixed inserting a new line before injecting to Apache Config
Fixed HTML minifier removing the quotes around href attribute
Fixed feeds caching test failing
Added License Expiration Admin Notices in Dashboard (Pro)
Implemented correct headers caching for REST API caching under Disk: Enhanced. including a missing test for REST API cache
Main admin menu and admin bar icons were not reflecting the correct color settings if the user selected a different Admin Color Scheme in their profile settings.
Previous icons were .PNG and have been updated to .SVG to make this possible.
I’ve been using this on my own website for a couple of years now to improve website load speed. Teamed up with MaxCDN it has increased my page load speed a lot. We install it on all of our client’s websites now!
Tried numerous caching plugins. W3 is best, especially for busy sites. Most plugins only cache pages, W3 has so many options. Support is very helpful as well. 5 stars.
This plugin made my web pages load faster than other similar plugins I had tried. When I needed help to exclude my sitemaps from caching, support quickly gave me the help I needed. Thanks!!!
I already knew what W3TC could do for the performance (speed) of my website, but until today I had no experience with their support for the free version of the plugin.
The amount of support they provided me and how much they helped me is outstanding. And that’s all for free. Really great plugin, would really recommend this one!
With this minor release we addressed an issue with the WordPress 5.3 release:
Warning: Declaration of W3TCDbCache_Wpdb::prepare($query, $args) should be compatible with wpdb::prepare($query, …$args) in /home/xxxxxxx/public_html/wp-content/plugins/w3-total-cache/DbCache_Wpdb.php on line 8
Please note that you need to Purge all caches and to clear your CDN cache if the warning is still showing on your website after updating to v0.10.2
We want to thank all of you who brought this issue to our attention, and hope you continue to support our product!
In our public repository onGitHub, you can review our source code, post issues, and even submit pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present. In the very near future, we will be adding attribution for all contributors that assist us in making W3 Total Cache the best WordPress Performance Boosting product on the market.
We are always looking for ways to improve W3 Total Cache with new features, UX and UI improvements, and fixing any outlying problems that may exist. If you like what we are doing, please be sure to take some time and rate our pluginon the WordPress Plugin Repository.
We appreciate all of our partners, supporters and the entire WordPress community, and would like to give special thanks to those who are active in the forums helping end-users.
Sometimes modifications to existing .js and .css files are not reflected for users visiting your website. This occurs because those files have been cached in the user’s browser from a previous visit and the cached version is served instead of the most recent version. The expiration of this cache is called time to live, or TTL and it is associated with this local cache in your browser, which is why it will show the old version until this length of time has passed. To see the correct version of the files, the user has to either clear the browser’s local cache & reload the page or do a hard refresh of the page by pressing Ctrl+F5 to ensure their browser is using the latest file versions.
When a user tries to access the URL, and the browser starts fetching the page data, it sees that it already has the page’s stylesheet E.G. style.css, and says “Wait!, I already have this file cached, so I don’t need to fetch it again and can just present that to the visitor”. And the Browser has a point!
What is Cache Busting?
Asking each and every user to clear their browser cookies or do a hard refresh is not reasonable and leads to frustrating user experience. To remedy this, we can use a technique known as Cache Busting. Cache Busting works by appending a unique query string to the path of the .js or .css file that tells the browser there is a new file to add to the cache memory. When the browser loads a page using these query strings it downloads any unrecognized files and displays them for the visitor.
How can I fix this?
You can use any unique query string you want to bust the browser cache, but the easiest way to guarantee a unique string is to use version numbers.
For example:
Let’s say you make some changes within your theme’s main JS file:
/mywebsite/wp-content/themes/mytheme/mytheme.js
After updating the file simply add a version number query string ?v=1.0
This way when the browser will see the updated JS as a new .js file which is not cached. So it will generally force the browser to update the JavaScript/stylesheet. So, each time you update your JS/CSS on the server, you can incrementally update your version number so it busts the previously saved browser cache.
You can accomplish this when you enqueue your script by adding an argument for the version, for example:
WordPress 5.3, scheduled to be released on November 12, and contains numerous improvements for site performance and user experience.
Server-Side Block API
PHP enthusiasts (and JavaScript haters) will be glad to know that there is now a server-side API for creating blocks in the WordPress Block Editor (Gutenberg). When asked about the performance impact of registering new blocks this way, Core Contributor Jorge Costa suspects that the impact should be negligible unless compared to a JavaScript file that is registering a large number of new blocks, which could be cached by the browser:
For most cases, the performance should be equivalent. The PHP code dynamically generates an inline script with the equivalent JavaScript code to register a block style and generates an inline style with the classes. If many block styles are being registered having a single JavaScript file that registers all the styles and a single stylesheet that includes the styles may be more performant than registering the styles with PHP. In that case, the JavaScript and CSS files will probably be cached by the browsers while for inline scripts/styles it is not possible to take advantage of caching.
Better Large Image Uploads
An update to the WordPress REST API will solve a major pain-point for many users— better handling of large image uploads. Previously, if the server returned a 500 error at any point during the upload process, the upload would fail. Now, the request will automatically reconnect and attempt the upload again, as well as generate the attachment sizes at the very end of the request.
The WordPress Date/Time component has historically relied on the sum of the Unix timestamp and a time zone offset, which caused a great deal of confusion since the inline documentation referred to it as simply a Unix timestamp. Developers would need to account for this difference when comparing two timestamps against each other.
The new API allows developers to fetch a timestamp as a true Unix time or a DateTimeImmutable object, with methods to set timezone offsets in a reliable manner.
With this minor release, we fixed slowdown in Memcached engine, Purge Cache menu links so they flush current blog in WPMU, and fixed am an error during upgrade, “Call to undefined method W3TC Util_Content::is_database_error”. We’ve also updated Redis cache engine to avoid “Function Redis::delete() is deprecated” warning
In our public repository on GitHub, you can review our source code, post issues, and even submit Pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present.
We are always looking for ways to improve W3 Total Cache with new features, UI improvements, and of course, improvements to the user experience. If you like what we have done, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.
Once again, we are sending a big thanks to all of our supporters, including those who are active in the forums helping end-users.
The newest update for W3 Total Cache is here and we will continue to deliver more speed for your WordPress websites while we continually improve the user experience.
In this release, we’ve added a new statistics component for pro users, redirects by using safer wp_safe redirect, .htaccess usage when page cache does not require it, protection of unexpected values in global variables, and improved support for CloudFront distributions with multiple origins. We’ve also added support for the Memcached binary protocol when available, more Amazon S3 regions, and caching for webp MIME type.
Additionally, we have fixed some bugs with the usage of base URL with minify, S3 + CloudFront URLs when CNAMEs not used, and mixing the content of sync & async scripts with minify.
In our public repository on GitHub, you can review our source code, post issues, and even submit Pull requests. You are welcome to join us there, and we really appreciate all users that have contributed, both past and present.
We are always looking for ways to improve W3 Total Cache with new features, UI improvements, and of course, improvements to the user experience. If you like what we have done, please be sure to take some time and rate our plugin on the WordPress Plugin Repository.
Once again, we are sending a big thanks to all of our supporters, including those who are active in the forums helping end-users.
We are continuing to improve W3 Total Cache by delivering more speed for your websites and better user experience. With this release, we’ve Updated AWS library due to the deprecation of older API versions scheduled on June 6, 2019, and added support of set_sql_mode by dbcluster. We’ve fixed the PHP warning when remote service cannot be loaded, PHP warnings on the support page and improved support for a web server running on non-default port with disk-enhanced and menu icons.
In our public repository on GitHub, you can review our code, post issues, and Pull requests, and you are welcome to join us there.
We are always looking to improve W3 Total Cache with new features and UI improvements and of course, fixes and improvements for improved user experience so make sure to take some time and rate our plugin here.
Again, big thanks to all of our supporters, including those who are active in the forums helping end users.
First, we want to thank all of you for bringing bugs and issues to our attention. This is helping us to fix and improve the W3 Total Cache to user satisfaction. In this release we improved security on calls to Opcache flush, cache delivery of /feed URLs, purging of the current page by using post_id instead of URL and minification of files in environments running on non-default ports.
We’ve also added fixes for database cluster in WordPress 5.1, minification in multisite when URLs were set to root-blog based URL, undefined w3tc_ga issue, warning caused by user agent theme change used, 404 in multisite caused by subdirectory issue and PHP warning when Redis integration not configured correctly
Make sure to visit our public repository on GitHub where you can review our code, post issues, and Pull requests.
In future releases, you can expect a lot of new features and UI improvements and of course, fixes and improvements for improved user experience
A big thanks to all of our supporters, including those who are active in the forums helping end users. Please take some time and rate our pluginhere. Every feedback and every issue reported is helping us continue offering a top-notch product.
