Prime Cache – Page Cache, WebP, Lazy Load, Minify, Defer & Delay JS (Zero Config)

Prime Cache is a lightweight performance plugin for WordPress. Page caching works immediately after activation — no wp-config.php edits, no manual setup. It also provides browser cache headers, file optimization (minify, defer, delay), lazy loading, WebP conversion, cache preloading, and automatic cache purge.

Watch the 5-minute setup tutorial:

For site owners who want the fastest possible path, the settings screen shows an optional one-line WP_CACHE snippet that upgrades serving to drop-in mode, where cached pages are served before WordPress core even loads. Adding it is entirely optional and entirely manual — the plugin never writes to wp-config.php.

Free Features

• Page Cache
• Browser Cache Headers
• .htaccess Optimization
• Gzip Compression
• 404 Page Caching
• HTML / CSS / JavaScript Minification
• Inline Small CSS
• Defer JavaScript
• Delay JavaScript
• Google Fonts display=swap
• Lazy Load
• WebP Conversion
• Image Resize on Upload
• EXIF Data Removal
• Bulk WebP Optimization
• Cache Preloading for homepage, public posts, and public taxonomies
• Link Prefetching
• Performance Tweaks (disable emoji, jQuery Migrate, embeds, and other WordPress bloat)
• Automatic Cache Purge on content changes
• Security Headers
• Import / Export
• WP-CLI Support

Optional Add-on Features

Prime Cache Pro, a separate add-on sold on the author’s website (https://raplsworks.com/plugins/prime-cache/), extends the free plugin. It is not required for the free plugin to work:

• AI Speed Diagnosis & consultation — measures your server and homepage, explains what is slow in plain language, and applies validated fixes in one click (bring your own API key: Anthropic / OpenAI / OpenRouter / Gemini)
• AVIF conversion (on top of the shared WebP engine)
• Critical CSS and Remove Unused CSS
• CDN URL rewriting
• Cloudflare, Sucuri, and Varnish integration
• Object Cache backends (APCu / Redis / Memcached)
• Sitemap-based cache preloading
• Database cleanup
• Heartbeat control
• Self-hosted Google Fonts and Google Analytics

Internationalization

• English (source)
• Japanese translation included (WordPress Translation Style Guide compliant)
• Translation-ready with .pot template

Documentation

Full documentation for every setting and every behavior:

• Free Manual (English): https://raplsworks.com/prime-cache-free-manual-en/
• Free 版マニュアル (日本語): https://raplsworks.com/prime-cache-free-manual-ja/
• Pro Manual (English): https://raplsworks.com/prime-cache-manual-pro-en/
• Pro 版マニュアル (日本語): https://raplsworks.com/prime-cache-manual-pro-ja/

External services

The free Prime Cache plugin does not connect to any external service. No data is sent to any third party at any time by the free plugin.

The following third-party hostnames appear inside the plugin’s source code as string literals only, and the plugin never makes outbound requests to them:

• googletagmanager.com, google-analytics.com, connect.facebook.net, widget.intercom.io, embed.tawk.to — listed in includes/class-file-optimizer.php as URL-pattern presets for the “Delay JS” feature. They are used only to recognize third-party scripts already present on the page (added by other plugins or the theme) and to defer their execution until first user interaction. The plugin itself does not load, fetch, or embed any of these services.
• cdnjs.cloudflare.com — referenced only in code comments and admin-screen help text describing how some themes (e.g. Cocoon) replace bundled jQuery with a CDN version. The plugin does not call or include any resource from this host.

If you install the optional Prime Cache Pro add-on, that separate plugin documents its own external service usage in its own readme — Prime Cache (free) on its own makes no outbound calls.

Why the page-cache drop-in keeps an open output buffer

Page-cache plugins must capture the entire rendered HTML response so the body can be written to disk before the browser receives it. dropins/page-cache.php opens an ob_start() early in the request and lets PHP flush the buffer naturally at request shutdown — the captured body is written to the cache file inside the buffer callback. The buffer is deliberately not closed mid-request; doing so would either truncate the cached body or break the capture for plugins/themes that emit their last output during shutdown. This matches the design of every other major page-cache plugin (WP Super Cache, W3 Total Cache, WP Rocket, Cache Enabler, etc.). The HTML transformation pipeline in includes/class-html-pipeline.php follows the same pattern for the same reason.