[No] utilice CDN

Prácticamente en cualquier artículo o herramienta de optimización de la velocidad de sitios web hay un modesto punto que dice "utiliza CDN". En general, un CDN es una red de entrega de contenido. En la empresa "Método Lab" a menudo nos enfrentamos a preguntas de clientes sobre este tema, algunos incluso activan el CDN por su cuenta. El objetivo de este artículo es analizar qué puede ofrecer un CDN en términos de velocidad de carga del sitio, qué problemas pueden surgir y en qué casos el uso de un CDN está justificado.

Las demoras marcadas en la imagen se deben al uso de CDN.

Un poco de historia

Como muchas tecnologías, los CDN surgieron por necesidad. Con el desarrollo de los canales de Internet, aparecieron los servicios de video en línea. Es evidente que el contenido de video requiere un ancho de banda considerablemente mayor en comparación con el contenido habitual de los sitios (imágenes, texto y código CSS o JS).

Al intentar transmitir un flujo de video a múltiples clientes desde un único servidor, el cuello de botella será probablemente el canal de Internet del servidor. Por lo general, con solo unos pocos miles de flujos, se saturará un canal típico de servidor. Por supuesto, pueden existir otras limitaciones en los recursos, pero ahora no son relevantes. También es importante mencionar que ampliar el canal del servidor es demasiado caro (a veces incluso imposible) y no es práctico. La carga en el canal durante las transmisiones será cíclica.

El CDN resuelve excelentemente el problema de la limitación del canal de un servidor individual. Los clientes no se conectan directamente al servidor, sino a los nodos de la red CDN. En la situación ideal, el servidor envía un flujo al nodo CDN, y luego la red utiliza sus propios recursos para entregar este flujo a numerosos usuarios. Desde el punto de vista económico, solo pagamos por los recursos efectivamente consumidos (pueden ser ancho de banda o tráfico) y obtenemos una excelente escalabilidad para nuestro servicio. El uso de CDN para la entrega de contenido pesado está completamente justificado y es lógico. Aunque cabe señalar que los jugadores más grandes en este campo (como Netflix) construyen sus propios CDN en lugar de utilizar grandes CDN comerciales (Akamai, Cloudflare, Fastly, etc.).

A medida que la web ha evolucionado, las aplicaciones web se han vuelto más complejas y pesadas. La velocidad de carga ha cobrado protagonismo. Los entusiastas de la velocidad de los sitios web han identificado rápidamente algunos problemas clave que causan una carga lenta. Uno de ellos son las demoras en la red (RTT — tiempo de ida y vuelta o tiempo de ping). Las demoras afectan muchos procesos en la carga del sitio: el establecimiento de la conexión TCP, el inicio de la sesión TLS y la carga de cada recurso individual (imágenes, archivos JS, documentos HTML, etc.).

El problema se agravaba porque al usar el protocolo HTTP/1.1 (hasta la llegada de SPDY, QUIC y HTTP/2, esta era la única opción), los navegadores abrían no más de 6 conexiones TCP a un mismo host. Todo esto conducía a la inactividad de la conexión y al uso ineficiente del ancho de banda. El problema se solucionaba en parte con el sharding de dominios — creando hosts adicionales para superar el límite en el número de conexiones.

Aquí aparece la segunda capacidad de la CDN: reducir las demoras (RTT) gracias a un gran número de puntos y la cercanía de nodos al usuario. La distancia juega un papel crucial aquí: la velocidad de la luz es limitada (alrededor de 200,000 km/s en fibra óptica). Por lo tanto, cada 1000 km de distancia agrega 5 ms de demoras o 10 ms en RTT. Este es el gasto mínimo de tiempo en la transmisión, ya que también hay demoras en el equipo intermedio. Como la CDN generalmente puede almacenar en caché objetos en sus servidores, podemos beneficiarnos de la carga de esos objetos a través de la CDN. Las condiciones necesarias para esto son: la existencia del objeto en la caché y la cercanía del punto CDN al usuario en comparación con el servidor de la aplicación web (servidor de origen). Es importante comprender: la proximidad geográfica de un nodo CDN no garantiza bajas demoras. La ruta entre el cliente y la CDN puede configurarse de tal manera que el cliente se conecte a un host en otro país, o incluso en otro continente. Aquí entran en juego las relaciones de los operadores de telecomunicaciones y el servicio CDN (interconexión, disponibilidad de puntos de intercambio, participación en IX, etc.) y la política de enrutamiento de tráfico de la propia CDN. Por ejemplo, Cloudflare, al utilizar sus dos planes iniciales (gratuito y económico), no garantiza la entrega de contenido desde el nodo más cercano; la elección del host se realiza para lograr el costo mínimo.

Muchas empresas de Internet líderes están generando interés público (entre desarrolladores web y propietarios de servicios) en el tema de la velocidad de carga y funcionamiento de los sitios web. Entre estas empresas se encuentran Yahoo (herramienta Yslow), AOL (WebPageTest) y Google (servicio Page Speed Insights), que desarrollan sus recomendaciones para acelerar los sitios (principalmente relacionadas con la optimización del cliente). Posteriormente, surgen nuevas herramientas para probar la velocidad de los sitios, que también ofrecen consejos para aumentar la velocidad. En cada uno de estos servicios o complementos hay una recomendación invariable: «Utiliza CDN». Como explicación del efecto CDN, generalmente se menciona la reducción de las latencias de red. Lamentablemente, no todos están dispuestos a entender cómo exactamente se logra el efecto de aceleración de un CDN y cómo se puede medir, por lo que la recomendación se acepta como un hecho y se utiliza como un postulado. De hecho, no todos los CDN son igualmente útiles.

Uso de CDN hoy en día

Para evaluar la utilidad de la implementación de CDN, es necesario clasificarlos. Lo que se puede encontrar actualmente en la práctica (los ejemplos entre paréntesis, por supuesto, no son exhaustivos):

1. CDN gratuitos para la distribución de bibliotecas JS (MaxCDN, Google, Yandex).
2. CDN de servicios de optimización del cliente (por ejemplo, Google Fonts para fuentes, Cloudinary, Cloudimage para imágenes).
3. CDN para recursos estáticos y optimización en CMS (disponibles en Bitrix, WordPress y otros).
4. CDN de uso general (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN para acelerar sitios web (Cloudflare, Imperva, Airy).

La diferencia clave entre estos tipos radica en la siguiente cuestión: qué parte del tráfico pasa a través del CDN. Los tipos 1-3 se encargan de la entrega solo de una parte del contenido: desde una solicitud hasta varias decenas (generalmente imágenes). Los tipos 4 y 5 son el proxy completo del tráfico a través del CDN.

En la práctica, esto significa el número de conexiones que se utilizan para cargar el sitio. Con el uso de HTTP/2, utilizamos una única conexión TCP al host para manejar cualquier número de solicitudes. Si separamos los recursos entre el host principal (origin) y el CDN, es necesario dividir las solicitudes en varios dominios y crear múltiples conexiones TCP. En el peor de los casos esto es: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. En esta fórmula no se tienen en cuenta los retrasos en las redes móviles para activar el canal de radio del dispositivo (si no estaba activo) y las demoras en la torre celular.

Así es como se ve en la carga del sitio web (las demoras para conectarse a la CDN se destacan con RTT de 150 ms):

Si la CDN cubre todo el tráfico del sitio (excepto servicios externos), podemos usar una única conexión TCP, ahorrando latencias en la conexión a hosts adicionales. Por supuesto, esto se aplica a las conexiones HTTP/2.

Las diferencias adicionales se definen por la funcionalidad específica de la CDN: para el primer tipo, esto es solo hosting un archivo estático, mientras que para el quinto se trata de la modificación de varios tipos de contenido en el sitio con el objetivo de optimización.

Capacidades de la CDN para acelerar el sitio

Describamos el espectro completo de capacidades de la CDN para acelerar sitios, sin mirar la funcionalidad de tipos específicos de CDN, y luego veamos qué se realiza en cada uno de ellos.

1. Compresión de recursos de texto

La posibilidad más básica y comprensible, sin embargo, a menudo se implementa de manera deficiente. Todas las CDN declaran la compresión como una de sus características de aceleración. Pero si se mira más de cerca, surgen deficiencias:

• se pueden usar tasas bajas para la compresión dinámica – 5-6 (por ejemplo, para gzip el máximo es 9);
• en la compresión estática (archivos en caché) no se utilizan posibilidades adicionales (por ejemplo, zopfi o brotli con un nivel de 11)
• no hay soporte para la eficiente compresión brotli (ahorro de aproximadamente 20% comparado con gzip).

Si utiliza una CDN, vale la pena verificar estos varios puntos: tomar un archivo que llegó desde la CDN, fijar su tamaño en forma comprimida y recomprimirlo manualmente para comparar (se puede usar algún servicio en línea con soporte para brotli, por ejemplo всёсжать.рф).

2. Configuración de encabezados de caché del cliente

También una característica simple de aceleración: establecer encabezados para la caché del contenido por el cliente (navegador). El encabezado más relevante es cache-control, el obsoleto es expires. Además, se puede usar Etag. Lo principal es que max-age en cache-control sea suficientemente grande (de un mes o más), si está dispuesto a almacenar el recurso de manera rigurosa, se puede agregar la opción immutable.

Las CDN pueden reducir el valor de max-age, obligando al usuario a cargar la estática con más frecuencia. No está claro si esto se debe al deseo de aumentar el tráfico en la red o a la mejora de la compatibilidad con sitios que no pueden vaciar la caché. Por ejemplo, el valor del tiempo de caché en los encabezados de Cloudflare por defecto es de 1 hora, lo cual es muy bajo para estáticas inmutables.

3. Optimización de imágenes

Dado que las CDN asumen las funciones de almacenamiento en caché y entrega de imágenes, sería lógico optimizarlas en el lado de la CDN y entregarlas en ese formato a los usuarios. Cabe mencionar que esta capacidad solo está disponible para las CDN de tipos 2, 3 y 5.

Las imágenes se pueden optimizar de diversas maneras: utilizando formatos de compresión avanzados (por ejemplo, WebP), codificadores más eficientes (MozJPEG) o simplemente eliminando metadatos innecesarios.

En general, hay dos tipos de optimización: con pérdida de calidad y sin pérdida de calidad. Las CDN suelen tratar de utilizar optimizaciones sin pérdidas, para evitar posibles quejas de los clientes sobre cambios en la calidad de las imágenes. En tales condiciones, la ganancia será mínima. En realidad, a menudo el nivel de calidad de JPEG supera considerablemente el necesario y se puede recomprimir sin problemas con un índice de calidad más bajo, sin perjudicar la percepción del usuario. Por otro lado, es difícil determinar el nivel de calidad y la configuración universalmente para todas las aplicaciones web posibles, por lo que las CDN utilizan configuraciones más conservadoras en comparación con las que se podrían aplicar teniendo en cuenta el contexto (finalidad de las imágenes, tipo de aplicación web, etc.)

4. Optimización de la conexión TLS

La mayor parte del tráfico hoy en día se transmite a través de conexiones TLS, lo que significa que gastamos tiempo adicional en la negociación de TLS. Recientemente se han desarrollado nuevas tecnologías para acelerar este proceso. Por ejemplo, la criptografía EC, TLS 1.3, la caché de sesiones y los tickets de sesión, la aceleración de hardware para cifrado (AES-NI), etc. Una configuración adecuada de TLS puede reducir el tiempo de conexión a 0-1 RTT (sin considerar DNS y TCP).

Con software moderno, implementar tales prácticas no es complicado en las propias capacidades.

No todos los CDN implementan las mejores prácticas de TLS; esto se puede verificar midiendo el tiempo de conexión TLS (por ejemplo, en Webpagetest). Idealmente, para una nueva conexión, se busca 1RTT, 2RTT es un nivel promedio, y 3RTT o más es deficiente.

También es importante señalar que, incluso utilizando TLS a nivel de CDN, el servidor con nuestra aplicación web también debe manejar TLS, pero del lado del CDN, porque el tráfico entre el servidor y el CDN transita por una red pública. En el peor de los casos, podríamos tener retrasos dobles en la conexión TLS (el primero con el host del CDN, el segundo entre este y nuestro servidor).

Para algunas aplicaciones, es necesario considerar cuestiones de seguridad: por lo general, el tráfico se descifra en los nodos del CDN, lo que representa una posibilidad potencial de interceptación del tráfico. Una opción para operar sin revelar el tráfico generalmente se ofrece en los planes más premium por un costo adicional.

5. Reducción de retrasos en la conexión

La principal ventaja del CDN, que todos mencionan: bajas latencias (menor distancia) entre el host del CDN y el usuario. Esto se logra creando una arquitectura de red distribuida geográficamente, donde los hosts se encuentran en puntos de concentración de usuarios (ciudades, puntos de intercambio de tráfico, etc.).

En la práctica, las prioridades para diferentes redes pueden estar en regiones concretas. Por ejemplo, los CDN rusos tendrán más puntos de presencia en Rusia. Los estadounidenses, principalmente, desarrollarán su red en los EE. UU. Por ejemplo, uno de los CDN más grandes, Cloudflare, tiene solo 2 puntos en Rusia: Moscú y San Petersburgo. Por lo tanto, como máximo, podemos ahorrar alrededor de 10 ms de latencia en comparación con el alojamiento directo en Moscú.

La mayoría de los CDN occidentales no tienen puntos en Rusia. Al conectarse a ellos, solo puede incrementar las latencias para su audiencia rusa.

6. Optimización de contenido (minificación, cambios estructurales)

El punto más complejo y técnico. Realizar cambios en el contenido durante la entrega puede ser muy arriesgado. Incluso al considerar la minificación: reducir el código fuente (eliminando espacios sobrantes, construcciones innecesarias, etc.) puede afectar su funcionalidad. En cuanto a cambios más serios—como mover el código JS al final del HTML, combinar archivos y similares—el riesgo de interferir con la funcionalidad del sitio es aún mayor.

Por lo tanto, solo algunos CDN del tipo 5 se ocupan de esto. Por supuesto, no es posible automatizar todos los cambios necesarios para acelerar — se requiere un análisis manual y optimización. Por ejemplo, la eliminación de código no utilizado o duplicado se clasifica como una tarea manual.

Por lo general, todas estas optimizaciones se gestionan mediante configuraciones y las más peligrosas están desactivadas por defecto.

Soporte de capacidades de aceleración por tipos de CDN

Así que, veamos qué oportunidades potenciales de aceleración ofrecen los diferentes tipos de CDN.

Para mayor comodidad, repetimos la clasificación.

1. CDN gratuitos para la distribución de bibliotecas JS (MaxCDN, Google, Yandex).
2. CDN de servicios de optimización del cliente (por ejemplo, Google Fonts para fuentes, Cloudinary, Cloudimage para imágenes).
3. CDN para recursos estáticos y optimización en CMS (disponibles en Bitrix, WordPress y otros).
4. CDN de uso general (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN para acelerar sitios web (Cloudflare, Imperva, Airy).

Ahora emparejemos las características y tipos de CDN.

Posibilidad
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compresión de texto
+–
–
+–
+–
+

Cabeceras de caché
+
+
+
+
+

Imágenes
–
+–
+–
–
+

TLS
–
–
–
+–
+

Retrasos
–
–
–
+
+

Contenido
–
–
–
–
+

En esta tabla, se utiliza «+» para indicar soporte completo, «–» para indicar ausencia y «+–» para indicar soporte parcial. Por supuesto, pueden haber discrepancias de esta tabla en la realidad (por ejemplo, algún CDN de propósito general podría implementar características para optimizar imágenes), pero es útil para una idea general.

Resultados

Espero que al leer este artículo, tenga una imagen más clara respecto a la recomendación de «usar CDN» para acelerar sitios web.

Como en cualquier cosa, no hay que confiar en las promesas de marketing de ningún servicio. El efecto debe medirse y verificarse en condiciones reales. Si ya está utilizando algún CDN, verifique su eficacia en función de los criterios descritos en el artículo.

Es posible que el uso de un CDN en este momento esté ralentizando la carga de su sitio web.

Como recomendación general, se puede optar por lo siguiente: estudie su audiencia y defina su ámbito geográfico. Si su audiencia principal se concentra en un radio de 1-2 mil kilómetros, no necesita un CDN para su propósito principal: reducción de retrasos. En su lugar, puede ubicar su servidor más cerca de los usuarios y configurarlo adecuadamente, obteniendo la mayoría de las optimizaciones descritas en el artículo (de forma gratuita y constante).

En el caso de que tu audiencia esté realmente distribuida geográficamente (a más de 3000 kilómetros de distancia), utilizar una CDN de calidad será realmente útil. Sin embargo, es importante entender de antemano qué podrá acelerar realmente tu CDN (ver tabla de capacidades y su descripción). Acelerar un sitio web sigue siendo una tarea compleja, que no se resuelve simplemente conectando una CDN. Además de las optimizaciones mencionadas, las herramientas más efectivas para acelerar un sitio siguen siendo: optimización del servidor, modificaciones avanzadas en la parte del cliente (eliminación de código no utilizado, optimización del proceso de renderizado, trabajo con contenidos, fuentes, adaptabilidad, etc.)

Fuente: habr.com