Is it working?

Request any HTML page twice with curl -I and read one header. Which header you look for depends on how you run mod_pagespeed 2.1.

curl -I http://localhost/
curl -I http://localhost/

The header, per integration

Integration	Header	Value	Means
Apache module	X-Mod-Pagespeed	the module version (XHeaderValue changes it)	the module handled the response
nginx module (native)	X-Page-Speed	the module version	the module handled the response
IIS module	X-Page-Speed	the module version	the module handled the response
Docker / nginx reverse proxy	X-PageSpeed	MISS	proxied to the origin, stored, the worker notified
		HIT	served from the cache
		STALE, with X-PageSpeed-Stale: if-error	the origin failed; a stale cached entry was served instead
		REVALIDATED, with X-PageSpeed-Revalidation: 304	the origin confirmed the cached entry; served from the cache
		async-css-loader	the small loader script the module serves itself
ASP.NET Core middleware	X-PageSpeed	MISS, then HIT	as the reverse proxy; the /console/* routes carry no header

On the Apache, nginx and IIS modules the header appears on every response the module handles, whether or not anything on that page was rewritten. Its presence confirms the module is loaded and pagespeed on applies to that site; the admin console tells you what it did.

First MISS, then HIT

The Docker reverse proxy and the ASP.NET Core middleware optimize off the request path. The first request for a URL serves the original bytes, stores them in the cache and notifies the worker; the worker builds the optimized variants in the background; the next request for the same URL and client class is served from the cache with X-PageSpeed: HIT. A second MISS a moment later usually means the worker had not finished yet. Wait and retry before you look for a fault.

To see an optimization rather than a cache outcome, ask for an image in a format the browser would accept. The URL stays the same; the bytes and the Content-Type change:

curl -s -o /dev/null -D - http://localhost/<your-image>.jpg -H 'Accept: image/jpeg'
# Content-Type: image/jpeg   — original
curl -s -o /dev/null -D - http://localhost/<your-image>.jpg -H 'Accept: image/webp'
# Content-Type: image/webp   — smaller, once the worker has processed it

On the native module with the optimizer worker attached, the admin console’s Statistics page shows the same thing as counters: ipro_daemon_served rises as in-place requests are answered from the worker’s cache, and ipro_daemon_fallthrough counts the ones the ordinary path answered.

Turn it off for one request

On the Apache, nginx and IIS modules, append ?PageSpeed=off to any URL to get the response as the origin serves it. ?ModPagespeed=off is the older spelling; both names are read on every platform. The values on, off, unplugged and noscript are honoured without a token; any other query option needs the RequestOptionOverride token set on the server. Compare the two responses to see what the module changed on that page.

The Docker reverse proxy does not read these parameters. Compare an optimized and an original response with the Accept header instead, as above.

The admin console

The Apache, nginx and IIS modules serve an admin console at /pagespeed_admin/ (one virtual host) and /pagespeed_global_admin/ (the whole server). Its Overview page answers the three questions at a glance: is the module working, is the optimizer worker healthy, and what have they saved. Both paths can purge caches and show configuration, so the shipped examples allow localhost only; see Admin console setup before you widen that.

Worker health

The optimizer worker answers two health probes:

• The health socket, always on. It is the notification socket’s path with .health appended: /run/pagespeed-optimizer/notify.sock.health for the packages, /data/pagespeed.sock.health in the container images. It answers one line starting with OK, or DEGRADED when the worker runs without its cache:

  socat -u -T 4 UNIX-CONNECT:/run/pagespeed-optimizer/notify.sock.health -
  # OK 5/128 notifs=1542 variants=986 proactive=724 errors=3 cache_entries=2048 inflight=3

• GET /v1/health on the management API, which is off until you enable a transport. On the packages, set OPTIMIZER_OPTS=--api-socket in /etc/default/pagespeed-optimizer and restart; the API then listens on /run/pagespeed-optimizer/api.sock, and /v1/health needs no token on any transport:

  curl --unix-socket /run/pagespeed-optimizer/api.sock http://localhost/v1/health

  The answer carries status, ready, a checks table, version, uptime_seconds, connections, inflight, browser_sandbox and syscall_filter. ready: true is the field to probe.

The worker also serves the web console at /console/ on the same API. Monitoring covers the metrics behind these probes and what to alert on.

If something is off

You see	Start here
No header at all	No X-Mod-Pagespeed or X-Page-Speed header
MISS on every request	Cache miss on every request
MISS on every reload in Chrome	MISS on every reload in Chrome
The header is there, images stay unchanged	Worker not processing content
WebP or AVIF never appears	Images not converting to WebP/AVIF
The ASP.NET Core dashboard reads zero	ASP.NET Core dashboard shows zeros

The HTML attributes, .pagespeed. URLs and the beacon endpoint you may meet in a page’s source are explained on PageSpeed markers.