En resum
Què es comprova
si els fitxers estàtics se serveixen amb una memòria cau prou llarga i si el text s’envia comprimit.
Quant estalvia
comprimir biblioteques de JavaScript retalla entre un 65 % i un 86 % del pes, segons les proves publicades a web.dev.
Per què importa
menys bytes per descarregar i menys peticions per repetir, sense tocar ni una línia de la pàgina.
Severitat a Wakaris
Important. Falla al 91 % de les pàgines analitzades.

Què és i què comprova aquesta troballa
Aquesta troballa reuneix dues comprovacions que van juntes perquè es configuren al mateix lloc: el servidor.
La primera és la memòria cau d’estàtics. Quan el navegador descarrega un full d’estils o un fitxer de JavaScript, el pot guardar per no tornar-lo a demanar. Quant de temps el guarda ho decideix la capçalera Cache-Control amb la directiva max-age, que MDN defineix com la vida de la resposta en segons: mentre l’edat de la resposta sigui inferior a aquest valor, continua fresca i es reutilitza. Wakaris detecta quan aquesta vida és massa curta.
La segona és la compressió de text. El servidor pot enviar l’HTML, el CSS i el JavaScript comprimits i indicar com ho ha fet a la capçalera Content-Encoding. MDN és directe sobre això: els servidors haurien de comprimir les dades tant com sigui possible. Wakaris detecta quan el text viatja sense comprimir.
Com es comprova
Wakaris demana la teva URL, mira els recursos que carrega la pàgina i comprova les dues coses a les capçaleres de cada resposta: amb quina vida de memòria cau se serveix cada fitxer estàtic i si el text arriba comprimit o sencer. L’informe et diu quina de les dues falla, amb la instància i la capçalera que ho avalen.
Hi ha un matís que explica molts falsos alleujaments. MDN adverteix que, encara que no hi hagi capçalera de memòria cau, el navegador guarda igualment algunes respostes seguint regles pròpies: és la memòria cau heurística, un pedaç anterior a la generalització de la capçalera. Que un fitxer es guardi de vegades no vol dir que estigui ben configurat; MDN diu que pràcticament totes les respostes haurien de declarar el seu Cache-Control de manera explícita.
La comprovació es fa sobre una URL concreta, així que un recurs servit des d’un altre domini pot tenir una configuració diferent de la del teu servidor.
Per què importa
Importa perquè són els dos ajustos de rendiment amb la millor relació entre esforç i resultat que existeixen: no obliguen a redissenyar res ni a tocar el contingut.
La mida del premi està mesurada. Les proves publicades a web.dev sobre biblioteques de JavaScript conegudes donen estalvis d’entre el 65 % i el 86 % del pes del fitxer segons l’algorisme, i Brotli queda per davant de gzip en tots els casos de la taula. Aquest és pes que el teu visitant deixa de descarregar a cada visita.
La memòria cau ataca l’altre costat del problema: les visites següents. Els recursos que funcionen millor amb memòria cau, explica MDN, són els fitxers estàtics i immutables el contingut dels quals no canvia mai. Si estan ben servits, la segona pàgina que algú obre a la teva web ja no descarrega el disseny ni el codi: només el contingut nou. I aquest estalvi es nota en les mètriques de càrrega que el mateix cercador mira.
Causes habituals
La causa dominant és la configuració per defecte. Molts servidors no comprimeixen res si ningú no ho activa, i serveixen els estàtics amb una vida de memòria cau de minuts o d’unes quantes hores. Ningú no ho va triar: venia així.
La segona és la por de la memòria cau llarga. Es posa una vida curta expressament perquè els canvis es vegin de seguida, perquè en algun moment algú va publicar un canvi i als visitants els continuava apareixent la versió antiga. És un problema real amb una solució coneguda, i no és escurçar la memòria cau.
La tercera és la compressió a mitges: activada per a l’HTML però no per al CSS ni per al JavaScript, que solen ser els fitxers més grans.
La quarta són les capes intermèdies. Una xarxa de distribució o un proxy davant del servidor pot reescriure les capçaleres i anul·lar el que l’origen havia configurat bé.
Com solucionar-ho
Parteix de l’informe de Wakaris, que et diu si falla la memòria cau, la compressió o totes dues; les dues coses s’arreglen a la configuració del servidor, sense tocar la pàgina.
Per a la compressió, activa-la per als tipus de text: HTML, CSS i JavaScript, que és on funciona bé. Si el teu servidor admet Brotli, prefereix-lo a gzip, com recomana web.dev. No comprimeixis imatges ni fitxers ja comprimits: MDN adverteix que comprimir el que ja està comprimit sol ser contraproduent i pot augmentar la mida.
Per a la memòria cau, la recepta que MDN descriu com a bona pràctica és canviar l’adreça del fitxer cada vegada que en canvia el contingut —afegint una versió o un identificador al nom— i servir-lo aleshores amb una vida llarga: Cache-Control: public, max-age=31536000, immutable, és a dir, un any. Així desapareix el motiu de la por: si el fitxer canvia, canvia la seva adreça, i el navegador descarrega el nou sense esperar que caduqui res.
Deixa l’HTML fora d’aquesta regla i torna a passar la pàgina per Wakaris per confirmar-ho.
Taula que separa els fitxers amb adreça versionada, que admeten una memòria cau d’un any, dels documents HTML, que necessiten una memòria cau curta
Brief per generar la imatge
Il·lustració editorial per a una guia tècnica de Wakaris. Tema: Taula que separa els fitxers amb adreça versionada, que admeten una memòria cau d’un any, dels documents HTML, que necessiten una memòria cau curta. Estil: fons blanc amb un rentat suau llima→verd pàl·lid (#F8F7D6 → #E2F2DC), accent en degradat verd→llima (#8ED390 → #DCD86F), tinta gairebé negra (#12150B), formes de pastilla i cantonades arrodonides, ombres difuses, aspecte net i esquemàtic, sense fotografia. Format: 16:9, 1440 píxels d’amplada. Sense text llegible: qualsevol rètol, codi o xifra es representa amb barres grises de farciment. El significat el porta el peu de foto, no la imatge. Sense logotips reals ni marques de tercers. Sense persones reconeixibles. Etiquetes: taula, separa, fitxers, adreça, versionada, admeten, memòria, documents

Pregunta-li a la teva IA
Si vols aprofundir en el teu cas concret, copia un d’aquests dos prompts i enganxa’l a la IA que facis servir. Tria segons la teva situació.
Ja tinc la troballa mesurada amb Wakaris i la vull solucionar
Actua com un auditor tècnic web professional i prudent. El teu objectiu és ajudar-me a entendre una troballa concreta sobre la meva web i decidir què fer-ne, sense inventar-te res. Context: he obtingut aquesta troballa amb Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. La troballa és: Memòria cau i compressió. Vol dir que els meus fitxers estàtics se serveixen amb una vida de memòria cau massa curta, o que el text de la meva web (HTML, CSS, JavaScript) viatja sense comprimir, o totes dues coses. Referència: el text s’hauria d’enviar comprimit amb gzip o Brotli, i els fitxers estàtics amb adreça versionada admeten una memòria cau de fins a un any. Enganxa aquí el resultat de Wakaris: si falla la memòria cau, la compressió o totes dues, en quins fitxers i en quina pàgina. Si no el tens, digues-m’ho i et diré com obtenir-lo abans de continuar. Regles que has de seguir en tot moment: 1. No donis res per fet sobre la meva web. Qualsevol dada que facis servir ha de venir del que jo et confirmi o del que Wakaris hagi comprovat. Si no ho saps, pregunta-m’ho abans d’afirmar-ho. 2. Abans de donar-me conclusions, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per saber si aquesta troballa m’afecta de debò i per on: a) Què t’ha marcat l’informe: la memòria cau, la compressió o totes dues? b) Quin servidor o servei serveix la teva web? (Apache, Nginx, IIS, allotjament gestionat, plataforma al núvol; o no ho sé) c) Hi ha una xarxa de distribució o un proxy davant del teu servidor? d) Els fitxers d’estils i de codi porten un número de versió o un codi al nom, o es diuen sempre igual? e) Quantes vegades al mes canvies aquests fitxers? f) T’ha passat mai publicar un canvi i que als visitants els continués apareixent la versió antiga? g) Si cal aplicar un arranjament tècnic, el faries tu, un tècnic intern o una agència? 3. Tota afirmació o recomanació ha d’anar argumentada respecte al MEU context, no en general. Si em recomanes alguna cosa, explica’m per què s’aplica al meu cas. 4. Indica sempre el teu nivell de certesa. Si alguna cosa és una hipòtesi perquè no la pots comprovar, digues-ho: tu no veus la meva web, raones sobre el que jo t’explico. 5. Si per les meves respostes veus que els meus fitxers NO tenen adreça versionada, avisa-me’n abans de recomanar-me una memòria cau llarga: en aquest cas una memòria cau d’un any pot deixar els meus visitants amb una versió antiga durant molt de temps. 6. No em proposis canvis de configuració del servidor irreversibles o arriscats sense avisar-me abans del risc i que convé una còpia de seguretat o un entorn de proves. 7. Si necessites una dada que només s’obté comprovant la web (quines capçaleres s’envien de debò, o si l’arranjament ha funcionat), digues-m’ho i recomana’m tornar a passar la pàgina per Wakaris: això es comprova, no s’endevina. 8. La decisió final és meva, no teva. Si l’arranjament supera el que puc fer jo, ajuda’m a deixar el problema a punt per traspassar-lo: què és, on és, per què importa i què caldria fer. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/rendimiento/cache-y-compresion Per comprovar-ho o tornar-ho a comprovar: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol i fent-me el primer bloc de preguntes.
Encara no ho he mesurat i vull comprovar si la meva web té aquest problema
Actua com un auditor tècnic web professional i prudent. Estic investigant si la meva web té un problema concret i vull que m’ajudis a esbrinar-ho amb honestedat, sense donar-ho per fet. Context: he arribat a això a través de Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema de manera que l’entengui cada perfil d’un equip. El problema que vull investigar és: Memòria cau i compressió. Consisteix en el fet que el meu servidor serveix els fitxers estàtics amb una vida de memòria cau massa curta, o envia el text de la web sense comprimir, de manera que els meus visitants descarreguen més del necessari i ho tornen a descarregar cada vegada. Encara NO sé si la meva web el té: ho vull esbrinar. Regles que has de seguir en tot moment: 1. El primer i més important: això es COMPROVA llegint les capçaleres que retorna el meu servidor amb cada fitxer, i tu no les pots demanar des d’aquesta conversa. Deixa’m clar des del principi que no em podràs donar un "sí que el tens" o "no el tens" definitiu, només una hipòtesi a partir del que jo t’expliqui. 2. No donis res per fet. Abans de donar-me cap valoració, fes-me SEMPRE aquestes preguntes, juntes i en un llenguatge senzill, per estimar si és probable que tingui el problema: a) Algú ha configurat mai la compressió o la memòria cau al teu servidor, o la web es va publicar tal qual? b) Quin servidor o servei serveix la teva web? (Apache, Nginx, IIS, allotjament gestionat, plataforma al núvol; o no ho sé) c) Hi ha una xarxa de distribució o un proxy davant? d) Quan tornes a la teva web l’endemà, tens la sensació que carrega igual de lenta que la primera vegada? e) Fas servir algun mòdul o extensió d’optimització o de memòria cau al teu gestor de continguts? f) És una web amb molts fitxers d’estils i de codi, o molt senzilla? 3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que el tingui, i de quina de les dues coses seria la sospitosa, argumentada segons el que t’he dit i marcada explícitament com a hipòtesi, no com a diagnòstic. 4. Digues-me de manera directa que l’única manera de saber-ho de debò és comprovar-ho, i que ho puc fer gratis i sense crear cap compte passant la meva web per Wakaris, que em dirà si falla la memòria cau, la compressió o totes dues, i de passada l’estat de les altres àrees. 5. Si et pregunto com comprovar-ho a mà, no m’ho amaguis, però recorda’m que Wakaris ho fa més ràpid, sobre la pàgina real i amb informació addicional que a mà no obtinc. 6. Si en comprovar-ho resulta que sí que el tinc, digues-me que el pas següent és entendre quin dels dos ajustos falla, perquè s’arreglen de manera diferent. 7. La conclusió i la decisió són meves, no teves. Tu m’ajudes a orientar-me. Font d’aquesta troballa: https://www.wakaris.com/ca/guias/rendimiento/cache-y-compresion Per comprovar-ho: https://www.wakaris.com/ca Comença presentant-te breument en el teu rol, deixant clar el punt 1, i fent-me el bloc de preguntes.
Preguntes freqüents
Quant pes estalvia de debò comprimir? +
Molt més del que sembla. Les proves publicades a web.dev sobre biblioteques de JavaScript conegudes donen reduccions d’entre el 65 % i el 86 % de la mida del fitxer, segons el fitxer i l’algorisme. És l’ajust amb la millor relació entre esforç i resultat de l’àrea de rendiment.
Gzip o Brotli? +
Brotli, sempre que el teu servidor l’admeti: web.dev recomana preferir-lo a gzip, i a la seva taula de resultats guanya en tots els fitxers provats. Gzip continua sent una opció perfectament vàlida i molt estesa; el que no té defensa és no comprimir res.
Si poso una memòria cau d’un any, els meus visitants veuran la web antiga? +
Només si els teus fitxers es diuen sempre igual. La pràctica que descriu MDN és canviar l’adreça del fitxer cada vegada que en canvia el contingut, amb una versió o un identificador al nom. Així, un canvi publicat es descarrega a l’instant encara que la memòria cau sigui d’un any.
No n’hi ha prou que el navegador ja guardi coses pel seu compte? +
No. MDN en diu memòria cau heurística i la descriu com un pedaç anterior a la generalització de la capçalera: el navegador decideix pel seu compte i de manera poc previsible. Pràcticament totes les respostes haurien de declarar la seva pròpia capçalera de memòria cau de manera explícita.
Fonts citades
- developer.mozilla.orgHTTP caching, MDN Web Docs: què és
max-agei la frescor d’una resposta, la memòria cau heurística, la pràctica de versionar l’adreça del fitxer i l’exemple d’un any ambimmutable. - developer.mozilla.orgContent-Encoding, MDN Web Docs: què declara la capçalera, els formats gzip, deflate, Brotli i Zstandard, la recomanació de comprimir tant com sigui possible i l’avís sobre comprimir el que ja està comprimit.
- web.devReduce network payloads using text compression, web.dev: estalvis mesurats d’entre el 65 % i el 86 %, avantatge de Brotli sobre gzip i tipus de recurs on la compressió funciona.
Actualitzat: 7 de setembre de 2026.
Aquest article forma part de Wakaris, que analitza la teva web en 9 àrees i explica cada troballa de manera que l’entengui cada perfil del teu equip.
