Serve Static – Automatic WordPress Static Page generator vs SQLite Object Cache

Serve Static provides a very efficient, simple and fast way of implementing static page caching in WordPress. It will generate static HTML copies of your webpages which will be then served using your server rewrite rules. This feature will bypass the whole PHP process and render only a simple HTML file without having to interect with the PHP, or MySQL for getting your page’s design or content. This plugin is really handy and helpful if your webpages are mainly static, like websites of Blogs, portfolios, company portfolios, service, and many more. This plugin doesn’t support any dynamic content caching, that means, all none of your dynamic content will be showing in the frontend, rather, a static version of that content will be showing. This plugin also comes with home-made HTML, CSS and JS minification features, which you can use to auto-minify the static files. This ensures more lightness of the HTML pages, and more boost to your page speed. Also, you can auto-warm the cache using the Warm feature, which will stimulate a visit on all your pages, to create the static files before they are served to your visitors. Usage After activating the plugin, it will try to modify your .htaccess file. If this is not possible for some reason, make sure to enter the rules by yourself. NOTE: without these .htaccess rules, the static files won’t be served or created. Note that, this is only applicable if you are using a Apache/Litespeed server. # BEGIN Serve Static Cache RewriteEngine On RewriteBase / RewriteCond %{HTTP_COOKIE} !(^|;\s*)wordpress_logged_in_.*$ [NC] RewriteCond %{REQUEST_URI} !^/(elementor|vc_row|fl_builder|fl-theme-builder) [NC] RewriteCond %{REQUEST_URI} !^/wp-admin/ [NC] RewriteCond %{REQUEST_METHOD} GET RewriteCond %{QUERY_STRING} ^$ [NC] RewriteCond %{DOCUMENT_ROOT}/wp-content/serve-static-cache/$1/index.html -f RewriteRule ^(.*)$ /wp-content/serve-static-cache/$1/index.html [L] # END Serve Static Cache If you the website installed on a sub-folder, like such that “https://test.com/domain1”, is your main domain of your WordPress site, you need to use a different .htaccess code. The plugin will automatically do that for you, but incase you need to do it manually, below is the format you need to follow. # BEGIN Serve Static Cache RewriteEngine On RewriteBase / RewriteCond %{HTTP_COOKIE} !(^|;\s*)wordpress_logged_in_.*$ [NC] RewriteCond %{REQUEST_URI} !^/(elementor|vc_row|fl_builder|fl-theme-builder) [NC] RewriteCond %{REQUEST_URI} !^/wp-admin/ [NC] RewriteCond %{REQUEST_METHOD} GET RewriteCond %{QUERY_STRING} ^$ [NC] RewriteCond "WP_CONTENT_DIR"/serve-static-cache/"sub-folder domain without slashes"/$1/index.html -f RewriteRule ^(.*)$ /"sub-folder domain without slashes"/wp-content/serve-static-cache/"sub-folder domain without slashes"/$1/index.html [L] # END Serve Static Cache The value of the WP_CONTENT_DIR should be something like: “/home/test.com/public_html/staging/wp-content” The value of the “sub-folder domain without slashes” should be your folder where WordPress is installed. So, if the WordPress is installed in “https://test.com/staging”, you should enter “staging”. When using a nginx server, make sure to add the following rules: # BEGIN Serve Static Cache location / { if ($http_cookie !~* "wordpress_logged_in_") { set $cache_uri $request_uri; if ($request_uri ~* "^/(elementor|vc_row|fl_builder|fl-theme-builder)") { set $cache_uri "null cache"; } if ($request_uri ~* "^/wp-admin/") { set $cache_uri "null cache"; } if ($request_method = GET) { set $cache_uri "null cache"; } if (-f $document_root/wp-content/serve-static-cache$cache_uri/index.html) { set $cache_file $document_root/wp-content/serve-static-cache$cache_uri/index.html; } if ($cache_file) { rewrite ^ /wp-content/serve-static-cache$cache_uri/index.html break; } } } # END Serve Static Cache This plugin creates static HTML versions of your pages/posts, or literally any custom post types, and serves them to your non-logged-in visitors. This is an awesome way to make your website blazing fast, and not even one request is made to PHP to request your pages. Anytime a Static page/post/any custom post type is updated, the cache of that specific page is automatically cleared, and regenerated. So, you do not have to worry about regenerating the cache eac time after making changes to your content. This plugin is also well-integrated with frontend post rating plugins as well, so that when any rating is added, the cache gets regenerated automatically. If you are using any rating plugins that are not working with this plugin, kindly let me know in the support forum. This plugin heavily relies on CRON to process it’s functionalities. So please make sure either your server-level cron or WordPress Cron is running and working. If not, this plugin will show errors in the Admin Notices to help you direct to the problem. If there are still many issues, kindly share in the plugin support thread. By default, this plugin automatically works with Apache and Litespeed servers, and everywhere .htaccess rules is functional. But to make this plugin work with NGINX, you will be needing to add some rules to your nginx.conf or site.conf file. An appropiate admin notice will be shown to you accordingly, kindly follow those instructions. This plugin is supposed to work with all the form builder plugins like WP Forms, Ninja Forms. If you face any issues while using any form plugin, kindly let me know in the thread, and I will try to make it compitable. Performance Converting your website to a static webpage can drastically improve your performance and page speed. Serve Static eliminates all requests made to your database and ultimately reducing the first time to byte, total blocking time and many more. This is especially impactful for websites that have mainly static pages, and use long pages with a lot of graphs, sliders, and other load-heavy resources like animations. Reduce hosting bandwidth Using Serve Static to serve static HTML pages of your website really cuts a great cost in your bandwidth usage, as this doesn’t hit the MySQL server for your visitors, but instead serves delivers a cached, minified HTML copy. This releases much of your cost, alongside the page boost. We are working on features like “hosting your Static pages in a third party CDN, and serving those to your visitors”. If you are interested to see this feature in soon, let me know by opening a supprt thread! NOTE Caching is fully disabled for Administrators, or any logged-in users. Static Cache will only be served to logged-out visitors of your site. Note that, the Static Cache can only be regenerated by using the buttons in the admin toolbar, or in the Settings page. After the cache is Flushed, the cache is NOT regenerated when someone visits the pages. This is done so that none of the personalized content gets saved in the HTML caches. This plugin may not work as expected with a caching plugin like WP Rocket or W3 Total Cache. So make sure the URLs of the static pages are excluded from the specific plugins. For example, when using WP Rocket, you need to navigate under Settings > WP Rocket > Advanced Rules > Never Cache URLs, and enter the URLs to the pages you want to serve as Static. When using W3 Total Cache, navigate under Performance > Page cache > Advanced > Never cache the following pages.

A persistent object cache helps your site perform well. This one uses the widely available SQLite3 extension, and optionally the igbinary and APCu extensions to php. Many hosting services offer those extensions, and they are easy to install on a server you control. What is this about? It’s about making your site’s web server perform better. An object cache does that by reducing the workload on your MariaDB or MySQL database. This is not a page cache; these persistent objects go into a different kind of cache. These objects aren’t chunks of web pages ready for people to view in their browsers, they are data objects for use by the WordPress software. Caches are ubiquitous in computing, and WordPress has its own caching subsystem. Caches contain short-term copies of the results of expensive database lookups or computations, and allow software to use the copy rather than repeating the expensive operation. This plugin (like other object-caching plugins) extends WordPress’s caching subsystem to save those short-term copies from page view to page view. WordPress’s cache happens to be a memoization cache. Without a persistent object cache, every WordPress page view must use your MariaDB or MySQL database server to retrieve everything about your site. When a user requests a page, WordPress starts from scratch and loads everything it needs from your database server. Only then can it deliver content to your user. With a persistent object cache, WordPress immediately loads much of the information it needs. This lightens the load on your database server and delivers content to your users faster. Who should use this? If your site runs on a single web server machine, and that server provides the SQLite3 and igbinary extensions to php, this plugin will almost certainly make your site work faster. And if that server provides the APCu extension, this plugin uses it too. Some hosting providers offer redis cache servers. If your provider offers redis, it may be a good choice. You can use it via the Redis Object Cache plugin. Sites using redis have one SQL database and another non-SQL storage server: redis. Other hosting providers offer memcached, which has the Memcached Object Cache plugin. And some large multipurpose cache plugins, such as the LiteSpeed Cache, also offer object caching based on one of those cache server software packages. The cache-server approach to object caching comes into its own when you have multiple load-balanced web server machines handling your site. SQLite doesn’t work correctly in a multiple-web-server environment. But, for single-server site configurations, SQLite, possibly assisted by APCu, performs well. And the vast majority of sites are single-server. APCu APCu is an in-memory storage medium. It lets php programs, like WordPress, store data in shared memory so it’s very fast to retrieve when needed. If APCu is available on your host server, you can configure this plugin to use it. It reduces the typical cache lookup time to one-fifth or less of the SQLite lookup time, which is itself a few tens of microseconds. Performance counts, especially on busy web sites. Please look at Installation to learn how to configure this plugin to use APCu. The plugin works fast without it, and faster with it. WP-CLI: Even if APCu is in use, caching with SQLite is necessary when your web site uses WP-CLI, because WP-CLI programs do not have access to the APCu cache. This plugin writes all cached data both to APCu and to SQLite and makes sure the two are synchronized. WP-CLI You can control this plugin via WP-CLI once you activate it. Please type this command into your shell for details. wp help sqlite-object-cache Credits Thanks to Till Krüss. His Redis Object Cache plugin serves as a model for this one. And thanks to Ari Stathopoulos and Jonny Harris for reviewing this. Props to Matt Jones for finding and fixing a bug that appeared on a heavily loaded system. Thanks to Massimo Villa for testing help, and to nickchomey for a comprehensive code review. All defects are, of course, entirely the author’s responsibility. And thanks to Jetbrains for the use of their software development tools, especially PhpStorm. It’s hard to imagine how a plugin like this one could be developed without PhpStorm’s tools for exploring epic code bases like WordPress’s. How can I learn more about making my WordPress site more efficient? We offer several plugins to help with your site’s database efficiency. You can read about them here.