Check whether my app's text responses are being compressed in production and fix it if not. 1. Verify first: check the production response headers for Content-Encoding (br or gzip) on my HTML, CSS, JavaScript, JSON API responses, and SVGs. Use curl with an Accept-Encoding header, not just browser dev tools, so we see what a real client gets. If a CDN or platform sits in front (Cloudflare, Vercel, Netlify, Fly, etc.), check at both the edge and the origin, because the platform may already handle it or may be passing through uncompressed responses. 2. Enable where missing: if my app server is responsible, add compression middleware (the compression package for Express, or my framework's equivalent) with brotli preferred and gzip as fallback. If the CDN is responsible, enable it in the CDN config. Do not double-compress; enable at one layer. 3. Scope correctly: compress text types only (HTML, CSS, JS, JSON, SVG, fonts that are not already compressed). Never compress images, video, or already-compressed formats; it wastes CPU and can grow responses. 4. Dynamic vs static: for static assets, use pre-compressed files where the platform supports it (build-time .br and .gz files) so the server does not recompress on every request. For dynamic responses, on-the-fly compression at a sensible level is fine. 5. Confirm the win: measure the transfer size of my main page and largest JS bundle before and after, and report the savings. Do not compress responses under ~1KB; the overhead is not worth it. Do not enable compression for responses that contain secrets reflected from the URL combined with user input without considering BREACH-style attacks; flag if any page does that. Give me: where compression was missing, what you enabled and at which layer, and the before/after transfer sizes.