Install GT Performance

Requirements

WordPress	6.6 or newer, single site (activation stops on multisite)
PHP	8.1 or newer
Extensions	dom, json, openssl
wp-config.php	A real AUTH_KEY (16+ characters, not the sample placeholder). The runtime configuration the drop-ins read is encrypted with a key derived from it.
Database	MySQL or MariaDB, or SQLite on WordPress Studio and Playground
Writable	wp-content/cache/, and wp-content/ for drop-ins
Optional	A Redis server and the PhpRedis extension for the object cache

Works on shared hosting. Nothing requires root, a worker, or a paid tier of anything.

Install

1. In wp-admin, go to Plugins > Add New Plugin, search for GT Performance, then click Install Now and Activate. To install by hand, download gt-performance.zip and upload it under Plugins > Add New Plugin > Upload Plugin.
2. Open GT Performance in the admin menu and go to the Setup tab. Activation does not take you there on its own.
3. Work through the six steps: server checks, other caches, cache mode, Cloudflare (optional), store and language plugins, and Verify. See Setup.
4. Enable only the modules you have tested against your theme.

In Setup’s cache mode step, Save cache mode with Store pages copies advanced-cache.php into wp-content/ and enables WP_CACHE in wp-config.php. Until that runs, origin caching is configured but inactive. Install page-cache drop-in on the Dashboard does the same. On a host that already caches pages (LiteSpeed, Kinsta, Hostinger, SiteGround, WP Engine, Varnish and others), choose Optimize only instead: nothing is installed, and the host’s cache stores the optimized pages. See Page Cache.

If wp-config.php already declares WP_CACHE in a way the plugin can’t safely edit, or isn’t writable, add the line yourself just after the opening <?php:

define( 'WP_CACHE', true );

Updates come from WordPress.org like any other directory plugin.

Verify it works

Setup > Verify requests the home page as a visitor up to four times, two seconds apart, and passes when GT Performance serves it from its cache. To check by hand:

curl -sSI https://example.com/ | grep -i x-gt-cache   # MISS
curl -sSI https://example.com/ | grep -i x-gt-cache   # HIT

Test logged out. wordpress_logged_in_ is a bypass cookie, so a signed-in request will never hit. A bypassed request sends X-GT-Cache: BYPASS with an X-GT-Cache-Reason only while Diagnostic logging is on; see Diagnostics.

wp gt-performance doctor

should report the page-cache drop-in owned and WP_CACHE enabled in Store pages mode. In optimize-only mode the drop-in is not used, and wp gt-performance cache status prints mode=optimize-only.

A sane rollout order

Each step is independently reversible. Do them one at a time and check the site in between. Front-end optimizations only run on responses the page cache stores, so they need step 1 in place, and signed-in visitors always see the unoptimized page.

1. Page cache only. Live with it for a day. Turn on Cache Warming once hits look right.
2. Media: lazy loading and dimensions. Low risk, real Core Web Vitals gain.
3. Fonts: self-host Google Fonts. Removes third-party requests.
4. Unused CSS at a 10% rollout, then raise it. See CSS Optimization.
5. JavaScript minify, then defer, then (only if you need it) delay.
6. Cloudflare or a CDN, once the origin behaves.
7. Redis object cache, if you have Redis.

Skipping to step 5 on a live store is how people conclude caching plugins are dangerous.

Deactivating and uninstalling

Deactivating:

• turns the origin page cache off in the runtime configuration, removes the page-cache and object-cache drop-ins if GT Performance owns them, and puts WP_CACHE back the way it found it;
• empties the local page store, because nothing purges while the plugin is off and a page edited in the meantime would otherwise come back as a HIT;
• with Cloudflare connected, deletes this site’s managed Cache Rule (no other rule) and purges this site’s hostnames at Cloudflare. This is best effort: an unreachable zone does not block deactivation, and wp gt-performance cloudflare disconnect can finish it later. See Cloudflare;
• unschedules its background events.

Saved settings are not changed. After reactivating, reinstall the drop-in from Setup (Save cache mode with Store pages) or the Dashboard, and run Connect/sync Cloudflare to recreate the Cache Rule. The Cloudflare tab says the rule is gone until you do.

Deleting the plugin keeps your settings and data unless Remove all data when the plugin is deleted is enabled (Optimization tab, Diagnostics panel). With it on, uninstall removes the plugin’s options, its gtperf_* database tables, and the whole wp-content/cache/gt-performance/ directory, including the Redis configuration file, which holds credentials.