Com fer la teva web més ràpida: una llista de comprovació pràctica

Per fer una web més ràpida, mesura-la primer amb PageSpeed Insights i després arregla la causa més gran que assenyali —normalment imatges massa grans, massa JavaScript, tipografies pesants o scripts de tercers. Apunta als objectius «bons» dels Core Web Vitals de Google: contingut principal visible en 2,5 segons, respostes als tocs en 200 mil·lisegons i gairebé cap salt de disseny. La majoria de webs hi arriben amb una sèrie de canvis, no amb una reescriptura.

Mesura abans de canviar res

Endevinar fa perdre temps. Dues eines gratuïtes cobreixen gairebé tothom:

• PageSpeed Insights (pagespeed.web.dev) —enganxa una URL en directe. Mostra les dades de camp d'usuaris reals de Chrome (si el teu lloc té prou trànsit) i les dades de laboratori d'una càrrega simulada, més una llista de problemes concrets.
• Lighthouse a les eines de desenvolupador de Chrome —la mateixa prova de laboratori, executada en qualsevol pàgina que puguis obrir, inclosa una vista prèvia. Prova en mode mòbil; els telèfons en xarxes més lentes són on es fan visibles els problemes.

Les xifres que importen són els Core Web Vitals de Google. A partir de setembre de 2026, la documentació de Google a web.dev dona aquests llindars «bons», mesurats al percentil 75 de les càrregues de pàgina:

L'INP va substituir l'antiga mètrica First Input Delay el 2024. Si una eina encara informa de FID, està desactualitzada.

Anota les teves xifres inicials. Després de cada correcció, torna a provar perquè sàpigues què ha ajudat.

On es perd el temps: opcions i compromisos

Cada causa habitual té una solució, i cada solució té un cost. Comença per les de dalt: són les més barates i les més comunes.

Imatges

Les imatges són el problema més comú i el més fàcil d'arreglar. Una foto de 4.000 píxels mostrada a 800 píxels d'amplada obliga cada visitant a descarregar cinc vegades més del que veu.

• Serveix les imatges a la mida en què es mostren, amb mides srcset adaptables per a telèfons i ordinadors.
• Usa formats moderns (WebP o AVIF) i una compressió sensata.
• Defineix width i height a cada imatge perquè el navegador reservi l'espai. Només això arregla la majoria del salt de disseny.
• Carrega en diferit les imatges sota la línia de plegat amb loading="lazy".
• Mai no carreguis en diferit la imatge principal de la part superior de la pàgina. La guia de LCP de Google és clara: carregar en diferit la imatge LCP sempre la retarda. Dona-li fetchpriority="high" en lloc d'això.

JavaScript

Moltes webs fetes amb IA són aplicacions d'una sola pàgina (SPA): el navegador descarrega un paquet de JavaScript i després dibuixa la pàgina. Com més gran és el paquet, més dura la pantalla en blanc. Solucions, en ordre d'esforç:

1. Elimina el que no uses. Demana una llista de dependències i talla les biblioteques que es van afegir una vegada i es van oblidar —una biblioteca de dates per a una sola data, un paquet complet d'icones per a cinc icones.
2. Divideix per ruta. Carrega el codi del tauler d'administració només quan algú l'obre, no a la pàgina d'inici.
3. Preprocessa les pàgines públiques. Una pàgina de màrqueting que arriba com a HTML real apareix abans que s'executi cap JavaScript. Això també ajuda els motors de cerca; consulta SEO per a webs construïdes amb IA.

Un INP lent normalment vol dir una tasca llarga que bloqueja la pàgina —filtrar una llista enorme a cada tecla, o tornar a renderitzar una taula sencera quan canvia una cel·la. El panell de Rendiment de les eines de desenvolupador de Chrome mostra quina és.

Tipografies

Cada família i pes de lletra és un altre fitxer. Dues famílies i tres o quatre pesos solen ser suficients. Precarrega la tipografia que s'usa per sobre de la línia de plegat, usa font-display: swap perquè el text es mostri de seguida, i autoallotja les tipografies si el servei extern és lent per als teus visitants.

Scripts de tercers

Els xats, l'analítica, els mapes de calor, els píxels d'anuncis, els vídeos incrustats i els fils socials carreguen codi d'altres servidors. Cadascun sembla petit; junts sovint són la part més lenta de la pàgina. Mantén els que realment mires. Carrega la resta després que la pàgina sigui interactiva, i substitueix les incrustacions pesades (un reproductor de YouTube, un mapa) per una vista prèvia lleugera que carregui l'original en fer clic.

Resposta del servidor

El temps fins al primer byte (TTFB) —quant triga el servidor a començar a respondre— està sota totes les altres mètriques. Les pàgines estàtiques servides des d'una CDN (una xarxa de servidors a prop dels teus visitants; consulta què és una CDN) són ràpides gairebé a tot arreu. Les pàgines que construeix un servidor a cada sol·licitud depenen d'aquest servidor i de la seva base de dades. Emmagatzemar en memòria cau el treball repetit i afegir índexs a la base de dades per a les consultes lentes són les solucions habituals.

Indicacions que funcionen

Sigues específic: nomena la pàgina, la mètrica i la restricció. Enganxa les troballes de PageSpeed Insights si les tens.

PageSpeed Insights informa d'un LCP de 4,8 s en mòbil per a la pàgina d'inici, i l'element LCP és la imatge destacada. Redimensiona i converteix la imatge destacada a WebP, serveix mides adaptables, defineix width i height, dona-li fetchpriority="high" i assegura't que no es carrega en diferit. Carrega en diferit totes les imatges sota la línia de plegat. No canviïs el disseny.

Audita les dependències d'aquesta app. Enumera cada paquet, què l'usa i aproximadament quant afegeix al paquet. Elimina els que no s'usen i divideix les rutes /admin i /settings en fragments separats que es carreguin només quan s'hi accedeix.

La caixa de cerca de /products se sent lenta. Aplica un debounce al filtre, evita tornar a renderitzar tota la llista a cada tecla, i pagina o virtualitza la llista si té més de 200 elements.

Pas a pas

1. Prova la pàgina en directe a PageSpeed Insights en mòbil. Anota el LCP, l'INP i el CLS, i els tres problemes principals que llisti.
2. Arregla primer les imatges: mides, formats, dimensions, càrrega en diferit sota la línia de plegat, prioritat per a la destacada.
3. Talla els scripts de tercers que no usis, i carrega la resta en diferit.
4. Redueix les tipografies a les que el disseny necessita.
5. Redueix el JavaScript: elimina els paquets no usats, divideix per ruta.
6. Preprocessa les pàgines públiques si encara es renderitzen al client i el LCP continua lent.
7. Revisa el servidor: memòria cau, índexs de base de dades, allotjament estàtic per al contingut que canvia poc.
8. Torna a publicar i torna a provar. Les dades de camp a PageSpeed Insights s'actualitzen durant les setmanes següents a mesura que arriben visites reals, així que jutja els primers resultats per les dades de laboratori.

Errors habituals

• Provar només en un portàtil ràpid. Els teus visitants estan en telèfons de gamma mitjana i dades mòbils irregulars. Prova en mode mòbil.
• Perseguir un 100 perfecte. La puntuació de laboratori és una guia. Quan els Core Web Vitals estan en el rang bo, el contingut i la usabilitat importen més que els últims punts.
• Carregar en diferit tot, inclosa la imatge destacada. Això empitjora el LCP.
• Afegir un plugin o una biblioteca de velocitat a sobre. Treure pes gairebé sempre guanya a afegir codi per gestionar-lo.
• Optimitzar la vista prèvia, no el lloc en directe. Les vistes prèvies de desenvolupament executen compilacions sense optimitzar. Mesura la URL publicada.
• Arreglar la velocitat una sola vegada. Cada widget, imatge i funció nous afegeix pes. Torna a provar després dels canvis grans.

Llista de comprovació de velocitat

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 en mòbil
• Imatges redimensionades, comprimides, en format modern, amb width i height
• La imatge destacada no es carrega en diferit; les imatges sota la línia de plegat sí
• Sense biblioteques de JavaScript no usades; les rutes pesades separades
• Dues famílies de tipografia o menys, tipografia principal precarregada
• Només els scripts de tercers que realment uses, carregats tard
• Pàgines públiques preprocessades o estàtiques quan sigui possible
• Tornat a provar a la URL en directe després de publicar

La velocitat i el disseny mòbil van units; consulta com fer una web adaptable a mòbils. Per a una revisió completa abans del llançament, com portar un prototip d'IA a producció cobreix la resta.

Velocitat a Mythex

A Mythex fas aquests canvis demanant-los en el xat, o a l'editor de codi amb Pro. Comprova la URL publicada, no la Vista prèvia, ja que la Vista prèvia executa un servidor de desenvolupament. Els frontends estàtics es despleguen com a llocs estàtics quan publiques (llocs web estàtics), la qual cosa encaixa amb les pàgines de contingut. Les apps amb servidor es redueixen a zero: s'adormen quan estan inactives i es desperten en la següent visita, de manera que la primera sol·licitud després d'un període tranquil és més lenta, i una base de dades adjunta s'adorm després de 5 minuts inactiva (límits d'allotjament). Si una pàgina pública només és lenta en la primera visita, aquesta és la causa probable. Mantenir les pàgines de màrqueting estàtiques ajuda. Després dels canvis, torna a publicar i fes una recàrrega forçada.

Preguntes