google-audit.jpg

Desvelamos cómo casi alcanzamos el 100 en auditoría Google Lighthouse

Los desarrolladores y diseñadores web nos esforzamos por mejorar la accesibilidad, usabilidad y SEO de nuestros sitios web.

Estamos evolucionando en métodos y técnicas para mejorar nuestro contenido, semántica y código. Añadimos plugins de caché y buscamos alojamiento en servidores con mejor rendimiento. Pero también compartimos una frustración y es que no hay un único baremo ni herramienta con la que analizar y tener claro el impacto de nuestro esfuerzo.

Ahora, gracias a Google Audit Score, Lighthouse, podemos tener una idea global de cómo se comporta nuestro sitio web bajo distintos aspectos: rendimiento, accesibilidad, seo, … y no menos importante todo ello bajo la óptica de Google.

Lighthouse es una herramienta de auditoría de páginas web de código abierto desarrollada por Google. Está disponible en las herramientas de desarrollador de Chrome, en forma de extensión de Chrome y como módulo que podemos ejecutar con Nodejs.

Lighthouse realiza auditorías en algunas áreas clave como: Rendimiento, Accesibilidad, Buenas prácticas y Aplicaciones Web Progresivas. Persigue en todas las áreas el acercarse al máximo a la experiencia de usuario final y los problemas que pueda tener para visualizar una determinada página de nuestro sitio web.

Google Lighthouse audita la página web y la clasifica de 0 a 100. Una «Buena experiencia del usuario final» está por encima de 80 y una «Mala experiencia» cuando nos situemos por debajo de este 80.

En wetopi.com nos esforzamos continuamente en mejorar nuestros servicios, la velocidad de nuestros servidores y la accesibilidad de nuestro sitio web. Así que mejor empezar por nuestra propia web.

En este artículo, reproduciremos los pasos llevados a cabo para mejorar la puntuación de nuestra página Home en Google Lighthouse. Empezamos con bajas expectativas. Tengamos en cuenta que nuestra web ya tiene unos años y la desarrollamos, sin pensarlo mucho, con un tema muy recargado de funcionalidades. Pero ante nuestra sorpresa el resultado final ha sido espectacular.

Este es nuestro viaje

Empezamos con este pobre resultado:

Un mal resultado inicial en Google Lighthouse

Para gloriosamente casi rozar el pleno de 100 en las puntuaciones de Lighthouse !!!

¿Cómo lo hicimos?

Un detalle antes de empezar,

Éste era la primera vez que nos enfrentábamos a la tarea de mejorar los resultados en Lighthouse por lo que no teníamos una idea clara del esfuerzo ni resultados que podíamos obtener. Tomamos el camino directo y empezamos a trabajar sin pensar en ir tomando notas para un posterior artículo.

Como el resultado ha sido muy bueno hemos decidido repetir el proceso para escribir este post.

Para empezar restauraremos una copia backup en un servidor de «staging» para no poner en riesgo el trabajo ya realizado en nuestro servidor producción.

En wetopi, desplegar un backup es un simple clic. En este enlace podéis ver lo simple que resulta desplegar un backup.

we restore a backup to reproduce the  Increase Score process
Panel de nuestro sitio web donde tenemos corriendo los dos servidores: producción y el backup-restore con el que trabajaremos.

El proceso

Lanzaremos a cada paso la Auditoria de Google Lighthouse siempre manteniendo las mismas opciones. En nuestro caso las que vienen por defecto y que simulan un usuario en un Móvil en red 3G:

optimizing score with Google audit with default options

Empecemos!

¿Cómo accedemos a Lighthouse?

En el navegador Chrome, hacemos clic con el botón derecho en la página web. Al seleccionar Inspeccionar, aparecerá una barra a un lado o debajo, dependiendo de la configuración.

En la barra superior donde se ven los elementos, consola, elegimos Auditorías. Y justo al final tenemos la opción para ejecutar la batería de pruebas:

Panel de Lighthouse

Cuando ejecutamos la auditoría, Google Lighthouse va mostrando actividad, y al terminar el test nos da el resultado junto a una lista de oportunidades ordenadas por «Ahorros» estimados en segundos. 

Abordamos el primer punto del primer bloque de oportunidades:

Defer unused css

En otras palabras: deja para más tarde (o elimina) los estilos que no uses.

Defer unused css es la primer opción para Optimizar el resultado

El punto 1 nos indica que estamos cargando un enorme archivo CSS. 

Éste es el precio a pagar cuando se usa un tema de WordPress poco optimizado y con gran cantidad de opciones. Tomamos la decisión de sustituir los CSS del tema por una copia algo más limpia que añadiremos desde nuestro tema hijo.

El primer paso: movemos una copia de style.css a nuestro tema hijo.

Luego es preciso indicarle a WordPress que no use el estilo original sino el el que hemos copiado a nuestro tema hijo. Al estar ya usando un tema hijo, solo tenemos que editar el archivo functions.php que ya teníamos.

A continuación se muestra el código para retirar la hoja de estilos del tema con «dequeue» e incorporar nuestra versión depurada con 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);

Esta tarea de «depuración» requiere mucho tiempo. Realizamos varias iteraciones probando que no rompíamos nada. Nos encontramos grandes bloques como el de Woo-commerce, «Sliders» y galerías que teníamos claro que no utilizábamos.

Al final terminamos reduciendo nuestro style.css a la mitad de su tamaño original. 

Para ayudarnos a identificar bloques de código CSS innecesarios, utilizamos la herramienta de desarrolladores de Chrome Coverage

El resultado fue un salto de 54 a 66 en la sección Rendimiento:

Performance audit con un resultado pobre de 66

Continuamos con el siguiente punto:

Defer offscreen images

Este punto nos presenta la oportunidad de reducir el tiempo de carga en 1.05 segundos!

Defer offscreen images

Google ha hecho un buen trabajo y en cada apartado tenemos un «Learn more».

Las imágenes fuera de la pantalla son imágenes que aparecen below the fold (por debajo del primer tramo de ventana del navegador). Dado que los usuarios no pueden ver imágenes fuera de la pantalla cuando cargan una página, no hay razón para descargar las imágenes fuera de la pantalla como parte de la carga de la página inicial.

Después de algunas investigaciones buscando el plugin más rápido y ligero para resolver este problema, nos decantamos por probar con Lazy Load de WP Rocket.

Lazy Load Actualmente está activo en más de 20,000 instalaciones con una calificación de 4 de 5 estrellas. La gran ventaja de este plugin es que pesa menos de 10 KB. No hay opciones para configurar, simplemente se instala, se activa y la carga diferida simplemente pasa a funcionar.

NOTA: después de la instalación de Lazy Load, hay que ir a la configuración de administración de WordPress y activar la opción de Carga de Imágenes diferida.

Con uso de Lazy Load saltamos de 66 a 70 en la auditoria de Performance/Rendimiento.

Preconnect:

El establecimiento de conexiones a menudo implica un tiempo considerable en redes lentas, especialmente cuando se trata de conexiones seguras. Eso ocurre debido a que suele ser necesario realizar consultas de DNS, resolver redirecciones, etc. Y eso conlleva varios viajes de ida y vuelta al servidor final que maneja la solicitud del usuario. 

El concepto de «Preconnect» consiste en informar al navegador de nuestra intención para que pueda anticiparse. La solución es tan simple como agregar una etiqueta en la cabecera de nuestra página indicando los dominios externos que utilizaremos.

Para añadir a la cabecera <head> los encabezados preconnect, tenemos que editar el archivo header.php en nuestro directorio de tema hijo:

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

Eliminando recursos»render-blocking»:

Se trata de eliminar los recursos que bloquean el pintado de la página. Ésta optimización junto a la anterior van alternándose conforme avanzamos en la optimización. Ahora nos enfrentamos a reducir o si es posible eliminar parte de nuestro javascript.

Retiramos los vídeos y su javascript:

Una importante decisión que tomamos fue la de retirar los vídeos que incrustábamos usando el servicio externo Wistia. Nos dimos cuenta con la auditoría que los CSS y los javascript de Wistia estaban bloqueando la ejecución del pintado. Otro detalle es que las carátulas de vídeo servidas no estaban del todo optimizadas.

Reemplazamos los videos incrustados con infográficos en formato svg.

La siguiente limpieza que realizamos fue deshacernos de jquerymigrate (la consola de Chrome nos dió la pista al mostrar «JQMIGRATE: Migrate is installed, version 1.4.1″)

jQuery Migrate simplifica el proceso de migrar y compatibilizar el código jQuery antiguo para que funcione con las versiones más nuevas de jQuery. En nuestro caso no debería ser necesario, pues estamos usando plugins y temas actualizados. Probemos pues nuestro site sin jquery migrate.

Eliminando jquery migrate:

Volvemos a nuestro archivo functions.php para 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' );

Este fragmento de código, actua cuando no está en wp-admin comprobando si registramos jquery. Si es así elimina jquery-migrate de la matriz de dependencias.

Al terminar, siempre tenemos que validar que todos las funcionalidades y rincones de nuestro sitio siguen funcionando como siempre. En nuestro caso todo funciona correctamente.

Y una nueva ejecución de Audit Lighthouse nos dio nuestra primera puntuación «verde» con un 89 en la sección rendimiento:

Eliminando los vídeos y jquery migrate incrementamos el rendimiento a 89

Google fonts desde nuestro server y ajustes del font-display:

Continuando con nuestra tarea de reducir el bloqueo, la auditoría de Google nos sugiere que configuremos «font-display» para reducir el tiempo de bloqueo.

El nuevo atributo «font-display» para los bloques @font-face nos permite a los desarrolladores decidir que hacer con el render durante el periodo en el que estamos cargando las fuentes. La idea es no bloquear el proceso de pintado por lo que la opcion «fallback» es ideal. Con «fallback» mientras se cargan las fuentes el pintado avanza usando fuentes de sistema. Luego, tan pronto están cargadas las fuentes, el navegador las reemplaza.

Otra gran mejora es servir las Google fonts desde nuestro servidor. Nuestros servidores wetopi tienen un rendimiento óptimo y están configurados para sacar el máximo partido de los sistemas de compresión y caché.

Nuestro tema nos permite desactivar el uso de fuentes Google desde el mismo panel de administración WordPress.

Atención al intentar conseguir una copia de las fuentes, vimos que Google fonts site no proporciona todos los formatos necesarios para dar cobertura a distintos navegadores. Necesitamos por lo menos: woff y woff2.

Por suerte encontramos este fantástico proyecto online: http://google-webfonts-helper que se definen perfectamente: A Hassle-Free Way to Self-Host Google Fonts. @majodev Muchas gracias por compartir.

Así es como pasamos a servir nuestras fuentes 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 las fuentes de google desde wetopi nos permitió incrementar el rendimiento
servir las fuentes google nos permitió incrementar el rendimiento

Introduciendo Cache y conexión segura https

En esta etapa de mejora de rendimiento, habilitamos el plugin de caché WP Super Cache y pasamos a usar HTTP/2 para servir páginas con https.

El único inconveniente es que HTTP/2 requiere una conexión segura. Esto significa agregar más tiempo para tratar con https y certificados seguros.

Al trabajar con https es importante usar un hosting que sirva las páginas con protocolos TLS de última generación. Las últimas versiones TLS1.2 y TLS1.3 significan una importante reducción en los tiempos de negociación de la conexión segura.

En nuestro caso, esta optimización no implica ningún esfuerzo. Los servidores en wetopi ya están perfectamente ajustados y con los más modernos protocolos para servir HTTP/2.

HTTPS increase Google Audit Performance

El resultado empieza a darnos alegrías.

Mejoramos en «Performance» Rendimiento y también en «Best Practices» Buenas Prácticas. 

Llegados a este punto las oportunidades van reduciéndose:

El primer punto todavía apunta al CSS y javascript. Decidimos dedicar más tiempo a encontrar más estilos no utilizados para reducir el tamaño. Mientras trabajábamos en la limpieza, descubrimos que estábamos cargando el código javascript de plugins que no se requerían en la página de inicio.

Si queremos ser «selectivos» en el «cómo» y «cuándo» cargar los recursos de cada plugin, podemos tomar dos direcciones:

  1. Usar un plugin capaz de tomar el control de la carga de los javascript y CSS, por ejemplo: W3 Total Cache. Con este plugin podemos extraer una relación de archivos y determinar cómo cargarlos, dónde y en que orden. Con este plugin también podemos usar las técnicas de «defer» y «prefetch».
  2. Cargar los plugins de forma selectiva allí donde se necesiten.

Apostamos por la última opción. Sin embargo, hay un inconveniente y es que si somos agresivos en las combinaciones de plugins podemos cargarnos las ventajas del propio sistema de caché del navegador. El problema se da cuando tenemos muchas combinaciones de CSS y las servimos concatenadas y minimizadas. El navegador verá un archivo de CSS distinto al ir cambiando de página.

Organizar los plugins en dos grupos es nuestra aproximación: una combinación de plugins para las páginas web corporativas y una segunda combinación para los blog posts.

Decidimos usar «plugin load filter» para implementar la separación de plugins. Éste permite activar/desactivar plugins dependiendo de un montón de criterios. Intentemos no excedernos si más tarde pretendemos juntarlos!

De forma resumida, el plugin te da una página de configuración con 2 pestañas. En la pestaña «Registro de filtro», decidimos los plugins que deseamos controlar según «Tipo de página». En la segunda pestaña «Activación de filtros de página» es donde repartimos el uso de plugins dependiendo de si es un «Página» o un «Post»:

Plugin load filter nos permite mejorar el resultado en Google Lighthoouse audit

Esto ha reducido el tamaño de nuestro javascript principal, lo que nos empuja hasta el fantástico resultado de 97, reduciendo el tiempo de «pintado» a 1.6 segundos en redes 3G:

97 in performance and First Content Paint of 1.6 secs

Estamos satisfechos con los resultados obtenidos en la sección rendimiento por lo que avanzamos a la siguiente sección de la Auditoría de Lighthouse.

Mejorando los resultados en Progressive Web App

Las aplicaciones web progresivas (PWA, por sus siglas en inglés) son aplicaciones web que se cargan como páginas web o sitios web normales, pero que pueden ofrecer al usuario funcionalidades como trabajar sin conexión, enviar notificaciones, …https://en.wikipedia.org/wiki/Progressive_web_applications

No todas las páginas web necesiten funcionalidades PWA. En nuestro caso, la posibilidad de navegar sin conexión nos pareció interesante. Nuestros clientes suelen ir a nuestra página web para hacer clic en el botón de Login y poder entrar al panel de gestión. Si nuestra web cae o está en mantenimiento, los usuarios perderían ese camino. Merece la pena intentar agregar esta funcionalidad PWA.

El ecosistema de plugins de WordPress es como el bolsillo de Doraemon: siempre encontramos un plugin con el que resolver el problema. 

En esta ocasión encontramos SuperPWA.

Este plugin es impresionante. Lo instalamos y configuramos simplemente cargando los iconos de nuestra aplicación, y en menos de una hora, nuestro PWA estaba en funcionamiento.

El panel de configuración de Super PWA no es nada complejo.

El resultado de la Auditoria arrojó un impresionante 100!

Gracias al equipo de Super PWA por crear este increíble plugin y ponerlo a disposición de la comunidad de WordPress.

Alcanzado este punto estábamos en Verde y muy cerca del 100 en todas las secciones. Solo quedaba por resolver aspectos de accesibilidad y SEO. En nuestro caso las mejoras fueron bastante sencillas: imágenes sin descripciones en la etiqueta «alt», botones sin descriptivos accesibles,…

We achieved almost 100% in Google Lighthouse audit

Estamos satisfechos con el resultado. Es un buen equilibrio entre tiempo invertido y resultados Google Lighthouse. Mover la puntuación de Accesibilidad y «Best Practices» hasta los 100 en nuestro caso significaría un cambio en el diseño y tema.

Bonus Extra

Aquí hay algunas sugerencias de carácter genérico que es bueno tengamos siempre presentes.

Reduzcamos la cantidad de plugins.

Añadir plugins, la mayoría de las veces, significa incrementar el tiempo de proceso tanto de nuestro servidor como de nuestro navegador. Es decir añadir plugins es darle más trabajo a nuestro servidor y a los navegadores de nuestros usuarios.

No instalemos plugins si no es estrictamente necesario.

Hay plugins con un fuerte impacto en «front-end» lado-usuario. Añaden hojas de estilo y javascript que raramente usamos al 100%. Y mucho menos en todas y cada una de nuestras páginas web.

Usemos temas ligeros.

En el próximo “refactoring” de nuestra web, prestaremos especial atención a la selección del tema. El tema es una pieza crucial en todo sitio WordPress, es la base sobre la que construimos y no debemos dejarnos impresionar por su aspecto y cantidad de funcionalidades. Busquemos temas ligeros de calidad contrastada.

Esperamos haber podido contribuir a hacer algo más entendible el proceso de optimización de un sitio web usando Google Lighthouse :)

Si estás pensando en optimizar tu site, cuenta con nosotros.

Nos encargamos de migrar una copia de tu sitio web producción para que no se rompa nada :) ¡Empieza a optimizar ya!

En wetopi dispones de servidores de desarrollo y migraciones gratis!

En resumidas cuentas, somos unos techies apasionados por WordPress que hemos creado Wetopi, un hosting especializado en WordPress, para minimizar la fricción a la que todo profesional se enfrenta al trabajar y alojar proyectos WordPress.

¿No tienes una cuenta en wetopi?

Prueba gratis – Descubrirás una manera eficiente de trabajar con WordPress

Incluye servidores desarrollo Gratis.
Sin tarjeta de crédito.

1 Star2 Stars3 Stars4 Stars5 Stars (17 votes, average: 4,24 out of 5)
Cargando…
Desvelamos cómo casi alcanzamos el 100 en auditoría Google Lighthouse
Share this post