Proponemos un framework de trabajo para poder conseguir mejoras continuas a nivel de velocidad.

1. THE WPO
ACADEMY

2. ¿Porque es importante la velocidad a nivel SEO?

3. ¿Porque es importante la velocidad a nivel usuario?

4. ¿Porque es importante la velocidad a nivel negocio?
Fuente: https://web.dev/why-speed-matters/

5. ¿Cómo se ha medido la velocidad en seo durante tiempo?
Desconexión SEO/Producto/Usuarios

6. Mitos sobre el performance

7. Mitos sobre el performance
La experiencia de usuario se puede capturar con una sola métrica
La buena experiencia de usuario no se puede capturar en un solo punto en el tiempo.
Se compone de varios touchpoints en el user journey.
Hay que saber que métricas influyen y medir las que son importantes.

8. Mitos sobre el perfomance
La experiencia de usuario puede ser testeada contra un solo “usuario representativo”
La Perfomance de los sites depende de muchos factores tales como el dispositivo utilizado, las
conexiones de red y otros factores. Hay que definir una serie de escenarios que sean representativos
de nuestros usuarios con más porcentaje sobre el total y que tenga en cuenta los parámetros mediante
los que se conectan.

9. Mitos sobre el perfomance
Si a mí me carga rápida, a mis usuarios también
Muchas veces usamos dispositivos y redes para realizar los tests de Perfomance que son más
rápidos y mejores que los de nuestros usuarios.
Hay que tener en cuenta las características reales de uso de nuestro site y testear contra
eso en nuestras métricas.

10. Datos de laboratorio vs datos de campo

11. Datos de Perfomance recogidos en un entorno controlado con
ajustes de redes y dispositivos predefinidos.
Ofrecen resultados reproducibles y permiten debugar para
identificar y corregir problemas de perfomance.
Fortalezas
Permiten solucionar problemas de perfomance
Visión completa del problema y foco en la UX
Crea un entorno de testeo reproducible
Limitaciones
Puede que no tenga en cuenta problemas reales que están
ocurriendo
No se puede correlacionar contra KPI´s del mundo real
Datos de laboratorio

12. También llamados Datos Reales de Usuarios (RUM)
Son datos de performance recogidos de cargas reales de
páginas de nuestros usuarios en nuestro site.
Fortalezas
Capturan la experiencia real de los usuarios
Pueden correlacionarse con KPI´s de negocio
Limitaciones
Cantidad de datos restringido
Opciones de reproducir las condiciones son limitadas
Datos de campo

13. Lighthouse
Consejos personalizados para mejorar Perfomance, accesibilidad, PWA, SEO y otras best practices.
WebPageTest
Permite analizarperformance de un site en un entorno controlado y profundizar en algunas métricas.
TestMySite
Diagnostica la Performancey provee algunos fixes basados en Webpagetest and PageSpeedInsights.
PageSpeed Insights
Muestra datos de performancede campo de tu site y sugerencias de como mejorarla.
Speed Scorecard
Permite comparartu site mobile contra otros. Utiliza datos de campo del Chrome UX Report.
Impact Calculator
Permite estimar el ingreso adicional proveniente de la mejora de Perfomance. Se basa en los datos de banchmark de GA.
Chrome Developer Tools
Permite perfilar el tiempo de carga de una página y debugar los problemas de performance.
Distintas herramientas de performance by Google

14. Benchmark de velocidad: Speed Scorecard y TestMysite
Coste Oportunidad Económico: Impact Calculator
Análisis impacto real de una tarea técnica en la Perfomance: Consola Chrome
Distintos casos de uso de las herramientas de performance

15. Análisis impacto real de una tarea técnica en la Perfomance

16. Análisis impacto real de una tarea técnica en la Perfomance

17. Análisis impacto real de una tarea técnica en la Perfomance

18. ¿La performance depende de la percepción?

19. He probado nuestra web y se carga en X,XX segundos.
La carga no es un solo momento en el tiempo; es una experiencia que ninguna métrica puede capturar por
completo. Así que, en lugar de medir la carga con una sola métrica, debemos medir los tiempos de cada
momento a lo largo de la experiencia que pueden afectar la percepción de carga de los usuarios.
La performance depende de la percepción

20. Métricas de Performance que responden a la realidad de los usuarios
El propósito de la página nos ayuda a determinar la
métrica importante para nosotros!

21. Primer procesamiento de imagen (FP) y primer procesamiento de imagen con contenido (FCP)
La API Paint Timing define dos métricas: primer procesamiento de imagen (FP) y primer procesamiento de imagen
con contenido (FCP). Estas métricas indican los puntos, inmediatamente después de la navegación, cuando el
navegador representa los píxeles en la pantalla. Es importante para el usuario, ya que responde a la pregunta:
¿está sucediendo?
FP indica el punto cuando el navegador representa cualquier elemento visualmente diferente de lo que estaba en la
pantalla antes de la navegación.
FCP es el punto cuando el navegador representa el primer bit de contenido desde el DOM, lo que puede ser texto,
una imagen, SVG o, incluso, un elemento <canvas>.
Métricas de Perfomance que responden a la realidad de los usuarios
FP & FCP

22. Métricas de Perfomance que responden a la realidad de los usuarios
FMP & HERO
Los elementos Hero responden al propósito de la página y son la parte meaningful del contenido.
Casi siempre, las páginas web tienen partes más importantes que otras. Si las partes más importantes de una página se
cargan de forma rápida, es posible que el usuario ni siquiera note que el resto de la página no se carga.

23. Tiempo hasta que es interactiva
La métrica Tiempo hasta que es interactiva (TTI) indica el punto en el que la aplicación se
representa visualmente y es capaz de responder de forma confiable a una entrada del usuario. Es
posible que una aplicación no pueda responder a una entrada del usuario por diversos motivos:
•Todavía no se cargó el JavaScript necesario para que los componentes en la página funcionen.
•Existen tareas largas que bloquean el subproceso principal (como se describe en la última sección).
La métrica TTI identifica el punto en el que se carga el JavaScript inicial de la página y se inactiva el
subproceso principal (sin tareas largas).
Métricas de Perfomance que responden a la realidad de los usuarios
TTI

24. Tareas largas (Ausencia de)
Los navegadores agregan tareas a una cola en el subproceso principal para ejecutarlas una por una. En algunos casos,
estas tareas pueden demorar más tiempo en ejecutarse y, si eso sucede, el subproceso principal se bloquea y el resto
de las tareas en la cola deben esperar.
La API Long Tasks identifica las tareas de más de 50 ms de duración como potencialmente problemáticas y las expone al desarrollador de
aplicaciones. Se seleccionó la duración de 50 ms para que las aplicacionescumplancon las pautas de RAIL de responder a una entrada del
usuario en 100 ms.
Métricas de Performance que responden a la realidad de los usuarios

25. Optimización de la ruta de acceso de representación crítica
¿Cómo optimizar estas métricas?
Optimización del ahorro del contenido

26. Evolución bytes descargados en la Web 2013-14
Optimización del ahorro del contenido
Diferentes cuantiles dentro de la distribución: 50 (promedio), 75 y 90

27. Optimización del ahorro del contenido
Eliminación de descargas innecesarias
Optimizar encoding y tamaño de transferencia de activos
Optimización de imágenes
Automatizar la optimización de imágenes
Reemplazar GIFs animados por videos
Optimización de arranque de Javascript
Carga de JS de terceros
Optimización Web Fonts
Almacenamiento de caché en HTTP
Uso de los Client Hints
Uso del header Save-Data

28. Eliminación de descargas innecesarias
Análisis e inventario de los recursos propios y de terceros
(p.e.script testing) ¿Podemos calcular su valor? ¿Cuándo se
usan?
Mide el rendimiento de cada recurso. ¿Se encuentra, o debe
encontrarse en la ruta de acceso crítica? Si el recurso no está
disponible, ¿afectará el rendimiento y la experiencia del
usuario en tus páginas?
¿Sigue este recurso las prácticas recomendadas de
rendimiento (compresión, almacenamiento en caché, etc.)?
Los recursos más rápidos y más optimizados son aquellos que no se envían.
Foco en el análisis individual

29. Optimizar encoding y tamaño de transferencia de activos
Aplicar optimizacionesespecíficas por contenido: minificadores CSS, JS y HTML.
Aplicar GZIP para comprimir el resultado minificado.

30. Optimización de imágenes
Quick Wins
Eliminar recursos de imageninnecesarios (EXIF)
Aprovechar los efectos CSS3 cuando seaposible
Usar fuentes web en lugar de codificar texto en las imágenes
Las imágenes siguen siendo la causa número uno de los archivos de tamaño excesivo en la Web.
Según HTTP Archive, el 60% de los datos transferidos para obtener una página web son imágenes
compuestas de archivos JPEG, PNG y GIF.
¿Existe el equilibrio?

31. Automatizar la optimización de imágenes
JPEG – JPEG Progresivo – Codificadores JPEG – MOZJPEG – GUETZLI – BUTTERAUGLI – WEBP – Optimización de SVG
¡Automatización es solución eficaz!
Las prácticas recomendadas cambian y el contenido que no pasa por una canalización de compilación puede omitirse fácilmente.
Compilación: imagemin o libvps
La mayoría de los CDN (p.ej., Akamai) y soluciones de terceros como Cloudinary, imgix, Image Optimizer de Fastly, SmartVision de Instart
Logic o la API ImageOptim ofrecen una optimización de imágenes automatizada.
Es más baratos pagar por estos servicios que dedicar el tiempo necesario y adaptarse a las best practices.
Proyectos opensource para abaratar: Imageflow o Thumbor.

32. Automatizar la optimización de imágenes
Presupuestos de rendimiento web para imágenes, nueva métrica SEO?
Un presupuesto de rendimiento es un "tope" para el rendimiento de páginas web que un equipo intenta no superar:
"las imágenes no superarán los 200 KB en ninguna página“.
Calibreapp
Speedcurve

33. Optimización de arranque de Javascript
Si eliminas el código JavaScript que no es esencial de tus páginas, puedes
reducir los tiempos de trasmisión, las operaciones de análisis y compilación
que hacen uso intensivo de la CPU, y una potencial sobrecarga de la
memoria. Esto también ayuda a que tus páginas sean interactivas más
rápido.

34. Optimización de arranque de Javascript
Objetivo: Mínimo tiempo de interacción para móviles.

35. Carga de JS de terceros
Botones de compartir
Videos embebidos
Iframes de publicidad
Scripts de analítica
Scripts de A/B
Otras librerías
Generan grandes cargasde Red Incrementan el tiempo del JS de arranque

36. Evaluación del impacto de los scripts:
- Medimos el tiempo de carga usando el panel de red de chrome
- Creamos perfiles de red que respondan a las condiciones de nuestros usuarios más communes (Network/CPU)
- Bloqueamos scripts de terceros y comparamos tiempo de carga
Carga de JS de terceros

37. Optimización scripts de terceros
- Usar atributos async o defer para evitar que se bloquee la carga.
- Analizar opciones de hostear el scriptpara ver si mejora Perfomance.
- ¿Es posible eliminar el script?
- Utilizar <link rel=preconnect> o <link rel=dns-prefetch> cuando sea posible para disminuir la latencia.
Carga de JS de terceros
¿Existe el equilibrio?

38. Encabezados optativos que nos dan datos sobre el dispositivo y la red que utilizan nuestros usuarios.
Son un método de negociación del contenido, lo que provoca que adaptemos el mismo en función de la respuesta del
navegador.
Uso del Accept header que describe que tipos de contenido entiendeel navegador, por lo que podemos ofrecerle esos.
Uso del header Save-Data, que en navegadores soportados permite aplicar optimizaciones para reducir los datos
necesarios para el renderizado.
Client Hints
WebP combinado con Uso del Accept header puede optimizar la carga de imágenes! (a veces ☺)

39. Too much! Vamos a poner metodología!

40. Performance budgets
Un presupuesto de rendimiento es un "tope" para el rendimiento de páginas web que un equipo intenta no superar.
Lighthouse puede ser incluída en el proceso de integración continua para que los tests fallen si se sobrepasa un
umbral de performance. Cada vez mas existe el reporting de la velocidad de carga en los KPI´s de negocio.
Cultura SEO!

41. Los budgets abren la conversación!
Vale la pena poner estas imágenes en alta definición?
Vale la pena este nuevo framework?
Se acabó que el SEO sea el que más se
preocupa por la performance, es hora de
que todo el mundo la tenga en cuenta!
Performance budgets

42. Métricas a incluir en los budgets
Quantitativas
(No dicen mucho sobre la experiencia de usuario)
Subrayan el impacto de las imágenes y los scripts.
Son fáciles de comunicar a los desarrolladores.
Podemos poner límites granulares del estilo:
•Tamaño máximo de imágenes
•Número máximo de web fonts
•Tamaño máximo de scripts
•Máximo número de recursos externos (incluyendo scripts de
terceros)
Dos páginas con el mismo peso pueden renderizar de forma
distinta dependiendo delorden en que se piden sus recursos, por
lo tanto la percepción del usuario puede verse afectada.

43. Hitos temporales
Métricas a incluir en los budgets
Marcan eventos que ocurrendurante la carga de la páginay que se miden el
lighthouse, por ejemplo FCP y TTI.
Lighthouse y WebPageTest calculan performance scores basados en reglas
generals de bestpracticesque puedes usar como guía, pro
La única forma de saber que funcona en tu site es testear!Y a su vez compararte
con la competencia para ver en que punto estamos.
Ejemplos de hitos:
Lapágina de búsuqedadebe incluir menos de 2 MB de imágenes en desktop.
La home debe llegar a TTI en <5s con una conexión 3G.
El blog debe tener una puntuaciónen en Lighthouse> 80.

44. Hagamos un benchmark con nuestros principals competidores, reproduciendo las características principales de uso de nuestros usuarios, a partir de aquí
podemos determinar major las métricas para el budget, ya que veremos nuestro escenario de competición.
Benchmark para poner contexto

45. Añadamos también métricas de hitos temporales y basadas en reglas para tener una vision más completa
Red Dispositivo JS Imágenes CSS HTML Fonts Total TTI
3G Moto G4 100 30 10 10 20 ~170 KB 5s
4G Moto G4 200 50 35 30 30 ~345 KB 3s
WiFi Desktop 300 250 50 50 100 ~750 KB 2s
Combina métricas a incluir en los budgets
Budget performance = Felicidad SEO ☺

46. Introduzcamos los budgets de performance en el desarrollo continuo
Budget performance = Felicidad SEO ☺
Lighthouse Bot se integra con herramientas de integración continua como Travis CI y
revisa que las subidas a producción respeten los budgets establecidos.

47. Si las subidas de Código empeoran ciertos elementos de performance el Lighthousebot u otras tools pueden parar la subida.
Introduzcamos los budgets de performance en el desarrollo continuo
Y detallar donde está la desviación:

48. Si quieres que tus usuarios noten la diferencia
en velocidad de carga, esta tiene que cambiar
en un 20% según la ley Weber-Fechner. Esta ley
de la psicofísica (psicología experimental)
demuestra que la cantidad de cambio que se
tiene que producer en los intervalos temporales
para que se note un cambio está entre el 7% y
el 18% de media. Si simplificamos nos queda la
regla del 20%.
Regla del 20%
La percepción de la performance

49. Ya casi lo tenemos!

50. …mientras tanto en GSC…

51. FCP - FIRST CONTENTFUL PAINT
• Muestra datos agregados del 75% de las visitas a una URL
FID – FIRST INPUT DELAY
Primera interacción, por lo tanto dependedel TTI
• Muestra el valor mínimo común del 95%de las visitas a una URL
…mientras tanto en GSC…
"No data available"
¿Eres nuevo en GSC?
O no hay suficientes datos en CrUX report .

52. Eduardo Garolera
edu@digitalgrowth.io
@egarolera