WooCommerce lent: causes típiques i en quin ordre solucionar-les

Un WooCommerce lent poques vegades té una sola causa. El normal és una suma: un allotjament just, una taula d'opcions que ha anat creixent durant anys, una dotzena de plugins que es carreguen a totes les pàgines i alguna tasca programada que coincideix amb les hores de més trànsit. Repassem les causes que més trobem quan revisem botigues WooCommerce, com mesurar-ne cadascuna sense endevinar i en quin ordre convé actuar perquè cada canvi es noti.

Per què un WooCommerce lent es nota més a la cistella i al checkout

WordPress genera cada pàgina amb PHP i amb consultes a MySQL o MariaDB. A la portada, les categories i les fitxes, una memòria cau de pàgina completa amaga bona part d'aquesta feina: el servidor desa l'HTML ja muntat i l'entrega sense recalcular-lo. La cistella, el checkout i el compte del client no es poden desar així, perquè cada visitant veu el seu propi contingut. En aquestes pàgines la botiga treballa sense xarxa i surten a la llum els problemes del servidor i de la base de dades.

Per això hi ha botigues que semblen ràpides mentre navegues pel catàleg i s'arrosseguen just quan vas a pagar. Amb l'administrador passa una cosa semblant. Si editar una comanda o desar un producte triga diversos segons, l'origen sol ser al servidor, a la base de dades o en algun plugin, i la memòria cau de pàgina no ho taparà.

Com mesurar la lentitud abans de tocar res

El primer és separar dos temps: el que triga el servidor a respondre i el que triga el navegador a pintar la pàgina. Si el primer és alt, optimitzar imatges o scripts donarà poc resultat. Si és baix i la pàgina continua lenta, cal mirar el front. Amb aquesta separació feta, la feina va de baix a dalt:

Per mesurar amb dades:

• Temps de resposta del servidor en una fitxa servida des de la memòria cau i a la cistella amb un producte a dins, diverses vegades i a hores diferents.
• Un plugin de diagnòstic com Query Monitor, instal·lat en una còpia de la botiga, per veure quantes consultes llança cada pàgina, quines triguen més i quin plugin les origina.
• El registre de consultes lentes de MySQL activat durant uns quants dies, si el teu allotjament ho permet.
• Els registres d'errors de PHP. Un avís que es repeteix milers de vegades al dia també consumeix temps.
• Les accions programades pendents o fallides, que WooCommerce mostra a la seva pantalla d'estat.

Apunta les xifres de partida per poder comparar després de cada canvi, i fes els canvis d'un en un.

Servidor i allotjament: PHP, memòria i memòria cau d'objectes

A WooCommerce el servidor és cosa teva o del teu proveïdor d'allotjament, i un pla compartit pensat per a un web corporatiu es queda curt tan bon punt la botiga rep comandes cada dia. Revisa aquests punts:

• La versió de PHP. Les antigues solen rendir pitjor i deixen de rebre pedaços de seguretat. Abans de pujar de versió, prova els plugins en una còpia.
• El límit de memòria de PHP i quants processos poden atendre peticions alhora. Quan s'esgoten, les peticions fan cua i en campanya sembla que la botiga ha caigut.
• Si hi ha memòria cau d'objectes persistent, com Redis o Memcached. WordPress hi desa resultats que es repeteixen i alleuja les pàgines que no es poden desar senceres a la memòria cau.
• Que la memòria cau de pàgina exclogui la cistella, el checkout i el compte, i respecti les galetes de sessió de WooCommerce.

Canviar d'allotjament té sentit quan, amb la base de dades i els plugins ja revisats, el servidor continua trigant a respondre. Fer-ho abans sol portar el mateix problema a una màquina més cara.

Base de dades: wp_options, autoload i taules que creixen

La taula wp_options desa la configuració de WordPress i de cada plugin. Les opcions marcades per carregar-se automàticament (el famós autoload) es llegeixen a cada petició, tant si la pàgina les necessita com si no. Amb els anys s'hi acumulen restes de plugins desinstal·lats, configuracions enormes desades en una sola fila i dades temporals que ningú no neteja. Si aquest bloc pesa diversos megues, totes les pàgines l'arrosseguen.

Segons la versió, la pantalla Salut del lloc de WordPress avisa quan les opcions que es carreguen automàticament ocupen massa. Per veure-ho amb detall cal una consulta a la base de dades que sumi la mida d'aquestes files i llisti les més grans. Abans d'esborrar-ne o desmarcar-ne cap, esbrina quin plugin la va crear, perquè treure la que no toca pot deixar un plugin actiu sense la seva configuració.

Hi ha altres taules que creixen sense que ningú les miri:

• Els transitoris, dades temporals que també viuen a wp_options. Els caducats haurien de desaparèixer sols, tot i que no sempre passa.
• Les taules d'Action Scheduler, on WooCommerce i molts plugins apunten les seves tasques en segon pla. Milers d'accions fallides indiquen que alguna cosa es repeteix sense èxit.
• Les sessions de WooCommerce dels visitants que han afegit alguna cosa a la cistella.
• Els registres de plugins de correu, seguretat o estadístiques que desen cada esdeveniment a la base de dades.

Les comandes també pesen. Amb l'emmagatzematge clàssic, cada comanda és una entrada més de WordPress amb desenes de metadades, i cercar a l'administrador es torna lent quan l'històric és gran. L'emmagatzematge de comandes d'alt rendiment les passa a taules pròpies. A la guia sobre HPOS a WooCommerce expliquem com fer aquest canvi sense trencar plugins.

Plugins i consultes pesades

Importa menys el nombre de plugins que el que fa cadascun i a quines pàgines. Un que només treballa a l'administrador gairebé no afecta el visitant. Un altre que llança consultes pesades a cada fitxa, o que crida un servei extern abans de pintar la pàgina, sí que es nota.

La manera més fiable de trobar el culpable és una còpia de la botiga: desactives plugins un per un, o per grups, i mesures el temps de resposta de les mateixes pàgines cada vegada. Query Monitor escurça la llista perquè agrupa les consultes pel component que les llança.

Aquests patrons apareixen sovint:

• Filtres de catàleg que cerquen per atributs o metadades sense índexs adequats. En catàlegs grans, algunes combinacions de filtres triguen segons.
• Cercadors que recorren la taula de metadades de productes comparant text.
• Plugins que consulten una API externa d'enviaments, divises o estoc cada vegada que es carrega una pàgina, en lloc de desar la resposta una estona.
• WP-Cron disparat per les visites. En una botiga amb trànsit sol anar millor desactivar aquest disparador i llançar les tasques des del servidor cada pocs minuts.
• Importacions d'estoc o de preus programades en hora punta.

De vegades un plugin fa molt més del que la botiga fa servir, i una peça petita escrita per al teu cas pesa menys. A plugin comprat o codi a mida a WooCommerce expliquem quan compensa cada opció.

Imatges, scripts i fragments de la cistella

Amb el servidor responent ràpid, queda el que passa al navegador. Les fotos de producte pujades a diversos milers de píxels, sense mides intermèdies ni formats moderns, continuen sent el més habitual. Regenerar les miniatures a la mida que fa servir el tema i servir-les en WebP, des del servidor o amb una extensió, se sol notar a categories i fitxes.

Els fragments de la cistella mereixen un apartat propi. WooCommerce fa servir una petició AJAX per actualitzar el resum de la cistella de la capçalera sense dependre de la memòria cau de la pàgina. Des de la versió 7.8 aquest script ja no es carrega per defecte a totes les pàgines, només on apareix el giny de la cistella. Tot i això, alguns temes porten el giny fix a la capçalera i alguns plugins declaren l'script com a dependència, i llavors cada visita llança una petició que no es pot desar a la memòria cau. Si veus aquesta petició a totes les pàgines des de les eines de desenvolupament del navegador, esbrina qui la carrega.

Després hi ha els scripts de tercers: xat, ressenyes, píxels de publicitat i finestres emergents. A la guia sobre la velocitat d'una botiga en línia entrem amb més detall en Core Web Vitals, imatges i scripts, per a qualsevol plataforma.

Què has de preparar abans de demanar una revisió de rendiment

Perquè la revisió comenci per les causes i no per suposicions, tingues a mà el següent:

• Accés d'administrador a WordPress i al tauler de l'allotjament, o el contacte de qui el gestiona.
• Versions de WordPress, WooCommerce i PHP, i la llista de plugins actius amb qui fa servir cadascun.
• Quines pàgines van lentes i quan: sempre, només en campanya o només a l'administrador.
• Si ja hi ha una còpia de la botiga o se'n pot crear una per provar.
• Tasques programades que coneguis, com importacions, sincronitzacions amb l'ERP o còpies de seguretat.
• Canvis recents, si la lentitud va començar de cop: un plugin nou, una actualització o un canvi de tema.

Si vols que ho mirem, a manteniment WooCommerce expliquem com treballem: mesurem, provem cada canvi en una còpia i el passem a producció quan la millora està comprovada.