Un caso práctico de algunos cambios importantes ingresados en Wix para mejorar el rendimiento de carga de sitios web en millones de sitios, lo que les permite obtener buenas puntuaciones de PageSpeed Insights y las Métricas web esenciales.
Gracias al aprovechamiento de los estándares de la industria, los proveedores de servicios en la nube y las funciones de CDN, combinados con una gran reescritura del entorno de ejecución de nuestro sitio web, el porcentaje de sitios de Wix que alcanzaron buenas puntuaciones del percentil 75 en todas las métricas web esenciales se triplicó año tras año, según datos de CrUX y HTTPArchive.
Wix adoptó una cultura orientada al rendimiento, y se seguirán implementando mejoras para los usuarios. A medida que nos enfocamos en los KPI de rendimiento, esperamos ver un aumento en 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. Según estudios, la velocidad del sitio tiene un impacto directo en los ingresos y porcentajes de conversiones de las empresas. En los últimos años, el sector puso más énfasis en la visibilidad del rendimiento y en acelerar la Web. A partir de mayo de 2021, los indicadores de experiencia de página se incluirán 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 diversas herramientas y artículos para ayudar a nuestros usuarios a obtener información sobre lo que pueden hacer para 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 sectores, es decir, aprovechar las economías de escala.
Hablar en un idioma común
Una de las principales dificultades del rendimiento es encontrar una terminología común para analizar diferentes aspectos de la experiencia del usuario, teniendo en cuenta tanto el rendimiento técnico como el percibido. El uso de un lenguaje común bien definido dentro de la organización nos permitió analizar y categorizar con facilidad las diferentes partes técnicas y compensaciones, aclaró nuestros informes de rendimiento y nos ayudó muchísimo a comprender qué aspectos debemos enfocarnos en mejorar primero.
Ajustamos todas nuestras actividades de supervisión y debates internos para incluir métricas estándar de la industria, como las Métricas web, que incluyen lo siguiente:
Puntuaciones de rendimiento y complejidad del sitio
Es bastante fácil crear un sitio que se cargue al instante, siempre que lo hagas muy sencillo solo con HTML y lo entregues a través de una CDN.
Sin embargo, la realidad es que los sitios se vuelven cada vez más complejos y sofisticados, funcionan más como aplicaciones en lugar de documentos y brindan funciones de compatibilidad, como blogs, soluciones de comercio electrónico, código personalizado, etcétera.
Wix ofrece una gran variedad de plantillas, lo que permite a sus usuarios crear un sitio fácilmente 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, comienza con una solicitud inicial a una URL para recuperar el documento HTML. Esta respuesta HTML activa todas las solicitudes adicionales de clientes 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 (lo que se conoce como TTFB; tiempo hasta el primer byte).
El pasado: renderización del cliente (CSR)
Cuando operas sistemas a gran escala, siempre debes tener en cuenta compensaciones, como el rendimiento, la confiabilidad y los costos. Hasta hace unos años, Wix usaba el renderizado del cliente (CSR), en el que el contenido HTML real se generaba a través de JavaScript en el lado del cliente (es decir, en el navegador), lo que nos permitía admitir una gran escala de sitios sin generar enormes costos operativos de backend.
CSR nos permitió utilizar un documento HTML común, que estaba prácticamente vacío. Todo lo que hizo fue activar la descarga del código y los datos requeridos que luego se usaron para generar el código HTML completo en el dispositivo cliente.
Hoy: renderización del servidor (SSR)
Hace unos años, hicimos la transición al procesamiento del servidor (SSR), ya que beneficiaba tanto la SEO como el rendimiento, mejoraba los tiempos de visibilidad inicial de la página y garantizamos una mejor indexación para los motores de búsqueda que no son totalmente compatibles con la ejecución de JavaScript.
Este enfoque mejoró la experiencia de visibilidad, en especial en conexiones y dispositivos más lentos, y abrió las puertas para realizar más optimizaciones de rendimiento. Sin embargo, también significó que para cada solicitud de página web se generaba en el momento una respuesta HTML única, que está muy muy lejos de ser óptima, en especial para los sitios con una gran cantidad de vistas.
Presentamos el almacenamiento en caché en varias ubicaciones
El código HTML para cada sitio era en su mayoría estático, pero hubo algunas advertencias:
- Cambia con frecuencia. Cada vez que un usuario edita su sitio o realiza cambios en los datos del sitio, por ejemplo, en el inventario de la tienda del sitio web.
- Había ciertos datos y cookies que eran específicos del visitante, lo que significaba que dos personas que visitaran el mismo sitio veían código HTML algo diferente. Por ejemplo, para admitir funciones de productos, como recordar qué artículos un visitante puso en el carrito o el chat que el visitante inició antes con la empresa, 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 los datos del visitante y, luego, solo modificamos partes específicas de la respuesta HTML sobre la marcha para cada visitante y por cada acierto de caché.
Solución de CDN interna
Lo hicimos con la implementación de una solución interna: con el uso de la caché HTTP Varish a fin de almacenar en caché y realizar proxies, Kafka para los mensajes de invalidación y un servicio basado en Scala/Netty que procesa estas respuestas HTML, pero muta el HTML y agrega datos específicos del visitante y cookies a la respuesta almacenada en caché.
Esta solución nos permitió implementar estos componentes delgados en muchas más ubicaciones geográficas y regiones de varios proveedores de servicios en la nube, las cuales se encuentran en todo el mundo. En 2019, presentamos más de 15 regiones nuevas y habilitamos gradualmente el almacenamiento en caché para más del 90% de nuestras páginas vistas que eran aptas para el almacenamiento en caché. La entrega de sitios desde ubicaciones adicionales redujo la latencia de la red entre los clientes y los servidores que entregaban la respuesta HTML, ya que acercaba 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, luego, invalidamos la caché ante 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 una entrada se publica o modifica.
Reduce las complejidades
La implementación del almacenamiento en caché mejoró en gran medida el rendimiento, principalmente en las fases TTFB y FCP, y mejoró nuestra confiabilidad, ya que entrega el contenido desde una ubicación más cercana al usuario final.
Sin embargo, la necesidad de modificar el HTML de cada respuesta presentaba una complejidad innecesaria que, si se quitaba, presentaba una oportunidad para realizar mejoras adicionales en el rendimiento.
Almacenamiento en caché del navegador (y preparativos para las CDN)
Aprox. el 13%
Las solicitudes de HTML que se entregan directamente desde la caché del navegador permiten ahorrar mucho ancho de banda y reducir 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 de un extremo separado, que el cliente llama para este fin, después de que llegara el HTML.
Migramos cuidadosamente estos datos y cookies a un extremo nuevo, al que se llama en cada carga de página, pero muestra un JSON delgado, que solo es necesario para el proceso de hidratación, para alcanzar la interactividad completa de la página.
Esto nos permitió habilitar el almacenamiento en caché del navegador del código HTML, 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. Para ello, se usa la ETag de HTTP, que es básicamente 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, pero no hay un cuerpo.
Además, este cambio significa que nuestro código HTML ya no es específico para visitantes y no contiene cookies. En otras palabras, se puede almacenar en caché en cualquier lugar, lo que permite usar proveedores de CDN que tienen una presencia geográfica mucho mejor en cientos de ubicaciones en 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. La mejora de nuestra infraestructura de red y la supervisión nos permitió mejorar nuestros tiempos de DNS, conexión y SSL.
Se habilitó HTTP/2 para todos los dominios de usuario, lo que reduce la cantidad de conexiones necesarias y la sobrecarga que viene con cada conexión nueva. Fue un cambio relativamente fácil de implementar y, a la vez, aprovechar los beneficios del rendimiento y la resiliencia que ofrece HTTP/2.
Compresión Brotli (frente a gzip)
21 a 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 HTML más utilizada en la Web. Este protocolo de compresión se implementó inicialmente hace casi 30 años.
La compresión de Brotli más reciente presenta mejoras de compresión casi sin compensaciones, y se está volviendo más popular, como se describe en el capítulo de compresión anual de la Almanac Web. Hace tiempo que es compatible con todos los navegadores principales.
Habilitamos la compatibilidad con Brotli en nuestros proxies nginx en los perímetros para todos los clientes que la admiten.
Usar la compresión Brotli redujo nuestra mediana de tamaños de transferencia de archivos en un 21% a un 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 publicar el código JavaScript y las imágenes en los sitios web de los usuarios.
Recientemente, integramos una solución de nuestro proveedor de DNS para seleccionar de forma automática 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 publicados por CDN
La pieza final del rompecabezas es entregar la última parte y la más crítica a través de una CDN: el HTML del dominio del usuario.
Como se describió anteriormente, creamos nuestra propia solución para almacenar en caché y entregar los resultados de API y HTML específicos del sitio. Mantener esta solución en tantas regiones nuevas también tiene sus costos operativos, por lo que agregar ubicaciones nuevas se convierte en un proceso que necesitamos administrar y optimizar de forma continua.
Actualmente, nos integramos con varios proveedores de CDN para admitir la entrega de todo el sitio de Wix directamente desde las ubicaciones de CDN para mejorar la distribución de nuestros servidores en todo el mundo y, por lo tanto, los tiempos de respuesta. Esto representa un desafío debido a la gran cantidad de dominios que entregamos, los cuales requieren la finalización SSL en el perímetro.
La integración con CDN acerca los sitios web de Wix al cliente como nunca antes. Además, incluye más mejoras en la experiencia de carga, incluidas tecnologías más nuevas como HTTP/3, sin ningún esfuerzo de nuestra parte.
Algunos comentarios sobre la supervisión del rendimiento
Si tienes 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 la comparamos con otras plataformas de sitios web.
La mayor parte del trabajo anterior se implementó durante el último año, y parte aún se está lanzando.
El texto web de HTTPArchive publicó recientemente la edición de 2020, que incluye un capítulo excelente sobre la experiencia del usuario de CMS. Ten en cuenta que muchas de las cifras que se describen en este artículo corresponden a mediados de 2020.
Esperamos ver el informe actualizado en 2021 y estamos supervisando activamente los informes de CrUX para nuestros sitios, así como nuestras métricas de rendimiento internas.
Tenemos el compromiso de mejorar continuamente los tiempos de carga y proporcionar a nuestros usuarios una plataforma en la que puedan compilar sitios como imaginen, sin comprometer el rendimiento.
Recientemente, DebugBear lanzó una Revisión de rendimiento del creador de sitios web muy interesante, que aborda algunas de las áreas que mencioné anteriormente y analiza el rendimiento de sitios muy simples compilados en cada plataforma. Este sitio se compiló hace casi dos años y, desde entonces, no se modificó, pero la plataforma mejora de manera continua y el rendimiento del sitio junto con ella. Se puede observar visualizando 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 sean ú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 las herramientas avaladas por la industria. Recomendamos las Métricas web esenciales.
- Aprovechar 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 aprender nuestra historia. Te invitamos a hacer preguntas, compartir ideas en Twitter y GitHub, y participar en la conversación sobre el rendimiento web en tus canales favoritos.