Nilesh Kanzariya

Installation

Requirements, activation effects, filesystem boundaries, server notes, and a safe first-run sequence.

3 min readPart of Performance Optimisation

Performance Optimisation 2.4.0 supports WordPress 6.2+ and PHP 8.2+. Install it on staging first, especially when another cache plugin, a page builder, WooCommerce, or a CDN is already active.

Requirements

RequirementDetails
WordPress6.2 or newer.
PHP8.2 or newer; the plugin pauses below the floor instead of fataling.
FilesystemWrite access to wp-content and, when page caching is used, wp-config.php.
RedisOptional. Object Cache requires a reachable Redis service and the PhpRedis extension.
ServerApache, nginx, LiteSpeed, or OpenLiteSpeed. Server-rule output is environment-specific.

Install and activate

  1. Install from the WordPress Plugin Directory or upload the plugin ZIP through Plugins → Add New → Upload Plugin.
  2. Activate Performance Optimisation.
  3. Open the plugin Dashboard and read the system/server notices before changing settings.
  4. Test a logged-out page, the block editor preview, and the main navigation after activation.

With WP-CLI, place the ZIP on the server and run: 

wp plugin install performance-optimisation.zip --activate

What activation creates

  • An owned advanced-cache.php drop-in when no foreign drop-in is present. The plugin recognizes its marker and will not overwrite another plugin\’s file.
  • A guarded WP_CACHE constant in wp-config.php when the file is writable and the edit is unambiguous.
  • The canonical wppo_settings defaults, including page cache enabled, native lazy loading, LCP guardrails, and WooCommerce safe mode.
  • The activity-log table used for cache, cleanup, and settings events.

Server rules are not enabled on a fresh install. The Redis object-cache.php drop-in is also installed on demand after a connection is tested; it is not written merely because the plugin is activated.

  1. Baseline: record a PageSpeed run, response headers, and a logged-out page load.
  2. Page cache: verify the drop-in, WP_CACHE, cache status, and a second request.
  3. Assets: enable HTML/CSS/JavaScript minification separately, then rebuild the cache.
  4. JavaScript delivery: test defer and delay with exclusions for navigation, consent, payment, and builder-critical scripts.
  5. Images: keep native lazy loading, then test LCP preloading and WebP/AVIF conversion.
  6. Infrastructure: add Redis, LiteSpeed, CDN, PageSpeed, RUM, or ESI one at a time.

Server notes

Apache and LiteSpeed Enterprise can apply marked .htaccess changes at runtime. OpenLiteSpeed reads the file on server start, so restart LiteSpeed after rule changes. Nginx does not evaluate .htaccess; copy the generated rules from the dashboard into the server configuration instead.

Verify the install

wp wppo verify
wp wppo cache status
curl -sI https://example.com/ | grep -iE \'x-litespeed-cache|etag|last-modified|vary|content-encoding\'

A cache hit may be identified by the plugin\’s ETag/Last-Modified validators or by LiteSpeed\’s X-LiteSpeed-Cache header, depending on the selected cache owner. Confirm the exact behavior on the server you operate.

Deactivate and uninstall

Deactivation removes plugin-owned cron events, owned drop-ins, the Redis configuration file, and the WP_CACHE guard when it created them. Uninstall additionally removes plugin options, activity data, generated cache files, converted-image copies, and post meta. Original Media Library uploads are never deleted by the uninstall routine.