Rendimiento en frontend

¡la velocidad y el tamaño importan!

luisddm.github.io/web-performance-adalab

Presentación

Quién soy

  • Ingeniero de Teleco y autodidacta
  • Trabajo en Alea Soluciones
  • Coorganizador de FrontFest
  • Aficionado a la seguridad y la electrónica

Qué hacía antes

  • Cuatro años trabajando en frontend
  • Previamente fui becario y freelance
  • Orgulloso alumnus de h4ckademy

Qué (debería) ser el desarrollo de software

Opinión personal

  • No atarse a tecnologias específicas, ser versátil
  • Buena gestión y buen código
  • Lo más importante, las personas
  • Especializarse está bien, pero evitar silos también

¡Ojo con los frameworks!

→ Odio los frameworks (Javi Santana)

Motivación

Tenemos un problema con la web

Tamaño, lentitud, complejidad, falta de usabilidad

No se pensó para su uso actual

Posibles causas

  • Mal código que crece desmesuradamente
  • No analizar correctamente al usuario objetivo
  • Falta de atención a los detalles
  • Decisiones tecnológicas erróneas
  • ...

Análisis y soluciones

Analizaremos el problema

Por qué ocurre, desde cuando ocurre, en qué impacta

Propondremos soluciones

Cómo ganar simplicidad, ligereza y rapidez

Análisis

Breve historia de la web

  • 1990: HTTP, HTML y el primer navegador
  • 1995: Javascript
  • 1996: CSS
  • 1997-1998: Comercialización de la web
  • 1999-2001: Burbuja punto com
  • 2002: Web 2.0

Cómo hemos cambiado

  • De simple texto con hipervínculos a grandes aplicaciones enriquecidas
  • De compartir conocimiento a negocio
  • De unos pocos "frikis" al público en general

→ HTTP Archive: State of the Web

Caso de estudio: USA Today

  • Edición USA vs edición UE (post RGPD)
  • Usaremos las Dev Tools del navegador
    • Pestaña de network
    • Forzar el throttling
  • Peso total vs transferido
    • Depende de caché, cabeceras, compresión, redirecciones...

→ USA Today

→ Twit de @paulcalvano

Otros casos de estudio

Sitio web Tx / Total Req.
Marca 5,6 / 13,8 MB ~600
El País 6,1 / 17,6 MB ~450
Tumblr 3,6 / 6,2 MB ~75
Medium 1,4 / 3,3 MB ~50

¿A quién perjudica esto?

Ámbito geográfico

Algunas de las webs que hacemos las utiliza gente que vive en entornos muy diferentes

→ Mapa cobertura Movistar 4G

→ Muchas zonas de Europa aún carecen de conexión de calidad a Internet (El País)

Dispositivos heterogéneos

Existe una ingente variedad de dispositivos para acceder a la web, que cuestan desde decenas a miles de euros

Elevado consumo de datos

¿Cuántas webs podemos ver con un giga de datos?

Bajo "engagement"

Cuando una web tarda demasiados segundos en cargar, la abandonamos

Accesibilidad

El mal rendimiento implica exclusión de algunos segmentos de población

Privacidad

Enorme cantidad de trackers que obtienen datos personales permanentemente a grandes empresas de internet, incluso sin estar logueados, y que ralentizan la web

Soluciones

Principio de Pareto

También conocido como regla del 80/20

Disponemos de tiempo y presupestos limitados, así que hay que priorizar las optimizaciones

Comprimir y redimensionar imágenes

  • Saber cuándo usar JPG, PNG, SVG u otros
  • Buscar un balance entre calidad y tamaño reducido
  • ¡No GIFs ni Flash!
  • En CSS, usar diferentes imágenes para diferentes media queries
  • Usar tag <picture>

→ El elemento Picture en MDN

Lo mismo con los vídeos

  • Elegir el formato adecuado (WebM, MP4, OGG...) pero cuidado con la compatibilidad
  • ¡No GIFs animados! Usar vídeo en su lugar
  • ¡No autoplay! Que decida el usuario
  • Cuidado con incrustar vídeos de YouTube

→ El Elemento Video en MDN

Minificar y concatenar

  • Minificar es eliminar espacios, intros, etc., reducir nombres de variables y otras técnicas similares para restar tamaño
  • Concatenar es juntar todos los archivos JS y CSS en uno solo para reducir las peticiones HTTP
  • Los frameworks suelen automatizar ambas cosas para el código de producción

→ Ejemplo con Gulp.js

Tipografías

  • Si importamos con @font-face en CSS, usar formato woff2 siempre que se pueda
  • Usar adecuadamente font-display para que el texto sea visible con una fuente de fallback mientras se carga la nuestra
  • Cuidado con importarlas directamente de Google Fonts o similares

→ La regla @font-face de CSS

Otros detalles

  • Colocar scripts siempre al final del <body> para no bloquear el renderizado
  • Eliminar en la medida de lo posible todo el JS y CSS que no se use

Compresión de datos y cacheado

Ahorran mucha transferencia de datos, pero dependen de la política del servidor

HTTP/2

  • Evita la necesidad de concatenar y modifica otras buenas prácticas de HTTP/1.1
  • Ha de estar soportado tanto por el servidor como por el navegador

→ Introducción a HTTP/2

Progressive enhancement

  • Implica una forma integral de pensar y desarrollar
  • Construir primero lo básico y añadir mejoras que se activen en función de las capacidades del hardware
  • Que TODOS los usuarios tengan una experiencia mínima, que no se rompa nada
  • Cada vez tenemos más estándares web con fallback
  • Útil vs usable: que sea útil lo más rápido posible

→ The cost of Javascript (Addy Osmani)

Herramientas

Lighthouse

Genera un informe sobre el rendimiento de la web

→ Auditar apps web con Lighthouse

→ Instalar Lighthouse en Chrome

GTmetrix

Analiza el rendimiento de la web y ofrece opciones de optimización

→ GTmetrix

Conclusiones

  • Cuando se optimiza, empezar por lo mínimo, y crecer estableciendo prioridades teniendo en cuenta los usuarios potenciales y los recursos disponibles
  • Establecer prioridades de optimización
  • La simplicidad es la gran aliada de la web y el software en general

→ @PerfReviews_ en Twitter

¡Gracias!

¿Alguna pregunta?