Millorar la velocitat d'una botiga en línia sense treure funcions

Quan la velocitat d'una botiga en línia comença a preocupar, la primera proposta sol ser retallar: treure el xat i les ressenyes, simplificar la fitxa de producte i esperar que la nota pugi. De vegades puja, i pel camí la botiga perd coses que ajudaven a vendre. Sovint hi ha marge per carregar les mateixes funcions en un altre moment o només a les pàgines on es fan servir. Aquí repassem com mesurar i en quin ordre atacar el que més pesa.

Com mesurar la velocitat d'una botiga en línia amb dades reals

Google resumeix l'experiència de càrrega a les Core Web Vitals. L'LCP mesura quant triga a pintar-se l'element principal de la pàgina, que en una fitxa sol ser la foto del producte. L'INP mesura quant triga la pàgina a reaccionar quan l'usuari fa alguna cosa, com triar una talla o prémer el botó d'afegir a la cistella; va substituir l'FID com a mètrica de resposta el 2024. El CLS mesura quant es mou el contingut mentre carrega, aquell salt que fa que premis un enllaç que no volies.

Google publica per a cada mètrica uns llindars que classifiquen les pàgines com a bones, millorables o dolentes. Consulta els vigents a la seva documentació abans de fixar objectius.

Dades de camp i dades de laboratori

Les dades de camp surten de visites reals amb Chrome, agregades durant diverses setmanes, i són les que veus a Search Console i a la part superior de PageSpeed Insights quan hi ha prou trànsit. Reflecteixen els mòbils i les connexions dels teus clients.

Les dades de laboratori, com la nota de Lighthouse, venen d'una simulació amb un dispositiu i una xarxa concrets. Serveixen per diagnosticar i comparar abans i després d'un canvi, tot i que la nota varia entre execucions. Fixa els objectius amb les dades de camp i fes servir el laboratori per trobar-ne la causa.

Amb poc trànsit pot ser que no hi hagi dades de camp per URL, i hauràs de basar-te en el laboratori o en una eina que reculli mètriques dels teus propis visitants.

Abans de tocar res, anota:

• Mètriques de camp per tipus de pàgina: portada, categoria, fitxa, cistella i checkout, al mòbil i a l'escriptori.
• Diverses mesures de laboratori de cada tipus de pàgina, per veure'n el rang i no una xifra solta.
• Temps de resposta del servidor en pàgines en memòria cau i sense.
• La llista d'scripts que es carreguen a la fitxa de producte i qui va demanar cadascun.

Imatges: el pes més habitual a fitxes i categories

En una botiga amb un catàleg ampli, les imatges solen ser el primer que apareix al diagnòstic: fotos de diversos milers de píxels mostrades en una miniatura o carrusels de portada que descarreguen totes les diapositives encara que l'usuari només en vegi la primera.

El que sol funcionar sense treure cap imatge:

• Servir cada foto a la mida en què es mostra, amb diverses resolucions perquè el navegador triï.
• Fer servir formats moderns com WebP o AVIF. Shopify i moltes CDN els serveixen segons el navegador; a WooCommerce i PrestaShop depèn del servidor o de l'extensió que facis servir.
• Aplicar càrrega diferida a les imatges que queden per sota de la primera pantalla.
• Deixar sense càrrega diferida la imatge principal de la fitxa i donar-li prioritat alta, perquè sol ser l'element que mesura l'LCP.
• Declarar l'amplada i l'alçada de cada imatge perquè el disseny no salti en carregar.

El quart punt s'oblida molt: activar la càrrega diferida a totes les imatges endarrereix justament la que Google fa servir per mesurar la càrrega.

Scripts de tercers, apps i plugins: el que carrega cadascun

Xat, ressenyes, píxels de publicitat, mapes de calor, finestres emergents o avisos de pagament ajornat: cadascun afegeix JavaScript que el navegador executa al mateix fil que atén els clics de l'usuari, i aquí és on se'n ressent l'INP. El problema sol ser la suma de molts a la fitxa de producte.

Comença per un inventari: quin script és, a quines pàgines cal i qui de l'equip el fa servir. És habitual trobar codi d'apps desinstal·lades fa mesos que continua al tema.

Hi ha diverses maneres de conservar la funció i reduir-ne el cost:

• Carregar cada script només on es fa servir. El giny de ressenyes cal a la fitxa; a la cistella i al checkout sobra.
• Endarrerir la càrrega fins que l'usuari el necessita. Un xat pot mostrar un botó lleuger i carregar el giny complet quan es prem.
• Revisar quines etiquetes de màrqueting poden passar a un gestor d'etiquetes ben configurat o a l'etiquetatge del costat del servidor.
• Substituir una app pesada per una funció a mida quan només se'n fa servir una part petita.

Imagina una fitxa amb un giny de ressenyes que porta la seva pròpia llibreria, les seves fonts i els seus estils per ensenyar cinc estrelles i un comptador. La nota mitjana es pot pintar des del servidor juntament amb la resta de la fitxa, i el llistat complet d'opinions es pot carregar quan l'usuari baixa fins a aquella secció. A Shopify, aquest tipus de canvi se sol resoldre amb funcionalitats a mida que substitueixen la part que fas servir d'una app.

Compte a endarrerir scripts de mesura: si el píxel de conversió es carrega tard, les campanyes poden deixar d'atribuir vendes. Prova aquests canvis amb qui gestiona les campanyes.

Tema i front: CSS, fonts i JavaScript propi

Molts temes comercials inclouen sliders, animacions i seccions que la botiga no fa servir, i carreguen el seu CSS i el seu JavaScript a totes les pàgines. Revisa quines parts es fan servir realment i si la resta es pot deixar de carregar. Canviar de tema sembla la solució ràpida, però si després s'instal·len les mateixes apps, la botiga acaba en un punt semblant.

Amb les fonts passa una cosa semblant: diverses famílies amb molts pesos suposen moltes descàrregues abans que el text es vegi bé. Reduir variants i precarregar la principal se sol notar sense canviar l'aspecte de la botiga.

El JavaScript propi també compta. Un filtre de categoria que recalcula tota la pàgina al navegador a cada clic, o un selector de variants que reconstrueix la fitxa sencera, empitjora l'INP encara que la càrrega inicial sigui ràpida. Si vens productes personalitzables, a la guia sobre el configurador de producte expliquem com evitar que les regles de compatibilitat bloquegin la pàgina.

Servidor, consultes lentes i memòria cau

A Shopify l'allotjament el gestiona la plataforma, així que el marge és sobretot al tema i a les apps. A WooCommerce i PrestaShop el servidor i la base de dades són responsabilitat teva, i un temps de resposta alt endarrereix tota la resta.

Les causes que més veiem són consultes lentes en cerques i filtres per atributs, taules de registres que creixen sense que ningú les netegi, versions antigues de PHP i importacions d'estoc programades en plena hora de trànsit. Activar el registre de consultes lentes durant uns dies sol assenyalar on cal mirar.

La memòria cau té les seves pròpies regles en una botiga:

• La memòria cau de pàgina completa serveix per a la portada, les categories i les fitxes, però no per a la cistella, el checkout ni l'àrea de client.
• Si hi ha preus per client o grup, la memòria cau els ha de distingir per no ensenyar a un particular el preu d'un distribuïdor.
• L'estoc i el preu que mostra una pàgina en memòria cau s'han de refrescar quan canvien, o vendràs amb dades velles.
• Una memòria cau d'objectes en memòria ajuda les pàgines que no es poden desar senceres en memòria cau.

En quin ordre millorar la velocitat d'una botiga en línia

L'ordre importa perquè alguns canvis amaguen l'efecte d'altres. Una seqüència que sol funcionar:

• Si el temps de resposta del servidor és alt, comença per aquí. Amb un servidor lent, optimitzar el front es nota poc.
• Després, imatges sobredimensionades i scripts orfes d'apps que ja no hi són. Són canvis de poc risc que afecten moltes pàgines.
• Llavors, scripts de tercers per tipus de pàgina, començant per la fitxa i la categoria, que és on més es navega.
• Al final, el tema i el JavaScript propi, que és el que més hores costa i més proves necessita.

Fes un canvi cada vegada i mesura abans i després al laboratori. Les dades de camp triguen setmanes a reflectir una millora, així que apunta la data de cada canvi. Després de cada desplegament, prova una comanda completa en un mòbil de gamma mitjana, que s'assembla més al dels teus clients que el portàtil de l'equip.

Què preparar abans de demanar una optimització

Amb això al davant, la valoració parteix de la teva botiga real:

• Accés a Search Console i a l'analítica.
• Llista d'apps, plugins o mòduls actius i qui fa servir cadascun.
• Les pàgines que més venen i les que reben trànsit de pagament.
• Les funcions que no es poden tocar, com el configurador, les ressenyes o el pagament ajornat.
• Un entorn de proves o la possibilitat de crear una còpia de la botiga.
• Si fas servir WooCommerce o PrestaShop, dades de l'allotjament i accés als registres del servidor.

Si vols que revisem el teu cas, a optimització ecommerce expliquem com treballem la càrrega sense treure funcions. Si a més sospites que la lentitud és només un de diversos problemes, una auditoria tècnica ecommerce ho ordena tot per prioritat abans de tocar codi.