google-audit.jpg

Desvetllem com quasi assolim el 100 a Google Audit Lighthouse

Els desenvolupadors i dissenyadors web ens esforcem per millorar l’accessibilitat, usabilitat i el SEO dels nostres llocs web.

Estem evolucionant els mètodes i tècniques per a millorar el nostre contingut, semàntica i codi. Afegim plugins per optimitzar rendiment i busquem millors allotjaments. Però tots compartim una frustració i és que no hi ha un únic barem ni eina amb la qual analitzar i tenir clar l’impacte del nostre esforç.

Ara, gràcies a Google Audit Score, Lighthouse, podem tenir una idea global de com es comporta el nostre lloc web sota diferents aspectes: rendiment, accessibilitat, SEO, … i no menys important, tot això sota l’òptica de Google.

Lighthouse és una eina d’auditoria de pàgines web de codi obert desenvolupada per Google. Està disponible a les eines de desenvolupador de Chrome, tambè en forma d’extensió de Chrome i com a mòdul npm que podem executar amb Nodejs.

Lighthouse realitza auditories en algunes àrees clau com: Rendiment, Accessibilitat, Bones pràctiques i Aplicacions Web Progressives. Persegueix en totes les àrees l’acostar-se al màxim a l’experiència d’usuari final. Per a això te en compte els problemes que pugui trobar per a visualitzar una determinada pàgina del nostre lloc web en condicions no favorables de xarxa o velocitat de procès.

Google Lighthouse audita la pàgina web i la classifica de 0 a 100. Una “Bona experiència de l’usuari final” està per sobre de 80 i una “Mala experiència” quan ens situem per sota d’aquest 80.

A wetopi.com ens esforcem contínuament per millorar els nostres serveis, la velocitat dels nostres servidors i l’accessibilitat del nostre lloc web. Així que millor començar per la nostra pròpia web.

En aquest article, reproduirem els passos duts a terme per a millorar la puntuació de la nostra pàgina Home a Google Lighthouse. Varem començar amb baixes expectatives. Tinguem en compte que la web ja té uns quants anys i es va desenvolupar amb un tema molt recarregat de funcionalitats pensant més en la flexibilitat que en la velocitat. Però cal dir que ha estat gran la nostra sorpresa doncs el resultat final ha estat força espectacular.

Aquest és el nostre viatge

Comencavem amb aquest pobre resultat:

Un mal resultat inicial a Google Lighthouse

Per a gloriosament gairebé fregar el ple de 100 a les puntuacions de Lighthouse !!!

Com ho vam fer?

Un detall abans de començar.

Aquesta era la primera vegada que ens enfrontàvem a la tasca de millorar els resultats a Lighthouse. No teníem una idea clara de l’esforç ni resultats que podíem obtenir. Vam enfilar el camí directe i comencarem a treballar sense pensar en anar prenent notes per a un posterior article.

Com el resultat ha estat molt bo hem decidit repetir el procés per a escriure aquest post.

Per poder refer el camí, restaurarem una copia còpia de seguretat en un servidor de “staging”. Fent-ho així no posarem en risc el treball ja fet a la web que tenim en producció.

A wetopi, desplegar una còpia de seguretat és un simple clic. En aquest enllaç podeu veure quant fàcil resulta el desplegar una còpia de seguretat.

restaurem un backup per refer el procés de millora de resultats a l'Auditoria de Google
Panell del nostre web on tenim corrent els dos servidors: producció i la còpia de seguretat restaurada on farem les reformes.

El procés

Farem a cada pas l’Auditoria de Google Lighthouse, sempre mantenint les mateixes opcions. En el cas present les que vénen per defecte i que simulen un usuari Mòbil en xarxa 3G:

optimitzant la puntuació a Google audit amb les opcions per defecte

Comencem!

Com accedir a Lighthouse?

Dins el navegador Chrome, fem clic amb el botó dret a la pàgina web. Al seleccionar Inspeccionar, apareixerà una barra a un costat o sota, depenent de la configuració.

A la barra superior on es veuen els Elements, Consola, … triem Auditories. I just al final tenim l’opció per a executar la bateria de proves:

Panell de Lighthouse

Quan executem l’auditoria, Google Lighthouse ens va mostrant activitat, i en acabar el test ens mostra el resultat al costat d’una llista d’oportunitats ordenades per “Estalvis” estimats en segons.

Abordem el primer punt del primer bloc d’oportunitats:

Defer unused css

En altres paraules: deixa per a més tard (o elimina) els estils que no utilitzis.

Defer unused css es la primera opció per Optimizar el resultado a Google Audits

El punt 1 ens indica que estem carregant un enorme arxiu CSS. 

Aquest és el preu a pagar quan treballem amb un tema WordPress poc optimitzat o amb gran quantitat d’opcions. Prenem la decisió de substituir els CSS del tema per una còpia una mica més neta que afegirem dins del nostre tema fill.

El primer pas: moure una còpia de style.css al nostre tema fill.

Després cal indicar-li a WordPress que no agafi l’arxiu d’estils original sinó el que hem copiat al nostre tema fill. Al nostre cas, com ja estem treballant amb un tema fill, només cal editar l’arxiu functions.php que ja teníem d’abans.

A continuació es mostra el codi per a retirar ell full d’estils del tema amb un “dequeue” i com incorporar la nostra versió depurada amb un “enqueue”:

function my_load_child_scripts() {
    wp_dequeue_style( THEME_SHORT.'-theme' );
    wp_deregister_style( THEME_SHORT.'-theme' );

    wp_enqueue_style( THEME_SHORT . '-child-theme' , get_stylesheet_directory_uri() . '/style.css', array(), false, 'all' ); 
}
add_action( 'wp_enqueue_scripts', 'my_load_child_scripts', 100);

Aquesta tasca de “depuració” requereix paciència i força temps. Realitzem diverses iteracions provant a cada pas que no trenquem res. Ens trobem grans blocs com el de Woo-commerce, “Sliders” i galeries que teníem clar que no utilitzàvem.

Al final acabem reduint el nostre style.css a la meitat de la seva mida original.

Per a ajudar-nos a identificar blocs de codi CSS innecessaris, utilitzem l’eina de desenvolupadors de Chrome Coverage

El resultat va ser un salt de 54 a 66 en la secció Rendiment:

Performance audit amb un resultat de 66 força millor

Continuem amb el següent punt:

Defer offscreen images

Aquest punt ens presenta l’oportunitat de reduir el temps de càrrega en 1.05 segons!

Defer offscreen images

Google ha fet un bon treball i en cada apartat tenim un “Learn more” on trobem detalls i ajudes.

Les imatges fora de la pantalla són imatges que apareixen below the fold (per sota del primer tram de finestra del navegador). Atès que els usuaris no poden veure imatges fora de la pantalla quan carreguen una pàgina, no hi ha raó per a descarregar les imatges fora de la pantalla com a part de la càrrega de la pàgina inicial.

Després d’algunes recerques buscant el plugin més ràpid i lleuger per a resoldre aquest problema, ens decantem per provar amb Lazy Load de WP Rocket.

Lazy Load Actualment està actiu en més de 20,000 instal·lacions amb una qualificació de 4 de 5 estrelles. El gran avantatge d’aquest plugin és que pesa menys de 10 KB. No hi ha opcions per a configurar, simplement s’instal·la, s’activa i la càrrega diferida simplement passa a funcionar.

NOTA: després de la instal·lació de Lazy Load, cal anar a la configuració d’administració de WordPress i activar l’opció de Càrrega d’Imatges diferida.

Amb ús de Lazy Load saltem de 66 a 70 en l’apartat de Performance/Rendiment.

Preconnect:

L’establiment de connexions sovint implica un temps considerable en xarxes lentes, especialment quan es tracta de connexions segures. Això passa pel fet que sol ser necessari fer consultes de DNS, resoldre redireccions, etc. I això comporta diversos viatges d’anada i tornada al servidor final que s’encarrega de la sol·licitud de l’usuari.

El concepte de “Preconnect” consisteix a informar el navegador de la nostra intenció perquè pugui anticipar-se. La solució és tan simple com afegir una etiqueta a la capçalera de la nostra pàgina indicant els dominis externs que utilitzarem.

Per a afegir a la capçalera <head> els etiquetats preconnect, hem d’editar l’arxiu header.php dins el directori del tema fill:

<link rel="preconnect" href="https://www.google-analytics.com">
<link rel="preconnect" href="https://stats.g.doubleclick.net">

Eliminant recursos “render-blocking”:

Es tracta d’eliminar els recursos que bloquegen el pintat de la pàgina. Aquesta optimització al costat de l’anterior van alternant-se conforme avancem en l’optimització. Ara ens enfrontem a reduir o si és possible eliminar part del nostre javascript.

Retirem els vídeos i el seu javascript:

Una important decisió que varem prendre va ser la de retirar els vídeos que incrustàvem amb el servei extern Wistia. Ens vam adonar amb l’auditoria que els CSS i els javascript de Wistia estaven bloquejant l’execució del pintat. Un altre detall és que les caràtules de vídeo servides no estaven del tot optimitzades.

Reemplacem els vídeos incrustats amb infogràfics en format svg.

La següent neteja que realitzem va ser desfer-nos de jquerymigrate (la consola de Chrome ens dona la pista al mostrar “JQMIGRATE: Migrate is installed, version 1.4.1″)

jQuery Migrate simplifica el procés de migrar i compatibilitzar el codi jQuery antic perquè funcioni amb les versions més noves de jQuery. En el nostre cas no hauria de ser necessari, perquè estem usant plugins i temes actualitzats. Provem doncs el nostre site sense jquery migrate.

Eliminant jquery migrate:

Tornem al nostre arxiu functions.php per a retirar ‘jquery-migrate’

//Remove JQuery migrate
function remove_jquery_migrate( $scripts ) {
    if ( ! is_admin() && isset( $scripts->registered['jquery'] ) ) {
        $script = $scripts->registered['jquery'];

        if ( $script->deps ) { // Check whether the script has any dependencies
            $script->deps = array_diff( $script->deps, array( 'jquery-migrate' ) );
        }
    }
}

add_action( 'wp_default_scripts', 'remove_jquery_migrate' );

Aquest fragment de codi, actua quan no estem a wp-admin comprovant si registrem jquery. Si és així elimina jquery-migrate de la matriu de dependències.

En acabar, sempre hem de validar que totes les funcionalitats i racons del nostre lloc continuen funcionant correctament. Tenim sort doncs al nostre cas tot funciona degudament.

I una nova execució de Audit Lighthouse ens va donar la nostra primera puntuació “verda” amb un 89 a la secció rendiment:

Eliminant els vídeos i el jquery migrate incrementem el rendimient a 89

Google fonts al nostre server i ajustos del font-display:

Continuant amb la nostra tasca de reduir el bloqueig, l’auditoria de Google ens suggereix que configurem “font-display” per a reduir el temps de bloqueig.

El nou atribut “font-display” per als blocs @font-face ens permet als desenvolupadors decidir que fer amb el render durant el període en el qual estem carregant les fonts. La idea és no bloquejar el procés de pintat pel que la opció “fallback” és ideal. Amb “fallback”, mentre es carreguen les fonts, el pintat avança usant fonts de sistema. Després, tan bon punt estan carregades les fonts, el navegador les reemplaça.

Un altre gran millora és servir les Google fonts des del nostre servidor. Els nostres servidors wetopi tenen un rendiment òptim i estan configurats per a treure el màxim partit dels sistemes de compressió i cache.

El nostre tema ens permet desactivar l’ús de fonts Google des del mateix panell d’administració WordPress.

Atenció mentre intentem aconseguir una còpia de les fonts, ens adonem que Google fonts site no proporciona tots els formats necessaris per a donar cobertura a diferents navegadors. Necessitem com a minim: woff i woff2.

Per sort trobem aquest fantàstic projecte online: http://google-webfonts-helper que es defineixen perfectament: A Hassle-Free Way to Self-Host Google Fonts. @majodev Moltes gràcies per compartir

Així és com passem a servir les nostres fonts de Google:

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 100;
  font-display: fallback;
  src: local('Roboto Thin'), local('Roboto-Thin'),
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-100.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-100.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 300;
  font-display: fallback;
  src: local('Roboto Light'), local('Roboto-Light'),
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-300.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-300.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: fallback;
  src: local('Roboto'), local('Roboto-Regular'),
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-regular.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/wp-content/themes/angle-child-theme/fonts/roboto-v18-latin-regular.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}
servir les fonts de google des de wetopi ens va permetre incrementar el rendiment
Servir les fonts de google directament millorem sensiblement en rendiment

Introduint Cache i connexió segura https

En aquesta etapa de millora de rendiment, habilitem el plugin de cache WP Super Cache i passem a utilitzar el protocol HTTP/2 per a servir pàgines amb https.

L’únic a tenir en compte és que HTTP/2 requereix sempre d’una connexió segura. Això pot penalitzar el rendiment doncs significa afegir temps per a negociar https i intercanviar els certificats segurs.

Si treballem amb https és molt important tenir un hosting que serveixi les pàgines amb protocols TLS d’última generació. Les darreres versions TLS1.2 i TLS1.3 signifiquen una important reducció en els temps de negociació de la connexió segura.

Per sort nostre, aquesta etapa d’optimización no implica cap esforç. Els servidors a wetopi ja venen perfectament ajustats i amb els més moderns protocols per a servir HTTP/2.

HTTPS incrementa el Google Audit Performance

El resultat comença a donar-nos alegries.

Millorem en “Performance” Rendiment i també en “Best Practices” Bones Pràctiques.

Arribats a aquest punt les oportunitats van reduint-se:

oportunitats per millorar en google audits

El primer punt encara apunta al CSS i javascript. Decidim dedicar més temps a trobar més estils no utilitzats per a reduir el pes. Mentre treballàvem en la neteja, descobrim que estàvem carregant el codi javascript de plugins que no es requerien a la pàgina d’inici. Seria més optim carregar el plugin exclusivament allà on es requereix.

Si volem ser “selectius” en el “com” i en el “quan” carregar els recursos de cada plugin, tenim dos camins:

  1. Cercar un plugin que ens permeti tenir el control de la càrrega dels javascript i CSS. Per exemple W3 Total Cache. Amb aquest plugin podem extreure una relació d’arxius i determinar com carregar-los, on i en quin ordre. Amb aquest plugin també podem aplicar les tècniques de “defer” i “prefetch”.
  2. Carregar els plugins de forma selectiva allí on es necessitin.

Apostem per l’última opció. No obstant això, hi ha un inconvenient i és que si som agressius en les combinacions de plugins podem carregar-nos els avantatges del propi sistema de cache del navegador. El problema es dóna quan tenim moltes combinacions de CSS i les servim concatenades i minimitzades. El navegador es trobarà un arxiu CSS diferent al anar canviant de pàgina.

Organitzar els plugins en dos grups és la nostra aposta: una combinació de plugins per a les pàgines web corporatives i una segona combinació per als blog posts.

Decidim usar “Plugin Load Filter” per a implementar la separació de plugins. Aquest permet activar/desactivar plugins depenent d’un munt de criteris. Recordem no excedir-nos si més tard pretenem concatenar!

De forma resumida, el plugin et dóna una pàgina de configuració amb 2 pestanyes. Dins la pestanya “Registre de filtres”, decidim els plugins que volem controlar segons “Tipus de pàgina”. A la segona pestanyaPage Type Filter Activation” és on repartim l’ús de plugins depenent de si és una “Pàgina” o un “Post”:

Plugin load filter ens permet millorar el resultat de Google Lighthoouse audit

El resultat es positiu, Hem reduït la mida del nostre javascript principal, la qual cosa ens empeny fins al fantàstic resultat de 97, rebaixant el temps de “pintat” a 1.6 segons en xarxes 3G:

97 en performance i un First Content Paint de 1.6 segons

Estem satisfets amb els resultats obtinguts en la secció rendiment pel que avancem a la següent secció de l’Auditoria de Lighthouse.

Millorant els resultats en Progressive Web App

Les aplicacions web progressives (PWA, per les seves sigles en anglès) són aplicacions web que carreguen com a pàgines web o llocs web normals, però que poden oferir a l’usuari funcionalitats com treballar sense connexió, enviar notificacions, … https://en.wikipedia.org/wiki/progressive_web_applications

No totes les pàgines web necessiten funcionalitats PWA. En el nostre cas, la possibilitat de navegar sense connexió ens va semblar interessant. Els nostres clients solen anar a la nostra pàgina web per a fer clic al botó de Login i poder entrar al panell de gestió. Si la nostra web cau o està en manteniment, els usuaris perdrien aquest camí. Val la pena intentar implementar aquesta funcionalitat PWA.

L’ecosistema de plugins de WordPress és com la butxaca de Doraemon: sempre trobem un plugin amb el que resoldre el problema.

Aquest cop surt de la butxaca el plugin SuperPWA

Aquest plugin és impressionant. Un cop instal·lem, configurar es simplement carregar les icones de la nostra aplicació. En menys d’una hora el nostre PWA estava en funcionament.

panell de configuració de Super PWA
El panell de configuració de Super PWA no és gens complex.

El resultat de l’Auditoria va donar un impressionant 100!

Gràcies a l’equip de Super PWA per crear aquest increïble plugin i posar-ho a la disposició de la comunitat WordPress.

Aconseguit aquest punt estàvem en Verd i molt prop del 100 en totes les seccions. Només quedava per resoldre aspectes d’accessibilitat i SEO. En el nostre cas les millores van ser bastant senzilles: imatges sense descripcions a l’etiqueta “alt”, botons sense descripcions accessibles,…

Hem aconseguit quasi el 100 al Google Lighthouse audit

Estem satisfets amb el resultat. És un bon equilibri entre temps invertit i resultats Google Lighthouse. Moure la puntuació d’Accessibilitat i “Best Practices” fins als 100, en el nostre cas significaria un canvi en el disseny i ben segur del tema.

Bonus Extra

Aquí deixem un parell de suggeriments de caràcter genèric que és bo tinguem sempre presents.

Reduïm la quantitat de plugins.

Afegir plugins, la majoria de les vegades, significa incrementar el temps de procés tant del nostre servidor com del nostre navegador. És a dir afegir plugins és donar-li més treball al nostre servidor i als navegadors dels nostres usuaris.

No instal·lem plugins si no és estrictament necessari.

Hi ha plugins amb un fort impacte al “front-end” costat-usuari. Afegeixen fulls d’estil i javascript que rarament usem al 100%. I molt menys en totes i cadascuna de les nostres pàgines web.

Triem temes lleugers.

Pel proper “refactoring” de la nostra web, posarem força atenció a la selecció del tema. El tema és una peça clau en tot web WordPress, és la base sobre la qual construïm i no hem de deixar-nos impressionar pel seu aspecte i quantitat de funcionalitats. Busquem temes lleugers de qualitat contrastada.

Esperem haver pogut contribuir a fer una mica més comprensible el procés d’optimització d’un lloc web analitzat amb Google Lighthouse :)

Si estàs pensant a optimitzar el teu site, compta amb nosaltres.

Ens encarreguem de migrar una còpia del teu lloc web producció a un entorn staging :) Comença a optimitzar ja!

A wetopi disposes de servidors de desenvolupament i migracions gratis

Resumidament, som uns techies apassionats per WordPress que hem creat Wetopi, un hosting especialitzat en WordPress, per minimitzar la fricció a la que tot professional s’enfronta en treballar i allotjar projectes WordPress.

No tens un compte a wetopi?

Prova ja – Descobriràs una manera eficient de treballar amb WordPress

Inclou servidors de desenvolupament Gratis.
No cal tarjeta de crèdit.

1 Star2 Stars3 Stars4 Stars5 Stars (10 votes, average: 4,60 out of 5)
Loading...
Desvetllem com quasi assolim el 100 a Google Audit Lighthouse
Share this post