Auditoria WPO professional + cas pràctic

En aquest post t’oferim tot el necessari per realitzar una auditoria WPO professional: fonaments, eines i trucs que t’ajudaran.

1. Què és el WPO?

WPO respon a les sigles Web Performance Optimization. En castellà seria alguna cosa així com Optimització del Rendiment Web. Es tracta del conjunt d’accions que podem realitzar a nivell de web i servidor per fer que la nostra web carregui el més ràpid possible, especialment en dispositius mòbils.

2. Per què és important el WPO?

Els motius són múltiples, però ens centrarem en els més importants:

• Estalvi: una web optimitzada consumeix menys recursos, i això ens permetrà reduir costos d’allotjament web (hosting) i el seu corresponent impacte en el medi ambient.
• SEO: les Core Web Vitals de Google són un dels senyals que els algoritmes tenen en compte a efectes de posicionament.
• Millor experiència d’usuari: un mal rendiment web suposa una mala experiència per als nostres usuaris, especialment en dispositius mòbils amb connexions lentes. En conseqüència, un bon WPO tindrà impacte directe en aspectes clau com la taxa de rebot, les pàgines vistes, el temps de permanència a la pàgina i, el més important, en les CONVERSIONS.

3. Què ha d’incloure una auditoria de WPO

3.1. Anàlisi de situació inicial

Mitjançant eines externes i amb el propi navegador, hem de fer una foto del rendiment actual. És important fer-ho amb metodologies i configuracions diferents, i passar l’auditoria no només a la home, sinó a conjunts d’URLs que tinguin patrons (per exemple post de blog, fitxa de servei, pàgina de categoria o marca, etc.).

3.2. Pedagogia i documentació

És un tema extremadament tècnic, però recomanem incloure un apartat de documentació que permeti justificar la importància de les nostres accions i fer aquesta pedagogia amb el client. És crucial fer una bona selecció de fonts, amb la màxima autoritat possible (en essència la de Google és sempre la més fiable, perquè determinades informacions que emetin parts interessades poden estar esbiaixades).

3.3. Recomanacions i prioritzacions

En aquest apartat s’han de llistar les possibles accions a implementar. Però hem d’anar més enllà. Un cop obtinguem el listing l’hem de filtrar i ponderar sota dos principis: prioritzar allò que tingui un impacte més gran en el rendiment, amb una inversió mínima de recursos.

Fins aquí seria l’apartat estricte que correspondria a una auditoria WPO: hem fet una foto, hem documentat les necessitats i hem emès una sèrie de recomanacions. Però normalment el client ens demanarà anar més enllà, bé implementant les millores, bé monitorant a posteriori les implementacions que hagi pogut fer un equip extern. En aquest cas prosseguiríem amb:

3.4. Testejar la web

No seria la primera vegada que després d’una optimització WPO obtenim una web que va ràpida, però que no va. L’objectiu no és passar un Speed Test, és carregar la web més ràpid sense perdre funcionalitats. En aquest apartat s’ha de realitzar un QA de web molt exhaustiu, com si acabéssim de publicar la pàgina web. Testejar la web amb diferents dispositius i navegadors, interactuar amb menús i botons, enviar formularis, processar comandes de compra en e-commerce, etc.

Si hi ha recursos disponibles, recomanem no implementar les millores WPO directament a la web que està online, en producció. L’escenari ideal és treballar en un clon de la web en un entorn de servidor igual al que tenim, fer-hi les proves i, quan tot estigui bé, passar a producció. Tot i que això, malauradament, no sempre serà viable.

3.5. Comparativa amb la situació inicial

Un cop implementada la bateria d’accions, hem de recuperar el que vam guardar al punt 3.1 d’anàlisi de situació inicial. I amb les mateixes eines i configuracions, mesurarem les millores que hem obtingut a les mètriques principals. És important triar-les bé i no marejar el client amb un excés de dades: 4-5 mètriques en 2-3 eines haurien de ser suficients.

3.6. Seguiment de l’experiència d’usuari (GSC, Locker…)

Les eines al final ens donen simulacions de rendiment web en supòsits determinats, des de tal lloc, tal dispositiu i navegador. Però aquests no són els usuaris reals de la nostra web, que són el destinatari final. Per això és important analitzar l’experiència real dels nostres usuaris a través d’eines com Google Search Console, que ens emet un informe magnífic. També mitjançant Locker Studio podem configurar un informe que mes a mes ens avalua si complim les Core Web Vitals, una meravella (vegeu l’informe CruX).

3.7. Recomanacions de futur

La bateria d’accions fruit de l’auditoria és molt important, però un cop tancada hem d’emetre recomanacions perquè quan el client faci canvis a nivell de continguts no ho llenci tot per terra. Hem de protocol·litzar especialment com serà la pujada de fotos i vídeos en el futur, ja que són els elements més sensibles a nivell de càrrega.

4. Eines per a la teva auditoria de WPO

És difícil fer una selecció, ja que hi ha multitud d’eines i totes tenen alguna característica interessant. Et posem aquí les que més fem servir a la majoria de projectes; compte, no és necessari utilitzar-les totes en un projecte, ni de bon tros.

4.1. Lighthouse amb Chrome (f12)

És gratuït, el més fiable, i el tens al teu PC. Només has d’obrir el navegador Chrome (preferiblement en mode d’incògnit i sense extensions), prémer F12, i allà el trobaràs. Allà veuràs el rendiment amb el teu propi cas, o pots canviar la configuració per simular les que fan servir les eines externes o el mateix Google.

4.2. Page Speed

El Page Speed és la referència de Google i molt probablement el que consultarà el client, així que encara que no t’apassioni haurà de ser la teva referència. Ningú vol que li surti en vermell i, per molt que li expliquis que no és el més rellevant, no colarà. Com a mínim en taronja. De totes maneres, el que més ens interessa realment és complir amb els nostres usuaris reals:

4.3. GTMetrix

Eina molt completa, per a molts més útil i fiable que la de Google. GTMetrix, a més de donar-nos una puntuació i colors, ens dona informació interessant sobre el Waterfall i alguns consells que faries bé de seguir.

4.4. Web Page Test

Aquesta és una alternativa interessant a les eines anteriors. Web Page Test, a més d’un speed test general configurable amb diversos països, connexions i dispositius, ofereix un informe interessant de Core Web Vitals i un altre al qual hi veiem molt futur per controlar l’emissió de carboni del nostre lloc.

4.5. Dot Com Tools

Aquest analitzador de WPO és especialment interessant per a projectes internacionals. El Dot Com Tools et dona una auditoria de rendiment de forma simultània des de diferents punts del planeta, i és el principal aliat de la contractació d’un CDN com cal.

4.6. Built With

Aquesta i altres eines ens poden ser útils per conèixer les entranyes de la web. Built With ens dona informació sobre el CMS utilitzat, el servidor que allotja el lloc web, els components de front i back que tenim, etc. Ens permet fer-nos una idea de l’ecosistema intern i el marge de millores que podrem aplicar.

4.7. Wappalizer

Compleix pràcticament les mateixes funcionalitats que l’eina anterior, però en aquest cas com a extensió de Chrome.

4.8. Request Map

Aquesta eina és útil per veure de manera gràfica com es fan les peticions externes, cosa que sempre és un mal de cap important. Provar Request Map

5. Les tripes de l’auditoria WPO

L’auditoria WPO té dos universos d’anàlisi: d’una banda, l’entorn de servidor, i de l’altra, el de la pròpia web. Et recomanem començar pels servidors, però no és imprescindible.

5.1 Auditoria de servidor

A nivell de servidor hem d’analitzar:

• Protocol https + versió de TLS
• Tipus de servidor
• Versió de PHP
• Protocol http (1.1, 2 o 3)
• Bases de dades (MariaDB, MySQL)
• Emmagatzematge (SSD)
• TTFB (no sempre és 100% per server)
  
  

Protocol https + versió de TLS

Mitjançant Chrome Dev, podem obtenir una sèrie d’informació bàsica sobre seguretat:

Aquí hem de comprovar:

1. Que tinguem un certificat SSL, que aquest sigui vàlid i de confiança, i que no estigui caducat.
2. Connexió (TLS, QUIC). A priori millor el segon per a projectes complexos. En l’exemple que veieu fem servir TLS1.2, així que una millora a proposar seria passar a TLS 1.3, ja que moure a QUIC seria una quimera. Coneix més sobre les diferències entre TLS 1.2 i 1.3.
3. Assegurar-nos que els recursos es carreguen de manera segura.

Tipus de servidor

Hi ha molts tipus de servidors, tot i que els més comuns són Apache, Nginx i LiteSpeed.

Podem comprovar el nostre amb l’extensió Wappalyzer, per exemple:


En el nostre cas d’exemple és un Apache. De vegades no es veu amb Wappalyzer; una alternativa seria l’extensió de Chrome Web Developer.

Versió de PHP

Ens interessa també conèixer la versió de PHP que estem fent servir. És una cosa que normalment és impossible de saber si no tenim accés al hosting i al codi, encara que de vegades és visible des de la resposta de capçalera a l’eina d’inspecció i a les URLs de GSC. En el nostre cas no és així, de manera que ho hem consultat amb el nostre proveïdor de hosting.

Com més moderna sigui la versió de PHP, millor. Especialment si podem passar a les versions 8, ja que totes les peticions es processen molt més ràpid (vegeu la comparativa de versions de PHP). Tot i això, has de tenir en compte que no es pot pujar la versió de PHP a la brava, perquè pot ser incompatible amb el codi de la web, i quedar-te sense pàgina en uns segons. De manera que primer t’has d’assegurar que el codi ja és apte o s’ha adaptat a aquest canvi, i tingues en compte que alguns projectes, per la seva edat o com estan construïts, no suportaran una pujada important de PHP sense rebentar.

Protocol HTTP

Hi ha diversos protocols i aquests influeixen molt en la capacitat de processar paquets de dades de forma simultània (vegeu la comparativa Protocol HTTP1 VS 2 VS 3). Com més avançada sigui la connexió, més paquets de dades es podran processar en paral·lel.

Amb això en ment, vegem quina connexió fa servir la nostra web. Per fer-ho podem utilitzar Chrome => eina de desenvolupadors => xarxa => botó dret => protocol

En el cas que ens ocupa, observem com es lliura contingut majoritàriament en h3, però també apareixen elements en h2. En aquests casos t’has de fixar si aquests elements es serveixen internament des de la nostra web, o bé són externs. En el segon cas no tenim marge de millora, òbviament. En qualsevol cas, és important que ja no s’enviï res per HTTP1, i com més contingut puguem servir per HTTP3, molt millor.

Bases de dades

Totes les webs necessiten una base de dades per emmagatzemar els continguts i registres, i un bon emmagatzematge i processament de la informació agilitza les peticions i, en conseqüència, el rendiment de la web. Els sistemes més comuns són MySQL i MariaDB. A priori és millor MariaDB, sobretot per processar bases de dades grans (vegeu la comparativa MySQL vs MariaDB). Conèixer el tipus de base de dades d’un projecte és complicat des de fora; ho has de consultar al teu panell de hosting o preguntar-ho al teu proveïdor.

Tecnologia d’emmagatzematge

La nostra web s’emmagatzema en discs durs, i la qualitat i capacitat d’aquests és clau. Els sistemes més comuns són l’HDD i l’SSD. La diferència en la velocitat d’escriptura, esborrat i peticions és abismal. Si encara no utilitzes SSD, és una cosa molt interessant a valorar. Novament, és una informació que has de consultar al teu panell de hosting.

TTFB

Mesura la durada des que es fa una petició de contingut a la web fins que es rep el primer paquet de dades. El temps de resposta, comúment conegut.

Es pot analitzar amb diverses eines; en aquest cas una bona opció és Speed Vitals.

Aquesta eina és molt intuïtiva, ràpida, i et dona el TTFB des de diversos països. L’exemple que veus és claríssim: compleix el TTFB des de Madrid però no des de l’estranger. Aquí entra la valoració de negoci: si es tracta d’una web i un negoci d’orientació local o estatal, no hi ha problema. En canvi, si té l’objectiu de captar usuaris i/o clients de diversos països, seria un punt clau a millorar.

Una alternativa interessant, i en local, és utilitzar Chrome Dev, però has d’anar amb molt de compte, perquè hauries de configurar la xarxa i dispositius que fa servir Google per al seu Speed Test, ja que la teva xarxa probablement processa més ràpid.

GTmetrix també seria una opció molt vàlida, encara que el fet que les seves anàlisis siguin des del Canadà sovint pot desvirtuar les xifres:

Amb aquesta i altres mètriques veureu que, segons l’eina escollida, els valors són diferents. Per això és important anar familiaritzant-se amb elles i, sempre que fem comparatives, utilitzar la mateixa eina i configuració.

Mesures a prendre sobre servidors

Tots els punts abans esmentats s’han d’analitzar. Ara bé, en alguns casos, si ja tenim una opció correcta, potser no interessa canviar a l’opció perfecta si els recursos i riscos no ho compensen. És especialment recomanable actualitzar la versió de PHP si és possible, però, per exemple, un canvi de tecnologia de base de dades normalment no compensarà, ja que per una petita millora de rendiment ens requerirà molt desenvolupament i costos.

Afrontar un canvi de hosting sempre és una cosa laboriosa i delicada. Si la valoració inicial no és desastrosa, explora les opcions per treure més suc del hosting actual. I només si això no és viable, afronta la migració cap a un altre hosting.

En el segon bloc, a nivell de projecte web hem d’analitzar:

• Nombre de peticions per tipologia de pàgina (pàgines, posts, tag…)
• Recursos interns (CSS, JS, IMG, PDFs…)
• Complexitat del DOM
• Complexitat de CSS i JS
• Tipus de lletres utilitzades (3 o 4 haurien de ser suficients; moltes webs tenen més tipografies de les que utilitzen)
• Memòria cau
• CDN

En aquest apartat veurem aspectes de configuració de la nostra web que estan impactant en el rendiment i que tenen marge de millora.

Passarem una eina, la que més ens agradi, i ens llançarà algunes recomanacions.

En el cas que utilitzis un CMS com Wordpress o Prestashop, la nostra recomanació és que abans d’afrontar això facis una auditoria de plugins/mòduls. Has de fer el següent:

• Els plugins que no s’estiguin utilitzant, elimina’ls. No n’hi ha prou amb desactivar-los, cal eliminar-los del tot. Google en el seu propi test ja ens avisa d’això:
  
• Tots els plugins actius han d’estar actualitzats, ja que afectaran molts aspectes, entre ells el rendiment. No cal dir que per poder-los actualitzar necessitarem llicències, i més val no escatimar-hi. Això també s’aplica al tema, en cas de fer-ne servir un.
• Optimitzem tots els plugins que tenim. En el cas de WPO, hauràs d’escollir aquells que més t’agradin per optimitzar aspectes de compressió, renderitzat, etc. Aquí cada mestre té el seu mètode: WP Rocket és una bona opció però no l’única, prova’n.
• Optimització de tipografies: per estalviar trucades externes, és important carregar internament les fonts i deixar de fer-ho des de fonts externes com Google Fonts. Si utilitzes Wordpress, hi ha plugins com OMGF que et poden ajudar.

• Imatges massa grans: en aquests casos has de comprimir-les a la mida mínima viable, sense que afecti una visualització òptima del contingut del lloc. Aquest procés es pot fer manualment, però el millor és fer-ho massivament mitjançant scripts o, en el cas de Wordpress, amb algun plugin tipus Imagify. Has de tenir en compte que s’han d’optimitzar les imatges actuals del lloc, però també has de preveure què passarà amb les futures (necessitaràs rutines o indicacions estrictes per a qui pugi contingut perquè pugi les noves fotos correctament).

• Fes servir formats d’imatge de nova generació: aquí la clau és lliurar les imatges en format WebP, essencialment, que és el format que demana Google, però mantenint les versions originals JPG o similars.
  
• Elimina els recursos que bloquegen el renderitzat: aquí és imprescindible carregar d’entrada els JS i CSS que necessitem per a un primer visualitzat del contingut de la pàgina a la part superior, mentre que la resta els podem carregar posteriorment (defer, async).

• Ajorna la càrrega d’imatges que no apareixen en pantalla: el mateix que hem fet amb els fitxers JS i CSS s’ha d’aplicar a les imatges. D’aquesta manera, a mesura que l’usuari faci scroll, es carregaran les imatges, en lloc de carregar-les totes d’entrada.
  
• Reduir el temps de resposta del servidor: aquest missatge hauria de desaparèixer si hem atès l’apartat anterior de l’article, on s’afrontaven els ajustos de servidor. Si això no està ben resolt, importa poc la resta d’accions que prenguem.

6. Resum i reflexions finals

No t’obsessionis amb la nota del Page Speed Insights. Pensa que és un test molt extrem, pel dispositiu i la xarxa utilitzats. En alguns casos un projecte no es podrà posar en verd per les seves característiques; es tracta de treure’n el màxim suc aportant recursos raonables. Fixa’t especialment en si complim els estàndards que demana Google en les mètriques principals de les Core Web Vitals.

A nivell de servidor, ja hem comentat que un canvi dràstic no és senzill, i en alguns casos serà impossible. Considera com a mínim la possibilitat d’actualitzar la versió de PHP, i per a projectes nous o migracions, aleshores sí, planteja un escenari de màxims.

En canvi, a nivell de projecte web, les optimitzacions més importants són totes les que tenen a veure amb les imatges (compressió, fer servir la mida que necessites, utilitzar formats de nova generació com WebP), així com tot el que té a veure amb el processament de JS i CSS (compressió, càrregues internes/externes, càrregues ajornades i asíncrones).

Fes servir Google Search Console i l’informe CruX a Locker Studio per fer seguiment del rendiment que experimenten els usuaris reals de la teva pàgina web. Has de ponderar els esforços amb el tipus d’usuaris reals que el teu projecte té (països, dispositius, etc.), o els que vol tenir en el futur.