RendimentLimita

Memòria cau i compressió: els dos ajustos que més pes treuen a una web

La compressió fa que els teus fitxers de text viatgin molt més petits. La memòria cau fa que no tornin a viatjar a la visita següent. Són dos ajustos del servidor, no del disseny, i gairebé cap web no els té ben configurats. Wakaris comprova tots dos sobre la teva pàgina real.

Per Juan Ignacio FrancoActualitzat: 7 de setembre de 20267 min de lectura

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.

Comparació d’una mateixa visita amb memòria cau i compressió i sense: en el primer cas es descarreguen tots els fitxers a mida completa, en el segon arriben comprimits i alguns no es demanen
Dos estalvis diferents: la compressió redueix el que viatja; la memòria cau evita que torni a viatjar.

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.

Imatge pendent · {IMG_2}

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
La memòria cau llarga és per al que té adreça versionada. L’HTML no entra mai en aquesta regla.
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
La memòria cau llarga és per al que té adreça versionada. L’HTML no entra mai en aquesta regla.

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ó.

Prompt A

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.
Enganxa’l a la IA que facis servir.
Prompt B

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.
Enganxa’l a la IA que facis servir.

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-age i 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 amb immutable.
  • 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.
Retrat de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de dades · Bitanube

Juan Ignacio Franco és analista de dades a Bitanube. Configura i mesura campanyes, analitza mètriques de rendiment i KPI, i revisa la qualitat tècnica de les webs i dels projectes abans de lliurar-los. Les troballes d’aquestes guies són les que apareixen en aquesta feina.

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.

Comparteix aquesta guia
Comença ara

La teva web té molt per explicar-te
I per fi l’entendràs

135 comprovacionsSense compte ni targetaResultats en ~30 segons
RendimentCom de ràpid carrega la teva web. Si triga, perds visites i vendes abans que et vegin.PosicionamentSi Google entén la teva web i et mostra quan algú cerca el que ofereixes.SeguretatSi la teva web està protegida. Un error aquí espanta clients i Google per igual.PresènciaCom apareixes a Google, a les xarxes i als mapes. És la primera imatge que dones abans que et contactin.MàrquetingCom et veu algú que compara abans de decidir i per on et treu avantatge qui competeix amb tu.Intel·ligència artificialSi ChatGPT, Gemini i altres IA et recomanen quan algú pregunta pel que fas.ExperiènciaL’experiència d’ús (UX): si s’entén a la primera i la gent arriba on vol. Una web confusa s’abandona encara que carregui ràpid.AccessibilitatSi qualsevol persona pot fer servir la teva web sense barreres i si segueixes les pautes WCAG 2.2. Més públic que t’entén.LegalSi compleixes amb les galetes i la protecció de dades. Evita sancions i multes que fan mal.

Suri

Assistent de Wakaris