Auditoría WPO profesional + caso práctico

En este post te ofrecemos todo lo necesario para realizar una auditoría WPO profesional: fundamentos, herramientas y trucos que te van a ayudar.

1. ¿Qué es el WPO?

WPO responde a las siglas Web Performance Optimization. En español sería algo así como Optimización de Rendimiento Web. Se trata del conjunto de acciones que podemos realizar a nivel de web y servidor, para hacer que nuestra web cargue lo más rápida posible, especialmente en dispositivos móviles.

2. ¿Por qué es importante el WPO?

Los motivos son múltiples, pero nos vamos a centrar en los más importantes:

• Ahorro: una web optimizada consume menos recursos, y eso nos va a permitir reducir costes de alojamiento web (hosting), y su correspondiente impacto en el medio ambiente.
• SEO: las Core Web Vitals de Google son una de las señales que los algoritmos tienen en cuenta a efectos de posicionamiento.
• Mejor experiencia de usuario: un mal rendimiento web supone una mala experiencia para nuestros usuarios, especialmente en dispositivos móviles con conexiones lentas. En consecuencia, una WPO va a tener impacto directo en aspectos clave como la tasa de rebote, las páginas vistas, el tiempo de permanencia en la página, y, lo más importante, en CONVERSIONES.

3. Qué debe incluir una auditoría de WPO

3.1. Análisi de situación inicial

Mediante herramientas externas y con el propio navegador, debemos tomar una foto del rendimiento actual. Es importante hacerlo con metodologías y configuraciones distintas, y pasar la auditoría no sólo a la home, sino a conjuntos de URLs que tengan patrones (por ejemplo post de blog, ficha de servicio, página de categoría o marca, etc).

3.2. Pedagogía y documentación

Es un tema extremadamente técnico, pero recomendamos incluir un apartado de documentación que permita justificar la importancia de nuestras acciones y hacer esa pedagogía con el cliente. Es crucial hacer una buena selección de fuentes, con la máxima autoridad posible (en esencial la de Google es siempre la más fiable, pues determinadas informaciones que emitan partes interesadas pueden estar viciadas)

3.3. Recomendaciones y priorizaciones

En este apartado se deben listar las posibles acciones a implementar. Pero debemos ir más allá. Una vez obtengamos el listing debemos filtrarlo y ponderarlo bajo dos principios: priorizar aquello que vaya a tener mayor impacto en el rendimiento, y con una inversión mínima de recursos.

Hasta aquí sería el apartado estricto que correspondería a una auditoría WPO: hemos tomado una foto, hemos documentado las necesidades, y hemos emitido una serie de recomendaciones. Pero normalmente el cliente nos pedirá ir más allá, bien implementando las mejoras, bien monitorizando a posteriori las implementaciones que haya podido hacer un equipo externo. En ese caso proseguiríamos con:

3.4. Testear la web

No sería la primera vez que después de una optimización WPO obtenemos una web que va rápida, pero que no va. El objetivo no es pasar un Speed Test, es cargar la web más rápido sin perder funcionalidades. En este apartado debe realizarse un QA de web muy exhaustivo, como si acabáramos de publicar la página web. Testear la web con diferentes dispositivos y navegadores, interactuar con menú y botones, enviar formularios, procesar órdenes de compra en e-commerce, etc.

Si hay recursos disponibles, recomendamos no implementar las mejoras WPO en la web que está online, en producción. El escenario ideal es trabajar en un clon de la web en un entorno de servidor igual al que tenemos, ahí hacer las pruebas y cuando todo esté bien, pasar a producción. Aunque eso, desgraciadamente, no siempre será viable.

3.5. Comparativa con situación inicial

Una vez implementada la batería de acciones, debemos desempolvar lo que nos guardamos en el punto 3.1 de análisis de situación inicial. Y con las mismas herramientas y configuraciones, mediremos las mejoras que hemos obtenido en las métricas principales. Es importante elegirlas bien y no marear al cliente con un exceso de datos: 4-5 métricas en 2-3 herramientas debería bastar.

3.6. Seguimiento experiencia usuarios (GSC, Locker…)

Las herramientas al final nos dan simulaciones de rendimiento web en supuestos determinados, desde tal lugar, tal dispositivo y navegador. Pero esos no son los usuarios reales de nuestra web, que son el destinatario final. Por ello es importante analizar la experiencia real de nuestros usuarios a través de herramientas como Google Search Console, que nos emite un maravilloso informe. También mediante Locker Studio podemos configurar un informe que mes a mes nos evalúa si cumplimos las core Web Vitals, una maravilla (ver informe CruX).

3.7. Recomendaciones de futuro

La batería de acciones fruto de la auditoría es muy importante, pero una vez cerrada debemos emitir recomendaciones para que cuando el cliente haga cambios a nivel de contenidos no envíe todo al traste. Debemos protocolizar especialmente cómo va a ser la subida de fotos y vídeos en el futuro, pues son los elementos más sensibles a nivel de carga.

4. Herramientas para tu auditoría de WPO

Es difícil hacer una selección, pues hay multitud de herramientas y todas tienen alguna característica interesante. Os ponemos aquí las que más usamos en la mayoría de proyectos, ojo no es necesaria usarlas todas en un proyecto, ni mucho menos.

4.1. Lighthouse con Chrome (f12)

Es gratis, el más fiable, y lo tienes en tu PC. Sólo tienes que abrir el navegador Chrome (preferiblemente en incógnito y sin extensiones), apretar F12, y ahí lo encontrarás. Ahí verás el rendimiento con tu propio caso, o puedes cambiar la configuración para simular los que usan las herramientas externas o el propio Google.

4.2. Page Speed

El Page Speed es la referencia de Google y muy probablemente el que consulte el cliente, así que aunque no te apasione deberá ser tu referencia. Nadie quiere que le salga en rojo, y por mucho que le expliques que no es lo más relevante, no va a colar. Por lo menos en naranja. De todos modos lo que más nos interesa realmentes cumplir con nuestros usuarios reales:

4.3. GTMetrix

Herramienta muy completa, para muchos más útil y fiable que la de Google. GTMetrix además de darnos una puntuación y colorines, nos da información interesante sobre el Waterfall y algunos tips que harías bien en atender.

4.4. Web Page Test

Esta es una interesante alternativa a las herramientas anteriores. Web Page Test además de un speed test general, configurable con varios países, conexiones y dispositivos, ofrece un interesante report de Core Web Vitals, y uno al cual le vemos mucho futuro para controlar la emisión de carbono de nuestro sitio.

4.5. Dot Com Tools

Este analizador de WPO es especialmente interesante para proyectos internacionales. El Dot Com Tools te da una auditoría de rendimiento de forma simultánea desde distintos puntos del planeta, y es el principal aliado de la contratación de un CDN como Dios manda.

4.6. Built With

Esta y otras herramientas nos pueden ser útiles para conocer las entrañas de la web. Built With nos da información sobre el CMS utilizado, el servidor que aloja el sitio web, los componentes de front y back que tenemos, etc. Nos permite hacernos una idea del ecosistema interno y el márgen de mejoras que vamos a poder aplicar.

4.7. Wappalizer

Cumple prácticamente las mismas funcionalidades que la herramienta interior, pero en este caso como extensión de Chrome.

4.8. Request Map

Esta tool tiene utilidad para ver de forma gráfica cómo se realizan las peticiones externas, algo que siempre es un dolor de cabeza importante. Probar Request Map

5. Las tripas de la auditoría WPO

La auditoría WPO tiene dos universos de análisis: por un lado el entorno de servidor, y por el otro el de la propia web. Te aconsejamos empezar por servidores, pero no es imprescindible.

5.1 Auditoría de Servidor

A nivel de Servidor debemos analizar:

• Protocolo https + versión de TLS
• Tipo de servidor
• Versión PHP
• Protocolo http (1.1, 2 o 3)
• Bases de datos (MariaDB, MYSQL)
• Almacenamiento (SSD)
• TTFB (no siempre es 100% por server)
  
  

Protocolo https + versión de TLS

Mediante chrome DEV, podemos obtener una serie de información básica sobre seguridad:


Aquí debemos comprobar:

1. Que tengamos un Certificado SSL, que este sea válido y de confianza, y que no esté caducado
2. Conexión (TLS, QUIC). A priori mejor el segundo para proyectos complejos. En el ejemplo que véis usamos TLS1.2, así que una mejora a proponer sería pasar a TLS 1.3, pues mover a QUIC sería una quimera. Conoce más sobre las diferencias entre TLS 1.2 vs 1.3
3. Asegurarnos que los recursos se cargan de forma segura
   
   

Tipo de servidor

Hay muchos tipos de servidores, aunque los más comunes son Apache y Nginx y LiteSpeed.

Podemos comprobar el nuestro con la extensión Wappalyzer por ejemplo:


En nuestro caso de ejemplo es un Apache. En ocasiones no se ve con Wappalyzer, una alternativa sería la extensión de Chrome Web Developer.

Versión de PHP

Nos interesa también conocer la versión de PHP que estamos usando. Es algo que normalmente es imposible de saber si no tenemos acceso al hosting y código, aunque en ocasiones es visible desde la respuesta de cabecera en la herramienta de inspección e URLs de GSC. En nuestro caso no es así, de modo que hemos consultado a nuestro proveedor de hosting.

Cuanto más moderna sea la versión de PHP, mejor. Especialmente si podemos pasar a las versiones 8, pues todas las peticiones se procesan mucho más rápido (ver comparativa de versiones PHP). Sin embargo debes tener en cuenta que no se puede subir la versión de PHP a las bravas, pues puede ser incompatible con el código de la web, y quedarte sin página en unos segundos. De modo que primero debes asegurarte que el código ya es apto o se ha adaptado a ese cambio, y ten en cuenta que algunos proyectos, por su edad o cómo están construidos, no van a soportar una subida importante en el PHP sin reventar.

Procolo HTTP

Existen varios protocolos y estos influyen mucho en la capacidad de procesar paquetes de datos de forma simultánea (ver comparativa Protocolo HTTP1 VS 2 VS 3). Cuanto más avanzada sea la conexión, más paquetes de datos van a procesar de forma paralela.

Conocido esto, vamos a ver qué conexión usa nuestra web. Para ello podemos usar Chrome => herramienta desarrolladores => red => botón derecho => protocolo



En el caso que nos ocupa observamos cómo se entrega contenido mayoritariamente en h3, pero también aparecen elementos en h2. En estos caso debes fijarte en si esos elementos se sirven internamente desde nuestra web, o bien son externos. En el segundo caso no tenemos margen de mejora, obviamente. En cualquier caso es importante que ya no se envíe nada por HTTP1, y cuanto más HTTP3 podamos servir, mucho mejor.

Bases de datos

Todas las webs necesitan una base de datos para almacenar los contenidos y registros, y un buen almacenamiento y procesamiento de la información agiliza las peticiones, y en consecuencia, en rendimiento de la web. Los sistemas más comunes son MySQL y MariaDB. A priori es mejor Maria DB, sobre todo para procesar bases de datos grandes (ver comparativa MySQL vs MariaDB). Conocer el tipo de bases de datos de un proyecto es complicado por fuera, debes consultar en tu panel de hosting o preguntarlo a tu proveedor.

Tecnología de almacenamiento

Nuestra web se almacena en discos duros, y la calidad y capacidad de estos resulta clave. Los sistemas más comunes son el HDD vs SSD. La velocidad de escritura, borrado y peticiones es abismal. Si todavía no usas SSD, es algo muy interesante a valorar. Nuevamente es una información que debes consultar en tu panel de hosting.

TTFB

Mide la duración desde una petición de contenido a web, hasta que recibe el primer paquete de datos. El tiempo de respuesta conocido comúnmente.

Se puede analizar con varias herramientas, en este caso una buena opción es Speed Vitals.



Esta herramienta es muy intuitiva, rápida, y te da el TTFB desde varios países. El ejemplo que ves es clarísimo, cumple el TTFB desde Madrid pero no desde el extranjero. Ahí entra la valoración de negocio: si se trata de una web y negocio de orientación local o estatal, no hay problema. En cambio si tiene objetivo de captar usuarios y/o clientes de varios países, sería un punto clave a mejorar.

Una alternativa interesante, y en local, es usar Chrome Dev pero debes ir con mucho cuidado, pues deberías configurar la red y dispositivos que usa Google para su Speed Test, pues tu red seguramente procesa más rápido.

GTmetrix también sería una opción muy válida, aunque que sus análisis sean desde Canadá a menudo pueden desvirtuar las cifras:




Con esta y otras métricas veréis que según la herramienta escogida los valores son distintos. Por ello es importante irse familiarizando con ellas, y siempre que hagamos comparaciones usar la misma herramienta y configuración.

Medidas a tomar sobre servidores

Todos los puntos antes mencionados deben analizarse. Ahora bien, en algunos casos si ya tenemos una opción correcta, quizá no interese cambiar a la perfecta si los recursos y riesgos no compensan. Es especialmente recomendable actualizar la versión de PHP si es posible, pero por ejemplo un cambio de tecnología de base de datos normalmente no va a compensar, pues por una pequeña mejora de rendimiento nos requerirá mucho desarrollo y costes.

Afrontar un cambio de hosting siempre es algo laborioso y delicado. Si la valoración inicial no es desastrosa, explora las opciones para sacarle más jugo al hosting actual. Y sólo si eso no es viable, afronta la migración hacia otro hosting.

En el segundo bloque, a nivel de proyecto web debemos analizar:

• Número de peticiones por tipología de página (páginas, posts, tag…)
• Recursos internos (CSS; JS, IMG, PDFs…)
• Complejidad DOM
• Complejidad CSS y JS
• Fuentes utilizadas (3 o 4 deberían bastar, muchas webs tienen más fuentes de las que utilizan)
• Caché
• CDN

En este apartado vamos a ver aspectos de configuración de nuestra web que estén impactando en el rendimiento y tengan margen de mejora.

Vamos a pasar una herramienta, la que más nos guste, y nos va a arrojar algunas recomendaciones.

En el caso de que uses un CMS como Wordpress o Prestashop, ahí nuestra recomendación es que antes de afrontar esto, hagas una auditoría de plugins/módulos. Debes hacer lo siguiente:

• Los plugins que no se estén usando, elimínalos. No basta con desactivarlos, hay que eliminarlos del todo. Google en su propio test ya nos avisa de eso:
  
• Todos los plugins activos deberían estar actualizados, pues afectarán a muchos aspectos, entre ellos el rendimiento. No hace falta decir que para poder actualizarlos necesitaremos licencias, y mejor no racanear con esto. Esto también aplica al tema, en caso de usar uno
• Optimizamos todos los plugins que tenemos. En el caso de WPO, deberás elegir aquellos que más te gusten para optimizar aspectos de compresión, renderizado, etc. Ahí cada maestrillo tiene su librillo: WP Rocket es una buena opción pero no la única, testea.
• Optimización de fuentes: para ahorrar en llamadas externas, es importante cargar internamente las fuentes, y hacerlo desde fuentes externas como Google Font. Si usas Wordpress, hay plugins como OMGF que pueden ayudarte

Pasamos entonces un nuevo Page Speed. Algunos de los errores más habituales que te vas a encontrar son:

• Imágenes demasiado grandes: en esos casos debes comprimirlas al tamaño mínimo viable, sin que afecte a una visualización óptima del contenido del sitio. Este proceso se puede hacer de forma manual, pero lo mejor es hacerlo masivamente mediante scripts o en el caso de Wordpress, con algún plugin tipo Imagify. Debes tener en cuenta que se deben optimizar las imágenes actuales del sitio, pero debes prever qué pasará con las futuras (necesitarás rutinas o indicaciones estrictas a los que suban contenido para la subida de fotos nuevas).

       

• Usa formatos de imagen de nueva generación: aquí la clave es entregar las imágenes en formato WebP esencialmente, que es formato que Google pide, pero manteniendo las versiones originales JPG o similar.
  
• Elimina los recursos que bloqueen el renderizado: Aquí lo que es imprescindible es cargar de entrada los JS y CSS que vamos a necesitar para un primer visualizado de contenido de la página en su parte superior, mientras que el resto los podemos cargar a posteriori (defer, async).

       

• Pospón la carga de imágenes que no aparecen en pantalla: lo mismo que hemos hecho con los archivos JS y CSS debe aplicarse a las imágenes. De esta manera, conforme el usuario vaya haciendo scroll, se cargarán las imágenes, en vez de cargar todas de primeras.
  
• Reducir el tiempo de respuesta del servidor: este mensaje debería desaparecer si hemos atendido al anterior apartado del artículo, donde se afrontaban los ajustes de servidor. Si esto no está resuelto bien, poco importa luego el resto de acciones que tomemos.

       

Test en real:

6. Resumen y reflexiones finales

No te obsesiones con la nota del Page Speed Insights. Piensa que es un test muy extremo, por el dispositivo y red usados. En ocasiones un proyecto no va a poderse poner en verde por sus características, se trata de sacarle el máximo jugo aportando recursos razonables. Fíjate especialmente en si cumplimos con los estándares que pide Google en las métricas principales de las Core Web Vitals.

A nivel de servidor, ya hemos comentado que un cambio drástico no es sencillo, y en ocasiones va a ser imposible. Considera por lo menos la posibilidad de actualizar la versión de PHP, y para proyectos nuevos o migraciones, entonces sí, plantea un escenario de máximos.

En cambio a nivel de proyecto web, las optimizaciones más importantes son todas las que tienen que ver con imágenes (compresión, usar el tamaño que necesites, usar formatos de nueva generación como WebP), así como todo lo que tiene que ver con el procesamiento de JS y CSS (compresión, cargas internas/externas, cargas diferidas y asíncronas).

Usa Google Search Console y el informe CruX en Locker Studio para hacer seguimiento del rendimiento que experimentan los usuarios reales de tu página web. Debes ponderar los esfuerzos con el tipo de usuarios reales que tu proyecto tiene (países, dispositivos, etc), o los que desea tener en el futuro.