Guia WPO per optimitzar la velocitat del teu lloc web

Guia WPO per optimitzar la velocitat del teu lloc web
David Kaufmann
Tutorials SEO
19 min read

Durant els darrers anys, hem vist com els professionals del màrqueting situen la velocitat de càrrega al capdamunt de tot procés d'optimització. El 2017, Google va començar a emfatitzar la importància de la velocitat de càrrega i la seva futura influència al posicionament, però no va ser fins l'estiu del 2018 que Google va fer aquesta declaració oficial.

En aquest article el nostre objectiu és ajudar-te a començar a optimitzar i millorar la velocitat de càrrega del teu lloc web pel teu compte. Com qualsevol procés d'optimització, hi ha una part tècnica que pot esdevenir complexa. A SEO Alive, sempre que escrivim un article d'aquest tipus volem que el puguis implementar tu mateix, encara que algunes accions requereixen un nivell més tècnic de coneixement. Sincerament, però, no ens tornem bojos perseguint les puntuacions a les eines que utilitzarem per auditar el WPO del nostre lloc.

L'optimització depèn molt de com s'ha dissenyat la plantilla, i no totes les plantilles permeten obtenir el mateix rendiment. És important tenir-ho en compte.

Comencem!

Què és WPO?

Web Performance Optimization, que anomenem WPO, és simplement l'optimització dels diferents processos que afecten com es carrega un lloc web.

Com mesurar la velocitat de càrrega d'un lloc web?

Hi ha moltes eines per mesurar la velocitat de càrrega. Les més populars són:

Abans de començar una auditoria, és important tenir en compte que la velocitat de càrrega varia per a cada usuari. Diferents variables poden afectar com se sent la velocitat per a un usuari a Conca enfront d'un a Ottawa.

Per això, en lloc de treballar en temps de càrrega en segons, recomanem centrar-se en optimitzar:

  • Pes del lloc web (MB)

  • Peticions

  • Temps de resposta del servidor

Si millorem aquestes 3 àrees, la velocitat de càrrega millorarà independentment d'on es troba l'usuari.

Aprofundirem en cada àrea i, mitjançant les diferents eines, veurem com treballar-les per millorar el rendiment de cada URL. Per què dic cada URL? Perquè, encara que pugui semblar obvi, m'he trobat amb molts casos en què només s'avaluaven les dades de la pàgina d'inici, i per descomptat, cada pàgina d'un lloc no carrega els mateixos recursos.

Eines de Desenvolupador de Google

Abans de començar, vull explicar algunes opcions que Google ofereix mitjançant les seves eines de desenvolupador. Aquesta eina és una de les més importants per analitzar com funciona un lloc web. Fes clic dret a la pàgina que el navegador té oberta i apareixerà un panell amb diferents opcions. Anirem a Inspeccionar (Ctrl + Shift + I).

Un cop oberta aquesta eina, anirem a l'opció NETWORK que trobaràs a la part superior. Si premem ENTER de nou al navegador, l'eina mostrarà la càrrega dels diferents recursos.

temps de càrrega a les eines de desenvolupador de Google
temps de càrrega a les eines de desenvolupador de Google

A la part inferior de la imatge, podem veure les dades que ens interessen per a una vista general de com es carrega el lloc.

Aprofundint més en aquest panell des de la part superior i mirant l'estructura de columnes, tenim:

  • Name: el nom del recurs.

  • Status: el codi de resposta del recurs (200, 301, 404...)

  • Type: el tipus de recurs (script, font, png, jpg, stylesheet...)

  • Initiator: quin recurs activa la petició.

  • Time: quant ha trigat la petició.

  • Waterfall: una representació gràfica dels temps de càrrega d'un recurs.

Si fem clic dret a la part superior, podem afegir i eliminar columnes amb aquesta informació.

afegint i eliminant elements informatius a network
afegint i eliminant elements informatius a network

Activar elements informatius addicionals com Domain, Scheme o Cookies pot ajudar en casos específics a localitzar recursos que ens podrien estar causant algun tipus de problema, però en aquest punt ens quedarem amb els que vénen predefinits.

Hi ha un aspecte que, encara que molt interessant, només tocaré lleugerament perquè el tinguem present. La velocitat de connexió, especialment al mòbil, és una peça clau de com es carrega un lloc. Des d'aquesta eina podem simular velocitats més lentes com 3G al mòbil.

simular una velocitat de transferència lenta
simular una velocitat de transferència lenta

Com saber el pes d'una URL i com reduir-lo?

El pes, ja sigui en Megabytes o Kilobytes, és una de les principals raons per les quals una URL triga a carregar-se. Per això comencem aprofundint en aquest aspecte, ja que marcarà el camí per aconseguir una bona optimització al nostre lloc.

Les dades següents provenen de l'eina mencionada abans, GTMETRIX, i corresponen a un lloc web que estic a punt de començar a optimitzar.

mètriques de pes web
mètriques de pes web

Ens centrarem en les dades de la columna dreta, la que es refereix a (Page Details), específicament el Total Page Size.

A primera vista, el pes d'aquest lloc està molt per sobre de la mitjana, però tingues en compte que el que importa no és el pes total del lloc sinó quant triga a carregar-se aquest pes, perquè hi ha una cosa anomenada Lazy Load, una funció que retarda la càrrega fins que l'usuari necessita el recurs. En parlarem més endavant.

També podem trobar aquesta informació a les eines de desenvolupador, al panell que hem vist abans, que us recordaré de nou.

temps de càrrega a les eines de desenvolupador de Google
temps de càrrega a les eines de desenvolupador de Google

Si mireu a la part inferior, tant els 7,5 MB com les 215 peticions vénen molt a prop de les xifres reportades per GTMETRIX. És important per a tu saber d'on obté GTMETRIX la seva informació en cas que mai vulguis utilitzar una eina diferent.

Ara veiem què està pesant tant i com podem solucionar-ho.

L'opció Waterfall ofereix una mirada visual a com es carreguen els recursos, mostrant la URL del recurs, l'estat, el domini i la columna Mida. Si fem clic en aquesta última columna ordena els pesos de més gran a més petit i de més petit a més gran.

analitzant la càrrega mitjançant el waterfall
analitzant la càrrega mitjançant el waterfall

Mirant els pesos, podem veure, com passa a la majoria dels casos, que les imatges són en gran part responsables del pes excessiu de la URL.

No hi ha una especificació formal per al pes màxim que hauria de tenir una imatge, però recomanem no més de 100 KB i, si en tens l'opció (si utilitzes Photoshop sí), configurar les imatges perquè es carreguin progressivament com a JPG i evitar PNG sempre que no necessitis un canal Alpha (transparència).

Reduint el pes de les imatges millorarem significativament la càrrega del lloc, i hi ha diverses eines que pots utilitzar. Personalment optimitzo amb Photoshop, però hi ha opcions online interessants:

Tant GTMetrix com l'eina de Google ens permeten visualitzar recursos per tipus, és a dir, només imatges, scripts, CSS...

Això és útil per a una perspectiva més àmplia d'on treballar. En aquesta URL, les imatges representen 4 MB dels 7,2 MB, així que una gran part del problema de pes és allà. Tot i així, hi ha altres recursos que destaquen com a extremadament pesats per al seu tipus, com un fitxer CSS de més de 700 KB i un Script de més de 300 KB.

En aquest punt vull aclarir que quan duem a terme una optimització de velocitat de càrrega (WPO) ens hem d'enfrontar a certs problemes que, encara que tenen solucions, no estan al nostre abast actuar.

En aquest cas veiem un fitxer CSS molt gran. Si el dissenyador va crear un CSS de més de 700 KB, optimitzar aquell fitxer específic serà difícil.

Què podem fer per reduir el pes d'aquests fitxers?

Minificar (CSS, JS i HTML)

La minificació és un procés que busca reduir el pes del fitxer eliminant dades innecessàries com comentaris, espais, codi repetit i codi no utilitzat. Hi ha moltes eines per realitzar aquest procés, excepte per a la part del codi no utilitzat, que és més difícil d'optimitzar i requeriria entrar manualment al fitxer (cosa que no recomano).

Eines per minificar fitxers

Per sort estem parlant de WordPress, i com tots sabem, a WordPress és molt rar no trobar un plugin que gestioni aquesta operació.

Personalment m'agrada utilitzar-ne un de completament gratuït, Autoptimize, i un de pagament, WP Rocket.

En aquest article no vull explicar com funcionen aquests plugins tant com fer les tasques d'optimització. Perquè si utilitzem altres plugins, també tenen aquestes opcions, i el millor és entendre el que estem fent.

Minificant amb WP Rocket

Aquesta part no és complexa. Només anem a la pestanya d'optimització de fitxers i marquem la casella minificar HTML. A WP Rocket aquesta opció es repeteix a sota per a fitxers CSS i JS. Tot i així, recomano activar aquesta casella i provar. Repeteix aquesta opció una a una, ja que si alguna cosa falla serà més fàcil identificar el problema.

minificar html amb wp rocket
minificar html amb wp rocket

Abans de comprovar l'efecte de la minificació hem de netejar la cache, altrament no veurem el resultat de l'HTML actualitzat.

Com netejar la cache del navegador?

Aquests tipus de plugins inclouen opcions per netejar la cache, que podem veure a la part superior.

netejar la cache amb wp rocket
netejar la cache amb wp rocket

Una altra manera és mitjançant el navegador, un cop activades les Eines de Desenvolupador de Google (Ctrl + Shift + I).

Fes clic dret a la fletxa "recarregar pàgina" i selecciona "buidar cache i recarregar de manera forçada".

netejant la cache des del navegador Chrome
netejant la cache des del navegador Chrome

Minificant amb Autoptimize

Amb Autoptimize, l'acció optimize és la que realitza la minificació, amb la particularitat d'oferir una opció per mantenir comentaris HTML. Aquests comentaris normalment són afegits pels desenvolupadors per mantenir informació que pot ser útil al futur.

minificar html amb autoptimize
minificar html amb autoptimize

Per comprovar que aquesta optimització ha tingut efecte, aniríem al codi font de la URL i hauríem de veure quelcom així:

exemple d'html minificat
exemple d'html minificat

El codi esdevé il·legible però la seva funcionalitat és la mateixa.

Aquestes opcions es repeteixen de la mateixa manera a WP Rocket i Autoptimize per a fitxers CSS i JS. Com he mencionat abans, no recomano optimitzar-ho tot alhora, sinó d'1 en 1. Aquests plugins mantenen còpies dels fitxers minificats, així que revertir a l'original és possible desmarcant la casella corresponent.

Per continuar reduint el pes de la pàgina tenim 2 opcions més:

  • Eliminar o reduir plugins que afegeixen CSS o JS a la càrrega.

  • Eliminar o retallar codi no utilitzat del fitxer CSS.

Aquestes 2 opcions són més complexes i requereixen més coneixement, ja que has d'anar amb compte i assegurar-te que no hi hagi crides d'altres pàgines a la part que estàs eliminant.

Tot i que eliminar plugins no sempre és possible per al recurs que proporcionen, hi ha plugins que estan més ben optimitzats que altres, és a dir, menys peticions i JS més lleugers. Així que al meravellós ecosistema de WordPress gairebé sempre hi ha una alternativa.

Temps de càrrega vs temps de resposta

Ara és hora de parlar de peticions, temps de resposta i temps de càrrega. En aquest punt hem de mencionar una part fonamental del procés: el servidor. L'optimització del servidor normalment està fora del nostre abast, així que és important triar una solució eficient.

Però anem pas a pas.

Què és una petició?

Una petició, o HTTP Request, és una crida feta del client al servidor per demanar un recurs determinat. Les peticions poden colpejar diferents servidors.

Les peticions poden ser HTTP o HTTPS. Si mirem l'estructura d'una petició, podem analitzar on passa el retard de temps.

Anàlisi del temps d'una petició HTTP

estructura de petició HTTP
estructura de petició HTTP

Desglossem el que veiem en aquest gràfic de temps.

  • La petició s'inicia però està bloquejada o en cua: si el bloqueig dura molt de temps pot ser per diverses raons: peticions de major prioritat o moltes peticions a aquest origen.

  • DNS Lookup: el navegador està resolent l'adreça IP de la petició.

  • Connecting: el temps que triga a connectar amb el servidor per resoldre la petició. Si aquest temps és alt, podria indicar problemes de xarxa, errors de connexió o un servidor sobrecarregat.

  • Sending: s'envia la petició de recurs.

  • Waiting: aquest és el temps que el servidor triga a resoldre una petició i enviar una resposta; si és llarg, hi ha un problema al servidor.

  • Receiving: rebent el recurs.

Una petició HTTPS afegeix un pas més, mostrat aquí.

anàlisi d'una petició HTTPS
anàlisi d'una petició HTTPS

Aquestes dues captures de pantalla pertanyen a dos llocs diferents, un no optimitzat (HTTP Request) i un altre optimitzat (HTTPS Request).

Si mires de prop i compares, la diferència més gran està al temps d'espera. En aquests casos, hauries d'analitzar el servidor amb més detall.

Peticions al servidor: com podem reduir-les?

Com hem vist, el nombre de peticions està estretament lligat al temps de càrrega, així que reduir el nombre de peticions milloraria els temps de càrrega d'una URL. El sentit comú juga un paper al procés d'optimització i saber si un recurs és realment útil per a l'usuari o el nostre negoci. Aquest és el moment per acomiadar-se de certs recursos que no aporten res, però no sóc jo qui ho ha de decidir.

Tot i així, tenim opcions per millorar les peticions, encara que aquestes accions no aportin un gran canvi a la càrrega del lloc. Em repetiré: el millor és eliminar recursos que no aporten res.

Combinar CSS i JS

Una altra acció popular en optimitzar una pàgina web és combinar recursos CSS i JS, però què significa això?

L'objectiu de combinar és reduir peticions a costa d'augmentar el pes del fitxer. Combinar significa unificar els diferents recursos CSS o JS en un de sol.

Si els temps de resposta són llargs, combinar pot ser beneficiós. Si els temps d'enviament són molt lents, potser una altra tècnica és millor.

L'ideal és combinar mentre tens un bon servidor, així guanyem als dos costats.

Combinant recursos amb WP Rocket i Autoptimize

L'operació de combinar amb aquests plugins és tan senzilla com abans. Només marquem la casella corresponent.

combinar css a wp rocket
combinar css a wp rocket

A WP Rocket les opcions per combinar CSS i JS són les mateixes; els panells són pràcticament idèntics. Com veiem a la imatge, hi ha una caixa per afegir la ruta de fitxers que no volem combinar.

A sota de la casella, també veiem una nota sobre no utilitzar l'opció combinar si estem utilitzant HTTP/2. Aquest article explica més sobre HTTP/2.

combinar css autoptimize
combinar css autoptimize

Autoptimize ofereix més opcions per treballar amb CSS i reduir peticions. A l'opció que marco, combina i et dóna un avís sobre l'efecte que pot tenir, però al final això és sempre relatiu.

En aquesta primera part de l'article, volia explicar en què consisteixen certes accions bàsiques, les que normalment veiem a pràcticament tots els plugins d'optimització WPO, però encara queda molt que podem fer per millorar tant les peticions com els temps de càrrega.

Configuració de cache

Sense dubte, l'optimització de cache és una de les accions on notarem les majors millores en com es carrega un lloc. En aquest article sobre SEO per a WordPress vaig explicar com funciona la cache. T'animo a fer-hi un cop d'ull per entendre com funciona.

Autoptimize i WP Rocket realitzen accions de cachejat, però WP Rocket et dóna un parell d'opcions més. Val la pena destacar que els plugins han convertit aquesta optimització en quelcom més senzill: amb prou feines tens un parell d'opcions i el procés és ràpid i indolor.

configurar wp rocket
configurar wp rocket

Com veus, WP Rocket et permet treballar 4 coses:

  • Activar cachejat per a dispositius mòbils.

  • Desar fitxers separats per a dispositius mòbils.

  • Activar cachejat per a usuaris registrats.

  • Especificar el temps per netejar la cache.

Depèn de cada projecte quina opció seleccionar, però amb tot això en ment el meu consell és:

  • Cache mòbil sempre, perquè encara que la majoria de llocs siguin responsive, hi ha contingut que pots tenir al mòbil però no a l'escriptori.

  • Fitxers per separat.

  • Sense cache per a usuaris registrats, sobretot perquè si estic fent edicions no vull cachejat.

  • Temps de cache, que depèn de quants canvis fas al teu lloc. Si és un lloc de notícies diari, curt; si és contingut que no s'actualitza freqüentment, més llarg.

Lazyload

La funció lazyload ajuda a mostrar recursos (Imatges i Iframes) quan l'usuari els necessita; és a dir, el navegador no carrega aquests recursos fins que l'usuari fa scroll fins a ells. Aquesta funció s'implementa a molts plugins i fins i tot ve preconfigurada en alguns temes de WordPress. A partir de la versió 76 de Chrome, ve fins i tot nativament al navegador.

Això vol dir que afegint l'atribut loading="lazy", el navegador ja interpreta la càrrega lazy de la imatge, però per descomptat no tots els navegadors interpretaran això, així que recomano continuar utilitzant el plugin. Aquí tens un vídeo extret de web.dev mostrant un exemple de què tracta la càrrega lazy d'imatges.

Optimització d'iframes

Si utilitzem iframes per incrustar contingut d'altres llocs, tenim dues accions que podem utilitzar per millorar la nostra càrrega.

  • Càrrega lazy mitjançant la funció lazyload

  • O substituir l'iframe per una imatge fins que l'usuari fa clic.

Tant la primera com la segona opció es poden activar mitjançant, un cop més, el nostre plugin de referència WP Rocket.

càrrega lazy per a vídeos a wp rocket
càrrega lazy per a vídeos a wp rocket

Autoptimize no té aquesta part però ofereix la instal·lació d'un plugin complementari per fer-ho https://wordpress.org/plugins/wp-youtube-lyte/

Càrrega diferida de fitxers JS amb Defer o Async

Els fitxers JS són un dels culpables del que les auditories de velocitat anomenen bloqueig de renderització d'una pàgina. Això passa quan, mentre renderitza, el navegador s'atura per descarregar un fitxer JS i executar-lo. L'objectiu de l'optimització WPO és lliurar informació a l'usuari tan aviat com sigui possible, per això es considera bloquejant, perquè no es renderitza res fins que el JS descarregat s'executa.

Per això aquest tipus d'acció tendeix a ser marcat a l'auditoria. En utilitzar plugins o temes de tercers que no estan ben optimitzats, podem tenir JS que bloquegi la renderització perquè està, per exemple, a la capçalera.

En aquests casos hauríem d'utilitzar dos atributs que s'afegeixen al codi de crida del JS, Defer i Async. Perquè aquests atributs funcionin, els scripts han de ser externs.

A SEO Alive utilitzem el plugin Pre Party Resource Hints, que et permet seleccionar quins fitxers i quin mètode de càrrega vols aplicar. Una meravella!

Quina és la diferència entre Defer i Async?

Encara que tots dos atributs tenen un objectiu similar, evitar que la interpretació del DOM HTML s'aturi pel JS, hi ha una diferència notable entre els dos.

Amb l'atribut Async el recurs es descarrega sense aturar la càrrega d'HTML, però un cop descarregat, la càrrega d'HTML s'atura per executar el JS; amb l'atribut defer el recurs també es descarrega en paral·lel amb la càrrega d'HTML, però s'executa quan acaba la càrrega, així que no hi ha bloqueig per part de l'script.

En aquest sentit hi ha diferències entre WP Rocket i Autoptimize. WP Rocket pren decisions molt més fàcils per a tu i actua de manera semi-automàtica per evitar que el JS bloquegi la renderització; a Autoptimize, en canvi, només pots activar l'opció Async.

A Autoptimize, sota la pestanya extra tenim aquesta opció per afegir els fitxers JS que volem carregar amb Async, però per a major flexibilitat recomanen un altre plugin complementari, "Async Javascript".

càrrega async autoptimize
càrrega async autoptimize

Amb aquest plugin podem treballar tant amb Defer com amb Async, i fins i tot ofereix opcions d'un clic per facilitar les coses. El bo d'aquest plugin és que podem treballar amb scripts i excloure els que considerem necessaris. A WP Rocket, en canvi, hem de confiar en el que fa el plugin, encara que ho fa bé.

Aquesta opció està a la mateixa pestanya d'optimització de fitxers.

atribut defer wp rocket
atribut defer wp rocket

Què és un CDN i com ens pot ajudar?

Un CDN és el que es coneix com una xarxa de distribució de contingut. El CDN s'encarrega de desar part de la informació i els recursos per alleugerir la càrrega del servidor per a aquests recursos i respondre millor a la càrrega. Els CDN també tenen una funció de còpia geogràfica, per mantenir el recurs disponible a diferents punts i servir-lo a l'usuari independentment d'on es connecti. Normalment aquest tipus de servei s'utilitza per a fitxers pesats com Imatges i Vídeos.

Subscriure's a aquest servei és important quan tenim llocs amb molt de trànsit, encara que no s'hauria de descartar per a llocs amb poc trànsit.

Altres accions que ens portaran una mica més de millora

Per acabar l'article tenim 3 millores més que, encara que no produiran grans canvis als temps de càrrega, ens ajudaran a reduir peticions, i al final això és el que volem.

Optimització de fonts

L'optimització de fonts es pot fer mitjançant plugins o manualment editant i optimitzant el CSS. L'ideal seria només cridar la font que vas a utilitzar i no, com passa en molts casos, descarregar un fitxer amb totes les Google Fonts.

Autoptimize té una opció per treballar amb fonts.

optimitzar fonts amb autoptimize
optimitzar fonts amb autoptimize

És difícil dir quina opció triar sense veure el projecte, perquè no sé quina font utilitza la teva plantilla i quan es carrega, així que el millor és provar i veure el resultat.

Com veus, just després de les opcions de Google Fonts tenim "Remove Emoji", que ens estalviarà una petició al servidor. La seva funció és simplement convertir símbols representatius d'emojis en l'icona.

emojis wp rocket
emojis wp rocket

WP Rocket també ens permet desactivar aquests emojis i també ofereix l'opció d'evitar que el contingut sigui incrustat en llocs de tercers.

Al final hi ha moltes accions per millorar la velocitat de càrrega d'un lloc. No sempre és possible treballar en profunditat per optimitzar cada recurs, perquè depèn del tipus de negoci i el que necessita.

Espero que aquesta guia d'optimització WPO sigui útil i la puguis aplicar als teus projectes o per als teus clients.

Автор: David Kaufmann

David Kaufmann

He passat els últims 10+ anys completament obsessionat amb el SEO — i sincerament, no ho canviaria per res.

La meva carrera va fer un salt qualitatiu quan vaig treballar com a especialista SEO sènior a Chess.com — un dels 100 webs més visitats de tot Internet. Operar a aquesta escala em va ensenyar coses que cap curs ni certificació podrien transmetre.

D'aquella experiència vaig fundar SEO Alive — una agència per a marques que es prenen seriosament el creixement orgànic. I com que no trobava cap eina que gestionés bé tant el SEO clàssic com el món de la IA, vaig construir SEOcrawl. Si busques un partner SEO sènior que s'estimi aquest sector de debò — m'encantarà parlar amb tu!

→ Читайте всі статті від David
Більше статей: David Kaufmann

Дізнайтесь більше контенту цього автора