Rendimiento en frontend
¡la velocidad y el tamaño importan!
luisddm.github.io/web-performance-adalab
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
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
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 |
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
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)
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?