served/compression
HTML responses are served compressed (brotli/gzip/zstd). Reglen served/compression kører i served-scope med severity 'warning' og indgår i servering-domænet sammen med 4 andre kontrakter i frameworket.
Hvorfor compression findes
Uncompressed text responses waste 70-85% of the bytes on the wire, directly inflating LCP — and crawlers crawl compressed sites measurably deeper. Any serious host/CDN does this; absence means misconfiguration.
Sådan håndhæves compression
Reglen compression evalueres mod den kørende server, fordi kravet bor i response headers eller statuskoder, som den statiske HTML ikke kan bære. Fejler en side, får agenten en finding, hvor fix-instruktionen for compression er formuleret som en konkret arbejdsordre med filnavne og målbare krav — aldrig et vagt råd. Severity 'warning' betyder at et brud på compression rapporteres uden at blokere builds — men guld-standarden er først nået, når også advarslerne er væk.
Domænet: servering
Served-domænet verificerer det, HTML'en ikke kan bære: security headers, CSP-kvalitet, HSTS, komprimering og ægte 404-statuskoder. Reglerne kører mod den levende server og parres med adapters-pakken, der genererer host-konfigurationen fra én kanonisk kilde. Netop derfor hører compression hjemme her: kravet kan afgøres maskinelt, og dermed kan det håndhæves i stedet for blot at blive anbefalet.
Test og fixtures
Som alle kontrakter i frameworket har served/compression en mutant-test, der beviser at reglen fejler, når kravet brydes — en regel uden en fejlende test er ikke en regel. Golden-fixturet beviser omvendt, at en fuldt compliant side består compression sammen med de øvrige 85 regler, og denne demoside er selv underlagt hele kontrakten.
Relaterede regler
Tilbage til oversigten over alle 86 regler.