Repository navigation
Setup
The Setup tab takes a fresh install to a verified cached page in six steps. It checks this server, looks for other page caches, picks a cache mode, connects Cloudflare if you use it, lists the store and language plugins that need a decision, and then requests your home page as a visitor until the cache answers.
Nothing on the tab changes the site until you press one of its buttons, and you can run it again at any time. Activating the plugin does not redirect you here. Until verification passes, the Dashboard's Recommended next step says to run setup and links to the tab.
What GT Performance needs before it can store anything. Each row reads Ready or Fix first:
| Row | Ready when |
|---|---|
| WordPress security keys |
AUTH_KEY is at least 16 characters and not the placeholder from wp-config-sample.php. The runtime configuration and saved credentials are encrypted with a key derived from it. wp config shuffle-salts generates real keys |
| OpenSSL | The PHP OpenSSL extension is available |
| Cache directory |
wp-content/cache (or GT Performance's directory inside it) is writable |
| advanced-cache.php | No other plugin owns wp-content/advanced-cache.php. When one does, deactivate that cache plugin or choose Optimize only in step 3 |
A second page cache in front of this one decides what visitors get, so this step looks for two kinds:
- Page-cache plugins. Active plugins that run their own page cache. Deactivate them, or let one own the cache: two page caches store and purge independently. See Integrations.
-
Host page cache. Found without a request when the environment declares it (Kinsta's
KINSTA_CACHE_ZONE, WP Engine'sWpeCommonclass, Pantheon'sPANTHEON_ENVIRONMENT, or xCloud's page cache as reported by the xCloud integration). Detect host cache also fetches your home page once as a visitor, with no cookies, and reads the response headers.
The headers the probe recognizes. A header counts when it is present, whatever its value, so a MISS still shows the cache is there:
| Response header | Reported as |
|---|---|
x-litespeed-cache |
LiteSpeed Cache |
x-kinsta-cache |
Kinsta |
x-hcdn-cache-status |
Hostinger CDN |
x-site-optimizer |
Hostinger Site Optimizer |
platform containing hostinger
|
Hostinger |
x-proxy-cache |
SiteGround Dynamic Cache |
x-wpe-cached, x-cacheable
|
WP Engine |
x-varnish |
Varnish |
x-fastcgi-cache |
Nginx FastCGI cache |
x-nginx-cache |
Nginx cache |
x-srcache-fetch-status |
Nginx SRCache |
x-ac |
WordPress.com Batcache |
x-pantheon-styx-hostname |
Pantheon Global CDN |
x-sucuri-cache |
Sucuri |
The probe's result is kept in the gt_performance_setup_probe option, so the tab shows it until you detect again.
Who stores the pages:
| Mode | What happens |
|---|---|
| Store pages | GT Performance serves cached pages before WordPress loads. Saving installs wp-content/advanced-cache.php and sets WP_CACHE in wp-config.php; deactivating the plugin removes both |
| Optimize only | Your host's cache stores pages. GT Performance optimizes them on the way in and changes no server files |
The step marks one mode (recommended here): Optimize only when step 2 found a host page cache, Store pages otherwise. A site that already runs optimize-only, or store mode with the drop-in in place, keeps its current mode preselected; an unfinished setup starts from the recommendation.
Save cache mode turns on Enable origin page cache, saves the mode, and in store mode installs the drop-in and WP_CACHE, exactly as Install page-cache drop-in does. The status beside the button reads Now: optimize only, Now: store pages, drop-in in place, or Now: store pages, drop-in or WP_CACHE missing. The same choice is on the Page Cache tab. See Page Cache.
Skip this step if the site is not on Cloudflare. Otherwise enter a Scoped API token (Zone Read, Cache Rules Edit and Cache Purge) and the Domain of the zone, save, then press Connect/sync Cloudflare. That is the same sync the Cloudflare tab runs: it creates or updates this site's managed Cache Rule, leaves your other rules alone, and purges this site's hostnames at Cloudflare afterwards. The connection check, the DNS and APO checks, and the other options are on the Cloudflare tab. See Cloudflare.
What is kept out of the cache on this site, and what needs a decision from you:
- Store plugins. When WooCommerce, Easy Digital Downloads or FluentCart is active, its cart, checkout and account pages and shopper cookies bypass the cache automatically. See Commerce Safety.
- Language and currency plugins. A plugin that can show visitors different pages at the same URL is flagged Review. The Integrations tab says what to set for each before you rely on the cache. See Integrations.
Verify requests your home page as a visitor, with no cookies, until the cache answers: up to four times, two seconds apart. A cold page takes one request to store at the origin and another to fill the edge.
In Store pages mode, verification passes when GT Performance serves the page from its cache (X-GT-Cache: HIT or STALE). With Cloudflare connected, Cloudflare's own answer (CF-Cache-Status) is shown beside the result but does not decide it: right after a full purge the edge can keep answering MISS for a while after the origin already serves hits. A Cloudflare HIT alone also passes, because a copy cached at the edge never reached the origin and proves the origin stored the page.
| Status | Meaning |
|---|---|
| Passed | Served from the cache (and from Cloudflare too, when it is connected) |
| Origin verified | GT Performance served the page from its cache, but Cloudflare has not answered HIT yet. Verify again in a minute or two; if it never does, sync Cloudflare and check that the DNS record is proxied |
| Not yet | The last attempt did not pass. The detail says why: the home page did not return 200, it is sent as private or sets a cookie (open Explain this page on Tools to see which rule applies), or it was not served from the origin cache (check the drop-in and WP_CACHE) |
| Not run | Verification has not run yet |
In Optimize only mode, verification passes when the home page comes back as a public 200 response. The host's cache stores the optimized version; the plugin does not.
The detail line shows the result, GT Performance's X-GT-Cache value, Cloudflare's cache status, and when it was checked. The last result is kept in the gt_performance_setup_verified option. The first pass records gt_performance_setup_completed, which is what stops the Dashboard pointing to Setup.
SetupReport.php · AdminModule.php
Installation · Page Cache · Cloudflare · Integrations · Diagnostics
GT Performance on WordPress.org · Changelog · Roadmap · GPL-2.0-or-later · Issues and pull requests welcome
Getting started
Caching
Optimization
Delivery
Operations
Reference
Links