web-frontend-pagespeed

Verifies HTTP caching and compression behavior of web assets using curl-based header and byte checks.

1|Updated Jun 23, 2026
One-click install
npx skills add https://github.com/bitranox/bitranox-skills --skill web-frontend-pagespeed-bitranox
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-frontend-pagespeed
Source: https://github.com/bitranox/bitranox-skills/tree/main/plugins/bitranox/skills/web-frontend-pagespeed
Command: npx skills add https://github.com/bitranox/bitranox-skills --skill web-frontend-pagespeed-bitranox

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Caching and compression misconfigurations fail silently: bandwidth or CDN costs rise with flat request volume, bundles get refetched on every navigation, and assets refuse to pick up new deploys, all without any error. Worse, the standard checks themselves can lie - a curl -I HEAD request can report a clean result that was never capable of detecting the problem. ## Core Features & Use Cases - False-clean detection: Explains why HEAD-based compression checks, no-cache without validators, and nginx add_header inheritance produce misleading results, and how to confirm with GET requests and wire-byte comparison. - Decision rules: Covers when immutable is safe (only with content-hashed URLs), how gzip_types literal matching against text/javascript breaks compression, and how ^~ prefix locations stop regex evaluation. - Use Case: Egress traffic jumps 3x after a frontend rewrite with flat request counts. Use this Skill to run GET-based header and byte-size checks at the CDN edge, identify a gzip_types mismatch and missing cache validators, and fix the nginx config. ## Quick Start Ask the AI to verify whether your site's static assets are actually being cached and compressed, using GET requests to compare response headers and wire bytes.

Frequently Asked Questions about web-frontend-pagespeed

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if gzip compression is actually working on my site?▼

Send a GET request with an Accept-Encoding: gzip header and compare the wire bytes against an uncompressed request, rather than trusting the Content-Encoding header alone. A plain curl -I HEAD request sends no Accept-Encoding, so it can report a false negative.

Why does Cache-Control: no-cache still cause full downloads?▼

no-cache means revalidate every time, not do-not-store. Revalidation is only cheap (a 304) if the origin emits an ETag or Last-Modified validator; a proxied app that sends neither turns each revalidation into a full 200 response with the entire body.

When is it safe to use the immutable cache directive?▼

immutable is only safe when the asset URL changes with its content, such as a hashed or versioned filename. On a fixed URL it leaves clients stuck with a stale asset until expiry with no way to push a fix, so use a bounded max-age until the build fingerprints filenames.

Why does gzip_types not compress my JavaScript files in nginx?▼

gzip_types matching is literal against the response Content-Type. Listing only application/javascript does not match text/javascript, which is what modern servers actually send, so nothing gets compressed.

Why did my nginx location block lose its security headers?▼

A location with its own add_header directive drops all inherited server-level headers, while a location with none inherits the whole set. Adding a single header to a location silently removes the rest there.

What does this pagespeed skill not cover?▼

The skill currently covers only caching and compression verification. Core Web Vitals, LCP, render-blocking resources, image strategy, preload hints, and Lighthouse workflows are explicitly declared as not yet written.