Un caso de éxito de algunos cambios importantes que se introdujeron en Wix para mejorar el rendimiento de carga de sitios web de millones de sitios, lo que les permitió obtener buenas puntuaciones de PageSpeed Insights y Métricas web esenciales.
Gracias a la optimización de los estándares de la industria, los proveedores de servicios en la nube y las capacidades de CDN, junto con una gran reescritura del entorno de ejecución de nuestro sitio web, el porcentaje de sitios de Wix que alcanzan buenas puntuaciones del 75% en todas las métricas de las métricas web esenciales se triplicó año tras año, según los datos de CrUX y HTTPArchive.
Wix adoptó una cultura orientada al rendimiento, y se seguirán implementando más mejoras para los usuarios. A medida que nos enfocamos en los KPIs de rendimiento, esperamos ver que aumente la cantidad de sitios que superan los umbrales de las Métricas web esenciales.
Descripción general
El mundo del rendimiento es hermosamente complejo, con muchas variables y complejidades. Las investigaciones demuestran que la velocidad del sitio tiene un impacto directo en los porcentajes de conversión y los ingresos de las empresas. En los últimos años, la industria ha hecho más hincapié en la visibilidad del rendimiento y en hacer que la Web sea más rápida. A partir de mayo de 2021, se incluirán los indicadores de experiencia de página en la clasificación de la Búsqueda de Google.
El desafío único de Wix es admitir millones de sitios, algunos de los cuales se crearon hace muchos años y no se actualizaron desde entonces. Tenemos varias herramientas y artículos para ayudar a nuestros usuarios a analizar y mejorar el rendimiento de sus sitios.
Wix es un entorno administrado y no todo está en manos del usuario. Compartir infraestructuras comunes presenta muchos desafíos para todos estos sitios, pero también abre oportunidades para mejoras importantes en todos los ámbitos, es decir, aprovechar las economías de escala.
Hablar en un lenguaje común
Una de las dificultades principales con el rendimiento es encontrar una terminología común para analizar diferentes aspectos de la experiencia del usuario y, al mismo tiempo, tener en cuenta el rendimiento técnico y el percibido. El uso de un lenguaje común y bien definido dentro de la organización nos permitió analizar y categorizar fácilmente las diferentes partes técnicas y compensaciones, aclarar nuestros informes de rendimiento y ayudarnos enormemente a comprender qué aspectos deberíamos enfocarnos en mejorar primero.
Ajustamos todas nuestras discusiones internas y de supervisión para incluir métricas estándar de la industria, como las Métricas web, que incluyen lo siguiente:
Puntuaciones de complejidad y rendimiento del sitio
Es bastante fácil crear un sitio que se cargue de forma instantánea, siempre y cuando lo hagas muy simple con solo HTML y lo publiques a través de una CDN.
Sin embargo, la realidad es que los sitios son cada vez más complejos y sofisticados, funcionan más como aplicaciones que como documentos y admiten funciones como blogs, soluciones de comercio electrónico, código personalizado, etcétera.
Wix ofrece una gran variedad de plantillas, lo que permite a los usuarios crear fácilmente un sitio con muchas funciones empresariales. Esas funciones adicionales suelen tener algunos costos de rendimiento.
El viaje
Al principio, había HTML
Cada vez que se carga una página web, siempre comienza con una solicitud inicial a una URL para recuperar el documento HTML. Esta respuesta HTML activa todas las solicitudes del cliente adicionales y la lógica del navegador para ejecutar y renderizar tu sitio. Esta es la parte más importante de la carga de la página, ya que no sucede nada hasta que llega el comienzo de la respuesta (conocido como TTFB: tiempo hasta el primer byte).
El pasado: renderización del cliente (CSR)
Cuando operas sistemas a gran escala, siempre tienes compensaciones que debes considerar, como el rendimiento, la confiabilidad y los costos. Hasta hace algunos años, Wix usaba la renderización del cliente (CSR), en la que el contenido HTML real se generaba a través de JavaScript en el cliente (es decir, en el navegador), lo que nos permitía admitir una gran escala de sitios sin tener grandes costos operativos de backend.
CSR nos permitió usar un documento HTML común, que era esencialmente vacío. Todo lo que hizo fue activar la descarga del código y los datos necesarios, que luego se usaron para generar el HTML completo en el dispositivo cliente.
Hoy: renderización del servidor (SSR)
Hace algunos años, realizamos la transición a la renderización del servidor (SSR), ya que era beneficiosa para el SEO y el rendimiento, ya que mejoraba los tiempos de visibilidad iniciales de la página y garantizaba una mejor indexación para los motores de búsqueda que no tienen compatibilidad total para ejecutar JavaScript.
Este enfoque mejoró la experiencia de visibilidad, en especial en dispositivos o conexiones más lentos, y abrió las puertas para más optimizaciones de rendimiento. Sin embargo, esto también significaba que, para cada solicitud de página web, se generaba una respuesta HTML única sobre la marcha, lo que dista mucho de ser lo ideal, en especial para los sitios con una gran cantidad de vistas.
Presentamos el almacenamiento en caché en varias ubicaciones
El código HTML de cada sitio era en su mayoría estático, pero tenía algunas advertencias:
- Cambia con frecuencia. Cada vez que un usuario edita su sitio o realiza cambios en los datos del sitio, como en el inventario de la tienda del sitio web.
- Tenía ciertos datos y cookies que eran específicos para cada visitante, lo que significa que dos personas que visitaban el mismo sitio veían un código HTML algo diferente. Por ejemplo, para admitir funciones de productos, como recordar qué artículos colocó un visitante en el carrito, el chat que inició con la empresa antes y mucho más.
- No todas las páginas se pueden almacenar en caché. Por ejemplo, una página con código de usuario personalizado que muestra la hora actual como parte del documento no es apta para el almacenamiento en caché.
En un principio, adoptamos el enfoque relativamente seguro de almacenar en caché el HTML sin datos de visitantes y, luego, solo modificamos partes específicas de la respuesta HTML sobre la marcha para cada visitante, para cada acierto de caché.
Solución de CDN interna
Para ello, implementamos una solución interna: usamos la caché HTTP de Varnish para el proxy y el almacenamiento en caché, Kafka para los mensajes de invalidación y un servicio basado en Scala/Netty que usa un proxy para estas respuestas HTML, pero muta el HTML y agrega cookies y datos específicos del visitante a la respuesta almacenada en caché.
Esta solución nos permitió implementar estos componentes delgados en muchas más ubicaciones geográficas y en varias regiones de proveedores de servicios en la nube, que se encuentran repartidas por todo el mundo. En 2019, presentamos más de 15 regiones nuevas y, gradualmente, habilitamos la caché para más del 90% de nuestras vistas de página que eran aptas para usarla. La entrega de sitios desde ubicaciones adicionales redujo la latencia de red entre los clientes y los servidores que entregaban la respuesta HTML, ya que acercó el contenido a los visitantes del sitio web.
También comenzamos a almacenar en caché ciertas respuestas de la API de solo lectura con la misma solución y a invalidar la caché en cualquier cambio en el contenido del sitio. Por ejemplo, la lista de entradas de blog del sitio se almacena en caché y se invalida cuando se publica o modifica una entrada.
Reducción de la complejidad
La implementación del almacenamiento en caché mejoró el rendimiento de manera significativa, en especial en las fases de TTFB y FCP, y mejoró nuestra confiabilidad, ya que se entregaba el contenido desde una ubicación más cercana al usuario final.
Sin embargo, la necesidad de modificar el código HTML de cada respuesta introdujo una complejidad innecesaria que, si se quitaba, presentaba una oportunidad para mejorar aún más el rendimiento.
Almacenamiento en caché del navegador (y preparaciones para las CDN)
~ 13%
Las solicitudes HTML se entregan directamente desde la caché del navegador, lo que ahorra mucho ancho de banda y reduce los tiempos de carga de las vistas repetidas.
El siguiente paso fue quitar estos datos específicos del visitante del HTML por completo y recuperarlos desde un extremo independiente, al que el cliente llamó para este fin, después de que llegó el HTML.
Migramos cuidadosamente estos datos y cookies a un nuevo extremo, al que se llama en cada carga de página, pero que muestra un JSON reducido, que solo es necesario para el proceso de hidratación, para lograr la interactividad de la página completa.
Esto nos permitió habilitar el almacenamiento en caché del HTML en el navegador, lo que significa que los navegadores ahora guardan la respuesta HTML para las visitas repetidas y solo llaman al servidor para validar que el contenido no haya cambiado. Esto se hace con la ETag HTTP, que básicamente es un identificador asignado a una versión específica de un recurso HTML. Si el contenido sigue siendo el mismo, nuestros servidores envían una respuesta 304 Not Modified al cliente, sin cuerpo.
Además, este cambio implica que nuestro código HTML ya no es específico del visitante y no contiene cookies. En otras palabras, básicamente se puede almacenar en caché en cualquier lugar, lo que abre la puerta al uso de proveedores de CDN que tienen una presencia geográfica mucho mejor en cientos de ubicaciones de todo el mundo.
DNS, SSL y HTTP/2
Con el almacenamiento en caché habilitado, se redujeron los tiempos de espera y otras partes importantes de la conexión inicial se volvieron más sustanciales. Mejorar nuestra infraestructura de redes y supervisión nos permitió mejorar los tiempos de DNS, conexión y SSL.
Se habilitó HTTP/2 para todos los dominios de usuario, lo que reduce la cantidad de conexiones requeridas y la sobrecarga que se genera con cada conexión nueva. Este fue un cambio relativamente fácil de implementar, a la vez que se aprovecharon los beneficios de rendimiento y resiliencia que ofrece HTTP/2.
Compresión Brotli (en comparación con gzip)
Entre el 21 y el 25%
Reducción del tamaño medio de transferencia de archivos
Tradicionalmente, todos nuestros archivos se comprimían con la compresión gzip, que es la opción de compresión de HTML más común en la Web. Este protocolo de compresión se implementó inicialmente hace casi 30 años.
La compresión Brotli más reciente presenta mejoras de compresión con casi ninguna compensación y, poco a poco, se está volviendo más popular, como se describe en el capítulo de compresión del Almanaque web anual. Todos los navegadores principales lo admiten desde hace tiempo.
Habilitamos la compatibilidad con Brotli en nuestros proxies de nginx en los extremos para todos los clientes que la admiten.
El cambio a la compresión Brotli redujo nuestros tamaños de transferencia de archivos medios en un 21% a 25%, lo que redujo el uso del ancho de banda y mejoró los tiempos de carga.
Redes de distribución de contenidos (CDN)
Selección de CDN dinámica
En Wix, siempre usamos CDN para entregar todo el código JavaScript y las imágenes en los sitios web de los usuarios.
Recientemente, realizamos la integración con una solución de nuestro proveedor de DNS para seleccionar automáticamente la CDN con el mejor rendimiento según la red y el origen del cliente. Esto nos permite entregar los archivos estáticos desde la mejor ubicación para cada visitante y evitar problemas de disponibilidad en una CDN determinada.
Próximamente… dominios de usuario que entregan las CDN
La última pieza del rompecabezas es entregar la última parte, y la más importante, a través de una CDN: el HTML del dominio del usuario.
Como se describió anteriormente, creamos nuestra propia solución interna para almacenar en caché y entregar los resultados de la API y el HTML específicos del sitio. Mantener esta solución en tantas regiones nuevas también tiene sus costos operativos, y agregar ubicaciones nuevas se convierte en un proceso que debemos administrar y optimizar de forma continua.
Actualmente, nos estamos integrando con varios proveedores de CDN para admitir la publicación de todo el sitio de Wix directamente desde las ubicaciones de CDN y mejorar la distribución de nuestros servidores en todo el mundo, y así mejorar aún más los tiempos de respuesta. Esto es un desafío debido a la gran cantidad de dominios que entregamos, que requieren la terminación de SSL en el perímetro.
La integración con las CDN acerca los sitios web de Wix más que nunca al cliente y mejora la experiencia de carga, incluidas tecnologías más nuevas, como HTTP/3, sin esfuerzo adicional de nuestra parte.
Algunas palabras sobre la supervisión del rendimiento
Si administras un sitio de Wix, es probable que te preguntes cómo se traduce esto en los resultados de rendimiento de tu sitio de Wix y cómo nos comparamos con otras plataformas de sitios web.
La mayor parte del trabajo realizado anteriormente se implementó el año pasado y algunos aún se están implementando.
Recientemente, The Web Almanac de HTTPArchive publicó la edición de 2020, que incluye un excelente capítulo sobre la experiencia del usuario de los CMS. Ten en cuenta que muchas de las cifras que se describen en este artículo son de mediados de 2020.
Esperamos ver el informe actualizado en 2021 y supervisamos de forma activa los informes de CrUX de nuestros sitios, así como nuestras métricas de rendimiento internas.
Nos comprometemos a mejorar continuamente los tiempos de carga y a proporcionar a nuestros usuarios una plataforma en la que puedan crear sitios como se imaginen, sin comprometer el rendimiento.
Recientemente, DebugBear publicó una revisión del rendimiento de los creadores de sitios web muy interesante, que aborda algunas de las áreas que mencioné anteriormente y examina el rendimiento de sitios muy simples creados en cada plataforma. Este sitio se creó hace casi dos años y no se modificó desde entonces, pero la plataforma mejora continuamente, al igual que el rendimiento del sitio, lo que se puede comprobar consultando sus datos durante el último año y medio.
Conclusión
Esperamos que nuestra experiencia te inspire a adoptar una cultura orientada al rendimiento en tu organización y que los detalles anteriores te resulten útiles y aplicables a tu plataforma o sitio.
Resumen:
- Elige un conjunto de métricas de las que puedas hacer un seguimiento de forma coherente con herramientas respaldadas por la industria. Te recomendamos las Métricas web esenciales.
- Aprovecha el almacenamiento en caché del navegador y las CDN.
- Migra a HTTP/2 (o HTTP/3 si es posible).
- Usa la compresión Brotli.
Gracias por conocer nuestra historia. Te invitamos a hacer preguntas, compartir ideas en Twitter y GitHub, y unirte a la conversación sobre el rendimiento web en tus canales favoritos.