El teu WordPress marca 35 a PageSpeed: què està passant
Obres PageSpeed Insights, introdueixes l’URL del teu web WordPress i el resultat és un 35 en mòbil. El LCP marca 4,8 segons, el CLS puja a 0,32 i l’INP registra 340 mil·lisegons. Coneixes les mètriques perquè portes mesos veient articles sobre Core Web Vitals a cada butlletí de màrqueting digital. El que no saps és per què el teu WordPress, amb un tema premium i diversos plugins d’optimització instal·lats, segueix suspenent.
El problema no és WordPress en si. WordPress alimenta el 43% del web global, i segons dades d’HTTPArchive de 2025, aproximadament un terç d’aquests llocs aprova els tres Core Web Vitals simultàniament. La diferència entre els que aproven i els que no rares vegades és una sola causa. És una acumulació de decisions tècniques: el tema escollit, els plugins actius, la configuració de memòria cau, el tractament d’imatges, la qualitat de l’allotjament i la quantitat de JavaScript de tercers carregat a cada pàgina.
Aquesta guia no va d’instal·lar un plugin màgic. Va d’entendre quins components del teu stack WordPress estan penalitzant cada mètrica i com intervenir a cada capa amb precisió quirúrgica. L’objectiu és passar d’aquest 35 a verd en les tres mètriques, i mantenir-ho així quan afegeixis contingut nou.
Per què WordPress té problemes freqüents amb els Core Web Vitals
WordPress no va néixer com un framework de rendiment. Va néixer com un sistema de publicació de blogs el 2003 i ha evolucionat mitjançant un ecosistema de plugins i temes que prioritza la funcionalitat per sobre de l’eficiència. Aquesta arquitectura extensible és la seva major fortalesa comercial i la seva major debilitat tècnica.
Un lloc WordPress típic d’empresa mitjana carrega entre 15 i 40 plugins actius. Cada plugin pot injectar els seus propis fitxers CSS i JavaScript a totes les pàgines del lloc, fins i tot a aquelles on no s’utilitza. Un plugin de formularis de contacte carrega el seu CSS a la pàgina d’inici. Un plugin de sliders carrega el seu JavaScript a la pàgina de serveis on no hi ha cap slider. Un plugin d’analítica afegeix un script de 45 KB que bloqueja el renderitzat. Segons el WordPress Performance Team, el lloc WordPress mitjà carrega 3,2 MB de recursos a la primera visita, quan el pressupost recomanat per a un LCP inferior a 2,5 segons és d’1,5 MB o menys.
El segon factor estructural és el tema. Els temes multipropòsit com Avada, Divi o BeTheme inclouen desenes de mòduls precarregats, fulls d’estil per a components que el lloc mai utilitza, i frameworks JavaScript complets incrustats. Un tema multipropòsit típic genera un DOM de 2.000 a 4.000 nodes a la pàgina d’inici, quan Google recomana un màxim de 1.500 nodes per a un rendiment òptim. El WordPress Performance Team ha documentat que els temes natius de blocs (Twenty Twenty-Four, Twenty Twenty-Five) generen entre 400 i 800 nodes per a un disseny equivalent.
El tercer factor és l’allotjament. La majoria de llocs WordPress empresarials comencen en allotjament compartit on un sol servidor físic atén centenars de llocs simultàniament. El resultat és un TTFB (Time to First Byte) de 400 a 800 mil·lisegons, que consumeix entre el 16% i el 32% del pressupost total de LCP abans que el navegador hagi rebut ni tan sols el primer byte d’HTML. Cap plugin de memòria cau pot compensar un servidor que triga mig segon a respondre.
Plugins de memòria cau: WP Rocket, LiteSpeed Cache, W3 Total Cache
La memòria cau de pàgina és l’optimització amb major retorn immediat a WordPress. Sense memòria cau, cada visita executa PHP, consulta la base de dades MySQL i genera l’HTML des de zero. Amb memòria cau, el servidor serveix un fitxer HTML estàtic pregenerat, eliminant completament el processament dinàmic per a visitants no autenticats.
El WP Rocket és el plugin de memòria cau més complet per als Core Web Vitals. El seu avantatge no és només la memòria cau de pàgina —que qualsevol plugin ofereix— sinó les optimitzacions complementàries integrades: eliminació de CSS no utilitzat (Remove Unused CSS), càrrega diferida de JavaScript (Delay JavaScript Execution), preload d’enllaços quan l’usuari fa hover, optimització de la base de dades i generació automàtica de CSS crític inline. Segons la documentació oficial de WP Rocket, aquestes optimitzacions combinades redueixen el TTFB entre un 40% i un 60% en configuracions típiques. El cost és de 59 dòlars anuals per a un lloc, una inversió que es recupera en dies si el lloc genera negoci.
El LiteSpeed Cache és la millor alternativa gratuïta, especialment potent en servidors que executen LiteSpeed Web Server (on aprofita la memòria cau a nivell de servidor, no només a nivell d’aplicació). Inclou optimització d’imatges integrada a través del servei QUIC.cloud, CDN propi i funcionalitats d’optimització de CSS/JS comparables a WP Rocket. La seva principal limitació és que en servidors Apache o Nginx perd l’avantatge de la memòria cau a nivell de servidor i funciona com un plugin de memòria cau convencional.
El W3 Total Cache ofereix el major control granular: permet configurar la memòria cau de pàgina, d’objectes, de base de dades i de navegador de forma independent. La seva complexitat és la seva fortalesa i la seva debilitat: una configuració incorrecta pot empitjorar el rendiment o causar conflictes amb altres plugins. És l’opció recomanada per a equips tècnics que necessiten control total sobre cada capa de memòria cau.
La configuració crítica que molts obliden: la memòria cau s’ha de purgar automàticament quan es publica o actualitza contingut, i les pàgines de cistella, checkout i àrea de client s’han d’excloure de la memòria cau per evitar servir contingut d’un altre usuari. WP Rocket i LiteSpeed Cache gestionen aquestes exclusions automàticament; a W3 Total Cache requereixen configuració manual.
Optimització d’imatges: ShortPixel, Imagify i conversió WebP
Les imatges són la causa número u d’un LCP deficient a WordPress. L’element LCP a la majoria de pàgines és una imatge hero, una imatge de producte o una imatge destacada del post. Si aquella imatge pesa 800 KB en lloc de 200 KB, el LCP es retarda proporcionalment.
L’estratègia d’optimització d’imatges té tres capes: compressió, format modern i dimensionament correcte.
Per a la compressió, ShortPixel i Imagify són els dos plugins líders. Tots dos processen les imatges en pujar-les a la biblioteca de mitjans i ofereixen tres nivells: lossy (màxima reducció, pèrdua de qualitat imperceptible en la majoria de casos), glossy (equilibri entre mida i qualitat) i lossless (sense pèrdua de qualitat, menor reducció). ShortPixel ofereix un pla gratuït de 100 crèdits mensuals i plans de pagament des de 3,99 dòlars al mes. Imagify està integrat amb WP Rocket i ofereix 20 MB gratuïts al mes.
El format WebP redueix el pes de les imatges un 25-35% addicional respecte a JPEG optimitzat, segons les dades publicades per Google. Tant ShortPixel com Imagify generen automàticament versions WebP de cada imatge i les serveixen a navegadors compatibles (que ja són el 97% del trànsit global). La configuració requereix assegurar-se que el servidor serveix les versions WebP mitjançant regles de reescriptura a .htaccess o configuració del plugin.
El dimensionament correcte és la tercera capa. WordPress genera múltiples mides de cada imatge pujada (thumbnail, medium, large, full). L’error més comú és carregar la imatge en mida full (2.400 px d’amplada) en un contenidor que només ocupa 800 px. La solució és l’atribut srcset —que WordPress genera automàticament des de la versió 4.4— i verificar que el tema no està forçant mides d’imatge incorrectes. Els page builders com Elementor de vegades ignoren les mides registrades i carreguen sempre la imatge original.
Una consideració tècnica freqüentment ignorada: les imatges above-the-fold (la imatge hero, el logotip, la primera imatge de producte) no han de tenir lazy loading activat. L’atribut loading="lazy" a la imatge LCP retarda la seva càrrega perquè el navegador espera fins que el viewport s’acosta a l’element. WordPress afegeix loading="lazy" automàticament a totes les imatges des de la versió 5.5, però des de la 5.9 exclou automàticament la primera imatge del contingut. Verifica que el teu tema no està sobreescrivint aquest comportament.
Minimització de CSS i JavaScript: Autoptimize i alternatives
El CSS i JavaScript no optimitzat és el segon factor més comú en LCP deficients a WordPress. Un lloc WordPress típic carrega entre 8 i 20 fitxers CSS i entre 10 i 30 fitxers JavaScript, molts d’ells render-blocking.
La tècnica més efectiva per millorar el LCP és el CSS crític inline: extreure el CSS necessari per renderitzar el contingut above-the-fold i injectar-lo directament al <head> de l’HTML, carregant la resta del CSS de forma asíncrona. WP Rocket genera CSS crític automàticament. Si no fas servir WP Rocket, Autoptimize combinat amb l’addon de CSS crític de CriticalCSS.com ofereix una funcionalitat equivalent.
Segons dades de l’equip de rendiment de WordPress, el lloc WordPress mitjà carrega un 60-70% de CSS no utilitzat a la pàgina actual. WP Rocket inclou la funció Remove Unused CSS que analitza cada pàgina i serveix només el CSS necessari. El plugin gratuït Asset CleanUp permet desactivar selectivament CSS i JS de plugins específics a pàgines on no es necessiten.
La minimització redueix la mida dels fitxers JS eliminant espais, comentaris i noms de variables llargs. La combinació de JavaScript redueix el nombre de peticions HTTP agrupant diversos fitxers en un. Autoptimize fa ambdues coses de forma gratuïta. No obstant, la combinació pot causar conflictes si l’ordre de càrrega dels scripts importa (i a WordPress, gairebé sempre importa). La recomanació actual és minimitzar sempre però combinar amb precaució, provant exhaustivament després d’activar la combinació.
El major impacte en l’INP prové de JavaScript de tercers que s’executa al fil principal durant la càrrega: scripts d’analítica, píxels de remarketing, widgets de xat, pop-ups de galetes. WP Rocket permet retardar l’execució de JavaScript fins a la primera interacció de l’usuari (Delay JavaScript Execution), eliminant completament l’impacte d’aquests scripts en el LCP i reduint significativament l’INP. Flying Scripts és l’alternativa gratuïta més eficaç per a aquesta funció específica.
Temes WordPress optimitzats per als Core Web Vitals
El tema és la base de tot el frontend de WordPress. Un tema mal codificat imposa un sostre de rendiment que cap plugin pot superar. Els temes que consistentment produeixen els millors resultats en Core Web Vitals comparteixen tres característiques: generen un DOM reduït (menys de 1.000 nodes a la pàgina d’inici), carreguen el mínim CSS i JS necessari, i no depenen de frameworks JavaScript pesants.
El GeneratePress és el tema que més consistentment produeix bons Core Web Vitals en auditories independents. La seva versió gratuïta genera menys de 10 KB de CSS i zero JavaScript al frontend. La versió premium (GeneratePress Premium, 59 dòlars amb actualitzacions de per vida) afegeix mòduls de disseny que es carreguen només quan s’activen. El DOM típic d’una pàgina GeneratePress té entre 300 i 600 nodes.
El Kadence ofereix una experiència visual més rica que GeneratePress sense sacrificar significativament el rendiment. El seu header builder i footer builder generen codi net, i el tema carrega JavaScript només quan s’utilitzen components interactius (menú mòbil, acordions). El DOM típic oscil·la entre 500 i 900 nodes, raonable per a un tema amb més opcions de disseny.
Els temes basats en blocs natius (Twenty Twenty-Four, Twenty Twenty-Five) són l’aposta oficial del WordPress Performance Team. En no dependre del Customizer clàssic ni de frameworks d’opcions de tercers, eliminen una capa completa d’abstracció. El seu rendiment és excel·lent en mètriques tècniques, però la seva flexibilitat de disseny és limitada sense l’editor de lloc complet (Full Site Editing), que encara té una corba d’aprenentatge pronunciada.
La realitat per a molts llocs: migrar de tema és un projecte significatiu. Si el pressupost o el calendari no ho permeten, les optimitzacions a les altres capes (memòria cau, imatges, JavaScript) poden millorar substancialment els Core Web Vitals fins i tot amb un tema subòptim. Però si després d’optimitzar tota la resta el LCP segueix per sobre de 3 segons i el DOM supera els 2.000 nodes, el tema és el coll d’ampolla i s’ha d’abordar.
Allotjament i TTFB: el factor que molts ignoren
El TTFB (Time to First Byte) és el temps que triga el servidor a enviar el primer byte de resposta al navegador. És el punt de partida absolut de la cascada de càrrega: res es renderitza fins que el navegador rep aquell primer byte. Google recomana un TTFB inferior a 200 mil·lisegons per contribuir a un LCP saludable.
L’impacte de l’allotjament en els Core Web Vitals està ben documentat. Les dades de CrUX mostren una correlació directa entre TTFB i LCP: llocs amb TTFB inferior a 200 ms tenen un 73% de probabilitats d’aprovar el llindar de LCP de 2,5 segons, mentre que llocs amb TTFB superior a 600 ms només l’aproven en un 18% dels casos.
L’allotjament compartit (Hostinger pla bàsic, SiteGround StartUp, GoDaddy Economy) té un TTFB típic de 400-800 ms. Un sol servidor físic atén centenars de llocs, i els pics de trànsit de qualsevol d’ells poden afectar la resta. Per a un blog personal és acceptable; per a un lloc empresarial que depèn del trànsit orgànic, és un coll d’ampolla estructural.
Un VPS gestionat (Cloudways amb DigitalOcean o Vultr) ofereix un TTFB típic de 150-300 ms. El lloc té recursos dedicats (CPU, RAM) i el proveïdor gestiona les actualitzacions del servidor. La relació cost-rendiment és excel·lent: des de 14 dòlars mensuals per un servidor amb 2 GB de RAM suficient per a llocs amb fins a 50.000 visites mensuals.
L’allotjament WordPress gestionat (Kinsta, WP Engine, Rocket.net) té un TTFB típic de 100-200 ms. Inclou CDN integrat, memòria cau a nivell de servidor (en molts casos no necessiten plugin de memòria cau), entorns de staging i suport especialitzat en WordPress. El cost és superior (des de 30-35 dòlars mensuals) però la infraestructura està optimitzada específicament per a WordPress.
Independentment de l’allotjament, un CDN redueix el TTFB per a usuaris geogràficament distants del servidor. Cloudflare (pla gratuït disponible) serveix el contingut en memòria cau des del punt de presència més proper a l’usuari. Per a un lloc amb audiència a Catalunya, un servidor a Europa combinat amb Cloudflare garanteix un TTFB consistent inferior a 200 ms per a la majoria de visitants.
Un mesurament que has de fer avui: obre Google Search Console, ves a Experiència > Core Web Vitals i mira les dades de camp del teu lloc. Si el TTFB (visible a PageSpeed Insights, secció Diagnòstic) supera els 400 ms, la primera optimització hauria de ser l’allotjament, no els plugins. Consulta la nostra guia sobre velocitat web per a una anàlisi completa de tots els factors que influeixen en la velocitat de càrrega més enllà de WordPress.
Checklist final: Core Web Vitals en verd a WordPress
L’optimització de Core Web Vitals a WordPress segueix un ordre de prioritat basat en l’impacte de cada acció. Implementar aquestes accions en seqüència, mesurant després de cada pas, permet identificar exactament quin canvi va produir cada millora.
Setmana 1 — Infraestructura base
- Verificar el TTFB actual a PageSpeed Insights. Si supera 400 ms, avaluar migració d’allotjament.
- Instal·lar i configurar un plugin de memòria cau (WP Rocket recomanat, LiteSpeed Cache com alternativa gratuïta).
- Activar compressió Gzip/Brotli a nivell de servidor o mitjançant plugin.
- Configurar un CDN (Cloudflare pla gratuït com a mínim).
Setmana 2 — Imatges
- Instal·lar ShortPixel o Imagify i processar per lots totes les imatges existents.
- Activar conversió automàtica a WebP.
- Verificar que les imatges above-the-fold no tenen
loading="lazy". - Revisar que el tema serveix imatges amb
srcseti mides apropiades.
Setmana 3 — CSS i JavaScript
- Activar Remove Unused CSS a WP Rocket o instal·lar Asset CleanUp per desactivar CSS/JS de plugins no utilitzats a cada pàgina.
- Activar Delay JavaScript Execution per a scripts de tercers.
- Generar CSS crític inline.
- Verificar que no hi ha fitxers CSS o JS render-blocking al
<head>que puguin diferir-se.
Setmana 4 — Tema i DOM
- Auditar el DOM de la pàgina d’inici amb Chrome DevTools (Elements > Ctrl+F > cercar total de nodes).
- Si supera 1.500 nodes, identificar els components del tema que generen més nodes.
- Desactivar widgets i mòduls del tema que no s’utilitzin.
- Si el tema és un page builder, avaluar el cost-benefici de migrar davant optimitzar la configuració existent.
Validació contínua
- Monitoritzar les dades de camp a Google Search Console cada setmana durant els 28 dies següents.
- Les dades CrUX s’actualitzen cada 28 dies, així que els canvis triguen aproximadament un mes a reflectir-se a les mètriques oficials de Google.
- Repetir l’auditoria de PageSpeed Insights després de cada canvi significatiu (nou plugin, actualització de tema, contingut pesat nou).
L’objectiu no és una puntuació perfecta de 100 a Lighthouse —és un nombre sintètic que no reflecteix l’experiència real—. L’objectiu és que els tres Core Web Vitals estiguin en verd a les dades de camp de Google Search Console: LCP inferior a 2,5 segons, CLS inferior a 0,1 i INP inferior a 200 mil·lisegons per al percentil 75 dels teus usuaris reals.