Desde hace ya algún tiempo queríamos aplicar algunas tecnologías de front que habíamos probado a algún proyecto. Por fin tuvimos la oportunidad, en un proyecto legacy, de aplicarlo y actualizar nuestra versión de Symfony y PHP. En este tipo de proyectos, donde hay dependencias antiguas, es siempre un reto mayor. Pero, ¿quién dijo miedo? No siempre se tiene un proyecto entre manos donde se pueda invertir tiempo en el rendimiento en sí, la velocidad desde que el usuario hace la petición hasta que se renderiza completamente la web, sea uno de los objetivos prioritarios.
Asi que aprovechamos este proyecto para utilizar:
- Gulp + webpack en la generación de assets
- Symfony 3 y PHP 7
- Mejorar la arquitectura del proyecto
Y estas son las conclusiones que obtuvimos:
1. EL DISEÑO ES LA BASE
Otro de los requerimientos iniciales del proyecto era utilizar Bootstrap. Este proyecto tiene un componente creativo importante, por lo que adaptarse a un sistema de columnas fue un gran reto. Y es aquí donde comienza nuestro trabajo de optimización del sitio, ¿Qué necesitamos de Bootstrap? Realmente sólo necesitamos el grid, así que tomamos solamente esa pequeña librería y dejamos el resto.
Del total de 233kb que pesa Bootstrap (versión 3.3.7) solamente incluimos en nuestro proyecto 13kb que es lo que pesa el grid.
2. MOBILE FIRST
A estas alturas, donde la tendencia de los usuarios es navegar usando dispositivos móviles, desarrollar un site responsive a partir de mobile e ir introduciendo más código y complejidad a medida que aumenta el display de la pantalla es algo prácticamente obligatorio si queremos que el rendimiento de nuestro site mobile sea rápido. En Europa ya hay sitios donde se supera ampliamente el 50% de visitas procedentes de dispositivos móviles y la tendencia es que su uso siga aumentando.
3. SVG VS PNG
Unos de los recursos más utilizados en un diseño web son las imágenes/iconos/logos que forman parte del propio diseño. En ante riores proyectos utilizabamos un sprite de imágenes, pero para este rediseño optamos por un nuevo formato SVG, el cual es mejor aliado para el desarrollo responsive, permitiendo redimensionar hasta el infinito sin perder calidad y con un peso muy ligero. Un cambio que aplicamos es que utilizamos nuestros SVG’s como elementos html, reduciendo así el número de peticiones al servidor. Otro gran beneficio de tener los svg, como elementos html es poder tener un historial de cambios del archivo en git.
Un ejemplo de este resultado es un logo que antes pesaba 10kb con dimensiones de 123×61 pixeles y formato jpg a un archivo con el formato html, peso de 1kb y dimensiones infinitas.
4. ETIQUETAS
Además de las imágenes que forman parte del diseño de un site, tenemos las imágenes de contenido que son las imágenes que los editores suben para los artículos, galerías etc. Gracias a la etiqueta
Si a este comportamiento le sumamos un lazy loading de imágenes obtenemos un gran impacto en la carga del sitio, ya que en la primer carga solamente se van a requerir las imágenes que el usuario tiene visibles en su dispositivo y gracias al tag picture, se mostrará la imagen con las dimensiones ideales para dicha resolución.
5. FUENTES
Recurso importante en el diseño de un site, también es un recurso importante a la hora de optimizar el tiempo de carga de un site. Nuestra postura y recomendación fue reducir el número de fuentes en el diseño y de ser posible utilizar la biblioteca de Google Fonts. Como resultado pasamos de tener 30 familias de fuentes a solamente 3 en este rediseño, una de ellas Open Sans, incluida en Google Fonts y una de las más usadas.
Otro cambio introducido fue reducir el número de formatos que compartimos para una fuente y servir woff/woff2 que son los formatos que mejor compresión tienen.
6. DIVIDE Y VENCERÁS, VERSIÓN CSS
El equipo de front tenía claro que quería un css limpio, ordenado y optimizado. Dividimos los elementos que forman la página web en componentes, ya que muchos de ellos se repiten en diferentes navegaciones y contenidos y no queríamos tener que duplicar elementos por cambios en tamaños de fuentes, margins, paddings, etc.
Conseguir una consistencia en los estilos y poder hacer componentes de cada uno de los elementos de la página y solo llamar a esos componentes donde los necesitamos, vale, esto está muy bien, pero no sirve de nada si todos nuestros archivos sass terminan generando un único css. Optimizar el css fue tarea fácil gracias al trabajo previo de componentizar el sitio, creamos una hoja de estilos por tipo contenido en el sitio, esto es Artículos, Galerías, etc. y cada hoja de estilo incluía solamente los componentes que necesitaba.
Así logramos que para un artículo, antes un css que pesaba 580kb ahora pesa solamente 329kb.
7. DIVIDE Y VENCERÁS, VERSIÓN JS
Siguiendo el alineamiento de los estilos, con el javascript queríamos hacer lo mismo, modularizar. Pero queríamos algo más que hacer pequeños archivos js luego concatenarlos en uno solo para servirlo en el sitio.
Así que optamos por utilizar Webpack, creamos módulos para cada componente en el sitio, cada componente es responsable de su comportamiento, luego para cada tipo de contenido creamos un módulo al cual llamamos controlador, que incluía los pequeños módulos que necesitaba ese contenido para funcionar. De este modo al igual que con el css, se genera un js por tipo de contenido, lo cual hace que cada archivo tenga solamente lo que necesita para el correcto funcionamiento.
Pero teníamos otro problema, 25 librerías externas se utilizaban. Luego de un análisis decidimos utilizar solamente 3, una para las galerías, otra para la carga de imágenes y jQuery. Pero con una condición, solamente se utilizan en lugares donde realmente se necesiten y así logramos un sitio con su 95% de código escrito en javascript puro y jQuery solamente se incluye como dependencia para la librería de galerías.
8. UNIENDO LAS DIVISIONES
Alguien tenía que unir tantas divisiones en CSS y JS y el seleccionado fue GulpJs. Gulp sería el encargado de compilar nuestros CSS, transpilar nuestro JS, optimizar las imágenes que no pudimos pasar a SVG, ejecutar los test y mover todo a la carpeta pública. Gracias a Gulp, bajamos el tiempo de deploy de 15 minutos a 7.
Los desarrolladores ahora pueden guardar sus cambios y automáticamente ver el resultado gracias al Gulp Watch.
9. DEPENDENCIAS EXTERNAS
En cualquier web de medios el SEO influye y mucho, y para tomar decisiones hay que estar muy bien informado sobre el comportamiento del usuario. Por tal motivo este tipo de sitios suele estar repleto de librerías js que mapean los eventos del usuario. Decidimos utilizar Google Tag Manager (GTM) y gestionar todas librerías de terceros desde ahí.
Esto es un cambio muy bien recibido además por los equipos de marketing, ya que pueden agregar, modificar o quitar librerías y eventos desde GTM , sin la necesidad de un deploy, además estas librerías se cargan asíncronamente, impactando positivamente en los tiempos de carga. Para nosotros nos habilita poder deshabilitar una librería temporalmente en el caso que esté generando errores en el sitio.
10. EQUIPOS TÉCNICOS
Hacemos tecnología, pero lo que importa, y lo que está detrás de todo, son personas. La experiencia y conocimientos son elementos necesarios, pero la actitud y las ganas de concretar las mejoras en métricas reales ha sido el objetivo a perseguir, casi obsesivamente. Haber contado con la confianza de los promotores, GQ Magazine, con su apuesta decidida por este proyecto, ha sido determinante en el éxito final.
EN CONCLUSIÓN:
El rendimiento, uno de los objetivos principales del proyecto, fue un gran éxito. Logramos bajar la carga completa de la homepage de 25,6 segundos a 7,1 segundos y antes una homepage que se comenzaba a renderizar en 3 segundos ahora se comienza a renderizar antes del segundo.
Y algo muy importante para nosotros: con este nuevo rediseño se logró un sitio con 203.966 líneas de código menos. Nada menos.