SQLite Object Cache vs Statixly – Static Site Generator

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.

Statixly converts your WordPress site into a fully static HTML website — eliminating PHP, databases, and server-side dependencies from your production host. The result: faster load times, a reduced attack surface, and the freedom to deploy on any web server or CDN. ⚡ Benefits: Why Statixly? 🚀 Faster page loads: Static websites load 3 to 5 times faster than WordPress sites by serving pre-rendered HTML without PHP execution or database queries. 🔒 Reduced attack surface: Static sites have no login page, database connection, or server-side code on your production host. This eliminates primary attack vectors such as SQL injection and brute-force attacks. 🌍 Deploy anywhere: Host on Cloudflare Pages, GitHub Pages, AWS S3, or any standard web server. No PHP, MySQL, or WordPress dependency is required in production. 💰 Lower hosting costs: Static files can be served from free or low-cost CDN-based hosts instead of a PHP-capable server. Managed WordPress hosting typically costs $25 to $100 or more per month, while static hosting is often free or very affordable on platforms like Cloudflare Pages or Netlify, which offer unmetered bandwidth on their free tiers. 🛠️ Zero production maintenance: Your live site is pure HTML. With no WordPress running in production, there are no security patches, plugin updates, or server-side dependencies to manage on your public host. 🎛️ Live export control: Start, pause, resume, or abort the export from the admin screen and monitor progress in real time. 📦 One-click download: The entire static site is packaged as a ZIP file, ready for extraction and upload. 🔄 Auto-resume on interruption: If internet connectivity drops during export, the job resumes automatically once the connection is restored. 🔍 SEO Benefits 📊 Better Core Web Vitals scores: Static HTML loads faster, directly improving Time to First Byte (TTFB) and Largest Contentful Paint (LCP), which are metrics Google uses as ranking signals. 🤖 Improved crawl efficiency: Search engine bots fetch plain HTML instantly, with no server-side rendering delay. This signals high crawl health and allows engines to index content more effectively. ⏱️ Higher uptime reliability: Static files served from a CDN experience near-zero downtime, helping avoid Google ranking penalties for frequently unreachable URLs. 🧹 No WordPress footprint in production: Common WordPress paths such as /wp-admin and /wp-login.php are removed from the live site, reducing spam crawling and preserving crawl budget. The admin screen provides the following capabilities: Start a static export job Monitor live export status in real time Pause, resume, or abort the export Download the generated static site as a ZIP file Download or delete export logs Delete temporary export directories Statixly systematically crawls website URLs, renders content, rewrites links for static output, and packages the results for deployment. Typical workflow First, build and set up your site as you normally do in WordPress. Make sure all content and settings are finalized before exporting. Next, open the Statixly admin screen and select the Generate/Export Static Site button to start the export process. After the export finishes, download the generated ZIP file containing your static website. Extract the files from the ZIP archive. Upload the extracted files to your chosen static hosting provider. For example, use your website’s document root on a web hosting server, Cloudflare Pages, GitHub Pages, AWS S3, etc. Important Requirements If the current WordPress website is on example.com and you want to make the static website available on example.com as well, move the WordPress website to a subdomain and protect it with HTTP Basic Auth, or move it to your localhost computer using a backup and migration plugin such as Duplicator. Permalink structure must not be set to Plain. Keep the Statixly export tab open while export is running. Not for e-commerce, etc. Statixly will not work on any WordPress website that generates content dynamically based on user interaction, e.g., an e-commerce or subscription-based website. Contact forms will not work. The contact form requires immediate backend processing upon submission by the user. However, this is on our roadmap. HTTP Basic Authentication If your WordPress install is protected with HTTP Basic Auth (for example, a staging or subdomain install), enter your credentials under Statixly → Settings → Security so Statixly can authenticate during export. Credentials are encrypted before storage and never exposed in logs or diagnostics output. Advanced Opt-In Options Statixly includes two optional safety/compatibility flags, both disabled by default and configurable from the Statixly → Settings → General screen. Allow insecure local HTTP fetch Enable this only for expired, invalid, or self-signed certificate environments where same-site HTTPS fetches fail TLS verification. This turns off SSL verification only for local same-site fetches. Prefer temporary storage above document root Enable this only if you explicitly want Statixly working directories outside wp_upload_dir(). By default, Statixly uses WordPress uploads paths. Please note that this option works only if the intended directory is readable and writable by the web server user. Both flags can also be set directly in the options table if preferred. Need Help? If you face any issues after installing the Statixly plugin, please open a support ticket with detailed information, and we will be happy to fix the issue.