CloudFlare CDN: ¿cuánto acelera la descarga de tu WordPress?

Tabla de contenidos

1. Prefacio
2. Breve introducción a los CDN’s
3. CloudFlare, un CDN al alcance de todos
   • Crear y configurar una cuenta CloudFlare
   • Buenas Prácticas de configuración con WordPress y CloudFlare
4. Efectos de CloudFlare en la velocidad de nuestra web
   • Pero… ¿cómo saber si CloudFlare está operativo?
   • CloudFlare en Pingdom Tools
   • CloudFlare en WebPageTest
   • CloudFlare en GTMetrix
5. Efecto de CloudFlare en los accesos distantes
6. Conclusiones

Prefacio

Hace poco publiqué una serie de artículos sobre optimización de WordPress para acelerar el tiempo de respuesta del servidor y mejorar el índice de Google PageSpeed Insights.

En los dos artículos de esta serie se cubrieron diversos aspectos de optimización, desde los más evidentes, como la compresión de imágenes o los plugins de WordPress, hasta otros menos conocidos, como la optimización de la Base de Datos o la minimización de ficheros. También se hacía referencia a la posible utilización de CDN’s para reducir el tiempo de descarga de una página web completa.

En ese momento desestimé la incorporación de un CDN en mi sitio web: ya tenía resultados bastantes buenos (PageSpeed de 90 para móviles y 96 para ordenadores, así como buenas puntuaciones en GTMetrix y Pingdom) y la mayoría de la información técnica que había leído sobre los CDN’s coincidían en que no ofrecían ventajas significativas para webs que no tuvieran muchas visitas (del orden de miles) o que estuvieran dirigidas a un público local (es decir, sin visitas desde otros países).

Sin embargo, animado y motivado por los comentarios de RaMGoN en ese mismo artículo y de intercambiar comentarios con Víctor Campuzano, que había instalado KeyCDN en su blog, decidí investigarlo por mi cuenta y comprobar hasta qué punto los CDN’s no eran aplicables para sitios webs sin alto número de visitas.

Este artículo, querido lector, querida lectora, es el resultado de dicha investigación…

 

Breve introducción a los CDN’s

Si has llegado hasta aquí, significa que estás interesado en los CDN’s y, probablemente, ya sepas en qué consiste. De todas formas, para que todos estemos en la misma onda y para aquellos que sólo han oído hablar de los CDN’s, voy a describir brevemente en qué consiste y cuál es su utilidad.

CDN son las siglas de “Content Delivery Network” y proporciona una infraestructura de servidores repartidos alrededor del mundo para almacenar los recursos estáticos de nuestro sitio Web (fundamentalmente, imágenes, hojas de estilo y ficheros JavaScript), de forma que cuando un usuario visita la web, estos ficheros se descargan desde los servidores de la red CDN y no desde nuestro servidor de hosting.

Al integrar un CDN con nuestro servidor de alojamiento conseguimos:

• Que nuestro servidor de alojamiento no tenga que entregar dichos ficheros al navegador del usuario. Esto, por un lado, lo libera para enfocarse en lo que realmente importante que tiene que hacer (generar las páginas dinámicas de nuestro sitio web); y, por otro, aumenta el número de descargas paralelas, puesto que se realizan desde varios servidores: el nuestro y el del CDN.
• Que nuestros usuarios de otras partes del mundo tengan acceso más rápido a nuestra web. Como los servidores del CDN están repartidos por toda la geografía mundial, cuando un usuario entra en nuestra página, será atendido por el que esté más cerca de él físicamente, mejorando sustancialmente los tiempos de descarga y navegación.
• Mayor tolerancia de errores. Si el servidor CDN más próximo sufre una avería o está sobrecargado, el proveedor automáticamente remite al siguiente más cercano, de forma totalmente transparente para el usuario.

Por sus características, tradicionalmente se ha considerado que la utilización de un servicio CDN sólo tiene sentido:

• Con un alto número de visitas, para evitar que el servidor de hosting pueda quedarse sin suficientes recursos para atender todas las visitas en un tiempo razonable (del orden de 1 segundo…).
• Con un porcentaje significativo de usuarios extranjeros, que se beneficiarían de la ventaja de disponer de un servidor geográficamente cercano que les atendería más rápidamente que nuestro servidor de hosting.

Ahora bien, ¿son ciertas estas condiciones? Un sitio Web con varias decenas o centenares de visitas diarias, o con pocos visitantes de otros países, ¿no podría beneficiarse de las ventajas de un CDN?

Para responder a estas preguntas, y quizás otras que estén ahora pasando por tu mente, primero vamos a instalar y configurar un CDN, CloudFlare, y enlazarlo con un sitio web operativo, con un volumen de visitas que ronda las varias decenas diarias, con picos por encima de la centena.

Seguidamente, utilizaremos este entorno como banco de pruebas para testear y analizar con diversas herramientas de medición cómo afecta a los tiempos de carga la utilización del CDN, comparándolos con los tiempos de carga usando exclusivamente el servidor de hosting. De esta forma podremos cuantificar el beneficio, si lo hubiera, que proporciona al sitio web.

 

CloudFlare, un CDN al alcance de todos

CloudFlare, junto con KeyCDN y MaxCDN, probablemente sea uno de los proveedores CDN más conocidos. Quizás el hecho de que ofrezcan un plan gratuito influya, pero por muy gratuito que sea un producto o servicio, si no ofrece calidad ni cubre una necesidad de los usuarios, difícilmente se difundirá ni perdurará en el tiempo.

Precisamente la existencia de este plan gratuito lo convierte en la mejor plataforma de lanzamiento para muchos propietarios de sitios web que quieren probar la tecnología CDN durante un tiempo antes de dar el paso a planes CDN más amplios cuando lo necesiten.

En este sentido, la facilidad de instalación y configuración de CloudFlare juegan en su favor; no es que el resto de proveedores CDN’s sean complicados, sino que en el caso de CloudFlare es MUY fácil… Porque, en el fondo, CloudFlare no es un CDN puro en el sentido estrictamente técnico de la palabra.

Aunque CloudFlare comparte la misma idiosincrasia que los CDN’s tradicionales (a saber, descargas de ficheros estáticos desde una red mundial de servidores), su operativa difiere en varios puntos:

• Los servidores CloudFlare responden directamente a todas las peticiones desde los navegadores a nuestro sitio web, actuando como intermediario de nuestro servidor de hosting.
• El funcionamiento del servidor CloudFlare es transparente para el servidor de alojamiento, que no necesita ninguna configuración especial para que el sitio web siga a pleno rendimiento (hay una excepción para un caso muy concreto, que veremos más adelante, pero que no afecta en nada al funcionamiento del CDN como tal).
• Aunque los ficheros estáticos están almacenados en los servidores CloudFlare, su dirección “real” (URL) sigue siendo la misma que si estuvieran en el servidor de alojamiento. En otras palabras, no hay que crear subdominios ni nada parecido.

En este sentido, los servidores de la red CloudFlare funcionan de forma similar a los tradicionales servidores proxies, como repositorios de ficheros que actualizan su contenido cuando los ficheros originales son modificados o cada cierto tiempo.

Esta característica tiene sus ventajas e inconvenientes:

Ventajas

• Configuración muy sencilla a través del panel de CloudFlare.
• No hay que configurar prácticamente nada en WordPress o cualquier otro gestor de contenidos.
• Libera a nuestro servidor de alojamiento no sólo de servir imágenes, sino también de muchos otros tipos de ficheros estáticos: todos se sirven desde los servidores de CloudFlare.
• Al funcionar como un proxy, todo el tráfico pasa primero a través de él y puede proporcionar mecanismos adicionales de seguridad y protección.
• Las estadísticas de descargas de nuestro servidor de alojamiento reflejarán menos tráfico, dado que gran parte lo absorben los servidores de CloudFlare. En otras palabras, consumiremos menos ancho de banda y recursos de nuestro hosting.

Inconvenientes

• No es un CDN puro, sino un proxy (servidor intermedio que cachea las páginas), lo que significa que tenemos que cambiar nuestros servidores de nombre («nameservers»).
• Al funcionar como una caché, ningún cambio de nuestro sitio web será visible hasta que CloudFlare recargue la página afectada (se puede soslayar parcialmente en la configuración de CloudFlare).
• Hay que ser cuidadoso con la configuración de seguridad en CloudFlare: si es demasiado estricta, podemos provocar falsos positivos y perder visitas legales.
• Al activar el servicio, hay que esperar a que se propaguen los cambios de los servidores de nombres (hasta dos días en el peor de los casos).

 

Crear y configurar una cuenta CloudFlare

Veamos ahora paso a paso como crear una cuenta CloudFlare para un sitio web, tomando como ejemplo éste que estáis leyendo 🙂

1. Entra en https://www.cloudflare.com/a/sign-up y crea una cuenta con tus datos.
2. Nada más crearla, debes proceder a añadir tu sitio web. No tienes que hacerlo ahora, pero mientras no lo hagas, no puedes usar el servicio CDN de CloudFlare. Si quieres, puedes añadir más de uno, separados por comas, pero te aconsejo que lo hagas de uno en uno, al menos hasta que te familiarices con todo el proceso de configuración:

3. Cuando pulsas “Scan DNS Records”, CloudFlare escanea los registros DNS (servidor de nombres de dominio) de tu sitio web. Este proceso lleva alrededor de un minuto, así que te ofrecen un breve vídeo explicativo (en inglés) para amenizar la espera. Pulsa “Continue” cuando termine el escaneo:

4. Aparece una lista de los registros DNS que CloudFlare ha detectado en tu web. En general, CloudFlare los detecta bien (es información pública, si se sabe dónde buscar, así que debería encontrarlos todos): lo que salga dependerá mucho de tu proveedor y de tu web. A no ser que domines el tema de los registros DNS, marca SOLO las dos filas correspondientes a tu servidor web: una con el tipo “A” y con tu dirección como nombre; y la otra con el tipo “CNAME” y con “www” como nombre. Para marcarlas, pincha en la nube de la derecha para que se ponga de color naranja:

5. Esto ya está casi terminado. Pulsa “Continue” y ahora selecciona el plan de pago. Yo he decidido que voy a dejar para más adelante el de 5.000 euros mensuales, y el de 200, y el de 20…:

6. Pulsa “Continue” y ya casi estás… Si tu proveedor tiene un acuerdo con CloudFlare, este paso lo hace automáticamente. Si no, te muestra tus nuevos servidores de nombre. Toma nota de ellos, tanto de los actuales (a la izquierda), como de los nuevos (a la derecha), aunque CloudFlare te envía un correo con ellos por si acaso:

7. Ahora debes actualizar los servidores de nombres (nameservers) en tu proveedor de registro de dominios (que, normalmente, coincide con el de hosting, pero no tiene porqué). Este punto depende de cómo sea el entorno de configuración de tu proveedor, pero sería algo parecido a esto:

Después de modificar quedaría algo como:

No te preocupes por las direcciones IP: el sistema las detecta y asigna automáticamente.

8. Sécate el sudor de la frente y tómate un refrigero, acabas de superar la parte más difícil 🙂
9. Cuando pulsas “Continue” en la última pantalla de CloudFlare (punto 6), te aparece el panel de control, con tus nuevos nameservers, la configuración por defecto y tu plan de suscripción. Hasta que no actualices correctamente los «nameservers» (punto 7), CloudFlare no activará el servicio. Pulsa “Recheck nameservers” para que CloudFlare los compruebe:

10. Normalmente, no hace falta esperar más que unos minutos para que CloudFlare active con éxito tu nuevo servicio CDN:

 

Ahora bien, el que esté activo no significa que a partir de ese momento todas las visitas se harán a través del CloudFlare. Debido al modo de funcionamiento de CloudFlare, los cambios que hemos hecho en los servidores de nombres (nameservers) deben propagarse a todos los servidores DNS de Internet. Este proceso puede durar hasta 24 horas o incluso más.

A través de la página whois.net puedes comprobar si los servidores de nombre ya están actualizados en el registro DNS, pero aún así son necesarias al menos 24 horas para que se propaguen a través de todo Internet:

De todas formas, como el cambio es totalmente transparente tanto para ti como para el sitio web, da lo mismo que sea en dos minutos que en dos horas: a medida que los cambios de nameservers se vayan propagando, los accesos a tu web se irán haciendo tanto a través de CloudFlare como directamente al servidor de hosting.

Pero, repito, no tienes que preocuparte de nada: todo eso se hace solo. La única diferencia que notarás cuando todo termine es que tu web descargue un poco más rápido (o eso espero).

 

Buenas Prácticas de configuración con WordPress y CloudFlare

Aunque anteriormente he mencionado que no es necesario cambiar ni configurar nada en WordPress para que funcione con CloudFlare, sí que es aconsejable aplicar algunas buenas prácticas en ambas plataformas para sacar el máximo rendimiento y evitar posibles conflictos que desbaraten nuestra web.

1. Incluye CloudFlare en tu lista blanca de direcciones IP

Como hemos mencionado, la dinámica de CloudFlare asemeja a la de un proxy. Esto significa que, una vez activo y operativo, todas las visitas a nuestro sitio web llegarán a través de los servidores de CloudFlare: unas las atenderá el propio servidor de CloudFlare, mientras que otras las pasará a nuestro servidor de hosting.

Como consecuencia, nuestro servidor de alojamiento verá que recibe muchas visitas desde un conjunto limitado de direcciones IP. Con varios centenares de visitas diarias no debería haber ningún problema, pero a medida que aumente el volumen de visitas, nuestro servidor de alojamiento puede considerar que son fruto de algún ataque o spamming.

Para evitar malentendidos en este aspecto, si nos movemos en el rango de las miles de visitas, deberemos añadir las direcciones IP de la red CloudFlare en la lista blanca (“whitelist”) de nuestro servidor de Hosting, para que nunca las califique erróneamente como perniciosas (en otras palabras, que no las meta en una lista negra).

Igualmente, debemos asegurarnos que en nuestro fichero «.htaccess» no estemos restringiendo el acceso desde servidores de CloudFlare. Si no sabes qué es este fichero o nunca lo has tocado, no te preocupes: tu proveedor habrá dejado el «.htaccess» por defecto, que no debería afectar a CloudFlare en modo alguno.

2. Revisa la configuración de rendimiento

La configuración de rendimiento se hace a través de dos iconos del panel de control de CloudFlare:

En general, no hace falta modificar la configuración por defecto de ninguna de las dos y no deberías cambiarlas salvo que tengas muy claro para qué lo haces. De todas formas, si te equivocas, tu sitio web está a salvo, pues se aplican exclusivamente en CloudFlare, por lo que revirtiendo la configuración todo volverá a funcionar normalmente.

El uso más habitual que haremos de la configuración de Caching será para borrar la caché (es decir, la copia de nuestros ficheros que CloudFlare tiene en sus servidores) y que se recarguen desde nuestro sitio web, o para entrar en Modo Desarrollo (Development Mode), que desactiva temporalmente la caché (hasta un máximo de 4 horas) por si estamos haciendo modificaciones en la web y las podamos ver en tiempo real.

La configuración de Velocidad (“Speed”) tiene pocas opciones para el plan gratuito (qué sorpresa…): Auto Minify y Rocket Loader. Si ya utilizas WordPress con algún plugin de minimización de ficheros CSS, JS o HTML, en ningún caso actives Auto Minify: puede haber conflictos entre ellos.

Por su parte, Rocket Loader tiene buena pinta; acelera los tiempos de carga para páginas con código JavaScript, pero está en beta y yo no me metería en ese fregado. Siempre puedes probar a ver qué pasa… pero revisa bien TODA tu web, incluida la página de administración.

3. Revisa la configuración de seguridad

De nuevo, la configuración por defecto se adapta a la mayoría de los casos, pero conviene saber en qué consiste la página de desafío (“Challenge Page”) y cómo controlarlo.

Dado que todo nuestro tráfico pasa a través de los servidores de CloudFlare, éste nos ofrece un servicio de protección contra ataques a través de su firewall. Si detecta un visitante que puede suponer una amenaza, le presenta una página de desafío (en esencia, un capcha) para determinar si es un usuario humano o un bot con malas intenciones.

Salvo que estemos en riesgo de sufrir ataques, con dejar el nivel de seguridad (“Security Level”) en su nivel medio tenemos más que suficiente.

4. Instala el plugin de CloudFlare en WordPress

“Pero, Antonio, ¿no había dicho que habías dicho que no hacía falta configurar nada en WordPress?”… Y es cierto: no hace falta para que CloudFlare funcione a pleno rendimiento, pero esa dinámica proxy de CloudFlare produce un efecto secundario en los comentarios de nuestro blog: todos parecerían haber sido realizados desde la misma dirección IP.

No es que sea algo grave, pero si tienes instalado un plugin anti-spam, puede interpretar (a la larga, lo hará) que los comentarios son spam por venir todos de la misma IP. Con el plugin de CloudFlare se repone la dirección IP a cada comentario y evitamos este problema. Si no tienes blogs o no habilitas los comentarios, evidentemente no necesitas este plugin.

5. No modifiques nada de tus plugins compatibles con CDN’s

Plugins como Autoptimize o WP Super Cache incorporan opciones de configuración especiales para CDN’s. Sin embargo, como CloudFlare no es un CDN tradicional ni hace falta crear un nombre de zona para tu web, no debes cambiar la configuración de ninguno de ellos.

6. Crea una regla de página para la administración de tu web

MUY IMPORTANTE: si no haces esto, es posible que tu gestor de contenidos no funcione.

Con CloudFlare, todos los accesos a nuestro sitio web se hacen a través de sus servidores… incluidos los de la página de administración (“wp-admin” en WordPress)… ¡No queremos esto!

Lo que queremos es que CloudFlare no cachee la página de administración ni interfiera de ninguna forma en su funcionamiento (por ejemplo, Rocket Loader o Auto Minify pueden afectarle).

Para evitar efectos perniciosos, debemos crear una regla de página (“rule page”) en el panel de control de CloudFlare, tal como se muestra a continuación:

Cuando añadamos la regla de página, debemos poner la opción “Custom Caching” con el valor “Bypass Cache”, y las siguientes opciones con el valor “Off”: Apps, Performance y Security.

En el cuadro de texto “URL pattern” debemos poner la dirección URL de nuestra página de administración (sin las “www”), rodeado por asteriscos, para indicar a CloudFlare que no intercepte ninguna página cuya dirección contenga este patrón.

 

Efectos de CloudFlare en la velocidad de nuestra web

Bien. Ya hemos repasado un poco algunos conceptos teóricos sobre los CDN’s, aclarado que CloudFlare no es un “CDN” tradicional en el sentido literal de la palabra, y creado y configurado una cuenta CloudFlare para nuestro sitio Web… Pero, lo realmente importante, ¿cuánto es el impacto de utilizar CloudFlare en la velocidad de descarga de nuestra Web?

Para valorarlo, nos valdremos de varias herramientas de medición, antes y después de activar CloudFlare, para comparar la ganancia (o pérdida… todo es posible; hay que mantener la mente abierta) en el tiempo de descarga y en las respectivas puntuaciones. Entre ambas pruebas dejé pasar casi cuatro días, para estar seguros que los nuevos nameservers estuvieran bien propagados.

¿Porqué varias herramientas?, podéis preguntaros. En la velocidad de descarga de una página web intervienen muchos factores, no sólo el tiempo de respuesta del servidor (por ejemplo, el estado de saturación de tráfico de una línea de conexión o de un router a mitad de camino), por lo que casi siempre obtendremos valores distintos. La mayoría dentro de una horquilla, pero puede haber valores extremos, tanto por arriba como por abajo, que nos pueden llevar a conclusiones erróneas si sólo hiciéramos esa medición.

Así que incluiré comparaciones de los análisis de Pingdom, GTMetrix y WebPageTest (ya adelanto que éste tiene una característica muy interesante). Además de las valoraciones finales, para cada uno de ellos también mostraré el gráfico en cascada («waterfall») antes y después de CloudFlare, que muestra cómo se descargan y en cuánto tiempo cada elemento de la página web, como detalle curioso para ver cómo resulta afectada la descarga al utilizar CloudFlare.

¿Y por qué no Google PageSpeed Insights? Bueno, porque después de activar CloudFlare… sigue arrojando exactamente los mismos valores para móviles y ordenadores. No me ha sorprendido mucho porque, desde mi punto de vista, Google no tiene en cuenta en esta valoración si nuestra web es igual de rápida para un asiático, un europeo o un americano: sólo quiere que sea rápida y lo mide desde el servidor más cercano a nuestro propio servidor de Hosting. En una web con intenso tráfico, probablemente sí se notaría el efecto de que el contenido estático se descargara desde otro servidor.

 

Pero… ¿cómo saber si CloudFlare está operativo?

Un problema de utilizar CloudFlare es que al principio no hay un método infalible para asegurarnos que CloudFlare está funcionando a pleno rendimiento en todo el mundo, más que dejar pasar varias horas, incluso más de un día.

Sí, tenemos el panel de control de CloudFlare, tanto la Web o el plugin de WordPress, que nos dice si está activo o no. Sin embargo, dado que el modo de funcionamiento de CloudFlare se basa en la modificación y propagación de los servidores de nombres («name servers»), es necesario que este cambio se propague a los servidores alrededor del ancho mundo para que sea 100% efectivo desde cualquier punto.

Esta propagación, para colmo, no es uniforme: habrá servidores que les llegue el cambio a los pocos minutos, mientras otros pueden tardar hasta dos días (como indica GTMetrix en su FAQ).

Por tanto, la recomendación general es esperar al menos 24 horas antes de empezar a hacer pruebas de velocidad. Aún así, os podéis encontrar con un comportamiento curioso, tal como me ocurrió a mí: haciendo las pruebas con Pingdom, el servidor de Estocolmo ya tenía los nuevos servidores de nombre de mi Web a las pocas horas, pero el de Amsterdam aún utilizaba los anteriores casi dos días después.

Esto mismo puede ocurrir con el resto de herramientas de medición, por lo que es importante saber si la herramienta está utilizando o no el servidor de CloudFlare durante su análisis. Veremos cómo hacerlo con cada herramienta.

Tened en cuenta que esto mismo puede estar pasando con vuestro proveedor de conexión; es decir, que siga utilizando los antiguos servidores de nombre. Seguramente, lo primero que haréis después de activar CloudFlare es probar vuestro sitio web… ¡y os llevaréis la decepción de que tarda prácticamente lo mismo que siempre!

A través de la línea de comandos de Windows podemos utilizar esta instrucción para saber si nuestro proveedor ya tiene los nuevos servidores de nombre:

tracert midominio.com

Windows ejecuta esta instrucción a través de nuestro proveedor de conexión, con el servidor de nombres que éste tenga. En mi caso, esto es lo que obtenía los dos primeros días después de activar CloudFlare:

Observad la última línea, la que empieza por ‘12’: ¡aún aparece mi anterior servidor de nombres, “.webempresa.eu”! Ahí debería aparecer uno de los servidores de nombres de CloudFlare. Además, en esa misma línea entre corchetes aparece la dirección IP original de mi nombre de dominio, cuando debería ser otra, la nueva que los servidores de nombre de CloudFlare asocian con mi dominio.

En cambio, haciendo el trazado de la ruta con la herramienta online https://centralops.net/co/Traceroute.aspx, sí que obtengo una dirección IP distinta:

La dirección IP del último paso (104.28.5.97) es la IP con que CloudFlare atiende las peticiones a mi sitio web. En este caso, mi nombre de dominio está resolviendo a la nueva IP, como debe ser.

Quizás penséis que debería estar molesto con mi proveedor… no realmente, CloudFlare es americano, por lo que supongo que es normal que a un servidor americano (como CentralOps.net) le llegue antes la propagación de los nuevos servidores de nombre.

Si tenéis curiosidad por saber qué ruta siguen las conexiones hasta vuestro sitio web a través de Internet, esta herramienta gráfica online las muestra sobre un mapa desde varias localizaciones (USA, Europa, Asia). A mí me ha permitido observar que un usuario americano necesitaba 25 saltos (“hops”) para conectar con mi sitio web sin CloudFlare (es decir, con la dirección IP original), y 15 con CloudFlare (con la nueva dirección IP). Ya hemos ganado algo por ahí para mis fans americanos…

 

CloudFlare en Pingdom Tolls

Antes…

En la puntuación de Pingdom (85/100), tal como vimos en el segundo artículo sobre optimización, está pesando mucho el tamaño de una petición (“request”) desde la página, que ocupa más de un paquete (lo que significa que navegador y servidor debe intercambiarse más paquetes), pero puedo asumirlo porque beneficia la puntuación de Google PageSpeed.

El tiempo de descarga es bastante rápido, menos de 7 décimas de segundo, y un tamaño de página no demasiado grande, a pesar de haber cuatro grandes imágenes (los sliders), cuatro de tamaño medio (los posts más recientes) y seis de pequeño tamaño, además de casi una docena de iconos.

Veamos la gráfica en cascada:

He ordenado esta representación por tamaño de fichero, para observar mejor cómo se distribuye la carga entre los ficheros más grandes y que, por tanto, más afectan al tiempo de descarga.

En esta gráfica, destaca que todas las imágenes grandes se descargan en apenas dos décimas de segundo, mientras que la descarga de la página principal, con solo 11,8 kB, necesita casi cuatro décimas. Dado que es una página dinámica, corresponde al tiempo que el servidor necesita para generarla; en este punto, la optimización de la base de datos y de los plugins resulta crucial para reducir este tiempo todo lo posible. Cabe mencionar que las imágenes no se descargan hasta que la página se descargue completamente, lo cual es lógico, pues el navegador no empieza a interpretarla hasta que no la tenga entera.

Después…

Después de dejar pasar varios días, para asegurar que no habría problemas con la propagación de los servidores de nombres, esto es lo que obtengo:

Vaya, dos décimas más rápido… No está mal. Por si acaso, lo ejecuté varias veces y, en general, resultaba entre uno y dos décimas más rápido que sin CloudFlare.

Veamos ahora la representación en cascada:

Parece que se confirma la suposición que hicimos en el “Antes…” sobre la descarga y generación de la página principal: con CloudFlare también necesita cuatro décimas, lo que confirma que es independiente de la conexión y que es el proveedor de hosting el que usa ese tiempo para generarla. Observaréis también que es un poco más grande, 12,7 kB: algunos pequeños cambios que hice desde que hice el test del “Antes…” (¿no me iba a quedar solo mirando a la pantalla, verdad? 😉 )

EL punto más llamativo es que las imágenes grandes necesitan ¡apenas media décima de segundo! para descargarse todas… ¡¡Impresionante!!

En fin, el primer resultado parece prometedor: ¡casi un 30% de mejora!

Pero, ¡ay!, ¿estamos seguros que estamos accediendo a través de CloudFlare y que no estamos ante un espejismo? Pingdom no nos dice de forma directa si ha accedido a nuestra web a través de CloudFlare, pero podemos sacar esta información de las cabeceras de respuesta que se muestran en la gráfica en cascada. Pinchando en el signo “+” de una de las filas, obtenemos algo así:

Y ahí lo tenemos: dos campos en la cabecera de respuesta generados por CloudFlare. El Server puede variar, pero si el campo “CF-Cache-Status” es igual a “HIT” significa que la página ha pasado por CloudFlare, según la documentación técnica de CloudFlare.

 

CloudFlare en WebPageTools

Esta herramienta de medición tiene una particularidad, de la que carecen las otras dos: puede repetir el test varias veces, mostrando el resultado mediano (no el valor medio). Por tanto, no es necesario que seamos nosotros quienes tengamos que repetir el test para obtener valores más reales, como hicimos con Pingdom.

Además, también puede mostrar dos valores: el de la primera vista, simulando un acceso por primera vez a la página; y el de la vista repetida, simulando un segundo acceso a la página y, por tanto, utilizando el caché del navegador. Para el caso que nos ocupa, este dato de la vista repetida debería similar con o sin CloudFlare, dado que el navegador no descarga nada, solo comprueba si la caché está actualizada (salvo que deshabilitemos la caché del navegador).

Antes…

Llama la atención que el tiempo de descarga varíe tanto con respecto a Pingdom, casi el doble, pero debemos recordar que las herramientas realizan los tests desde servidores propios, con distintas líneas de conexión y estructura de red; por tanto, cabe esperar algunas diferencias. Lo importante, y lo que debemos analizar, son las diferencias que observemos con la misma herramienta desde el mismo servidor.

Dado que ésta es la principal ventaja de los CDN’s, que dependiendo desde donde se haga la petición al sitio web, responde el servidor CDN más cercano, en cada caso deberíamos obtener el mejor resultado posible. Sin embargo, me sigue pareciendo una diferencia demasiado grande entre ambas herramientas, máxime cuando para Pingdom he seleccionado su servidor de Suecia y para WebPageTest, el suyo de París, muy cercanas entre sí.

Veamos ahora la cascada de peticiones y descargas:

Esta herramienta no permite ordenarlas por tamaño de fichero, así que la cascada se muestra por orden de descarga, que coincide con el orden en que el navegador encuentra los distintos ficheros al leer la página HTML.

La generación y descarga inicial de la página no llega de tres décimas, menos que en Pingdom, pero a partir de ahí hay diferencias mucho más significativas entre ambos. La más evidente: mientras que Pingdom mostraba que las imágenes se descargaban en menos de una décima de segundo cada una, en WebPageTest muchas superan las tres décimas. Este comportamiento se repite en todas las ejecuciones del test.

Esta diferencia tan abultada no se puede imputar al uso de distintos servidores por cada herramienta. Más bien parece apuntar al algoritmo que una y otra utilizan para medir los tiempos de descarga; por ejemplo, ¿cómo considera cada una de ellas cuando empieza y termina la descarga de un fichero? No encuentro otra explicación para tanta diferencia. En cualquier caso, está visto que la comparación de los resultados entre distintas herramientas no es fiable.

Después…

En este caso, la ganancia en el tiempo total de descarga es menor que con Pingdom, alrededor del 15% para la primera vista, mientras que la vista repetida es prácticamente la misma, lo que es normal puesto que el navegador sólo tiene que hacer una petición de comprobación con el servidor.

Además, podemos ver que el primer byte se descarga y la página se empieza a renderizar casi al mismo tiempo que sin CloudFlare; tiene sentido: en realidad, en ese punto todavía no se ha hecho ninguna descarga como tal desde los servidores de CloudFlare, tan solo la petición al servidor y la descarga de la página principal, que, al ser dinámica, se hace desde el servidor de hosting. Incluso es posible que el primer byte tarde más con CloudFlare, puesto que hay dos peticiones: del navegador al servidor de CloudFlare y del servidor de CloudFlare a nuestro servidor de hosting para que sirva la página dinámica.

En la representación en cascada, tampoco se observa tanta diferencia durante las descargas de las imágenes como con Pingdom. En general, con CloudFlare es algo más rápido, pero tampoco como para tirar cohetes:

En conclusión, WebPageTest nos da también a la opción con CloudFlare como ganador, aunque con menor margen que Pingdom, posiblemente debido a que utiliza otros servidores para lanzar el test, con diferentes conexiones y estructuras de red, y al diseño de su algoritmo de testeo.

Finalmente, como habréis observado en las imágenes, aquí no hay problema para saber si CloudFlare está operativo: nos los muestra bien claramente en la esquina superior derecha. Pero también podemos  asegurarnos en la gráfica en cascada, pinchando en el signo “+” de las cabeceras y mirando el campo “CF-Cache-Status”:

 

CloudFlare en GTMetrix

Antes…

No son malos valores, aunque el PageSpeed Score se queda un poco descolgado. De nuevo, vemos que el tiempo de descarga no coincide ni con Pingdom ni WebPageTest, pero con la peculiaridad que GTMetrix presenta las mayores variaciones, desde 1.0 segundos hasta 1.7, así que he tomado aproximadamente el valor mediano como más representativo. Curiosamente, el PageSpeed Score y el YSlow Score casi siempre eran estos mismos, excepto para descargas a 1.0 segundos, que aumentaban en un punto cada uno.

De nuevo, en este caso es fácil determinar si está operativo el CDN: GTMetrix nos lo muestra también directamente en la página de resultados.

Veamos la gráfica en cascada:

Tampoco se puede ordenar por tamaño de fichero, pero ya se puede ver que, en cuestión de los tiempos de descarga de cada recurso, es más parecida a la de WebPageTest que a la de Pingdom, aunque con tiempos mayores, superiores a la décima de segundo, donde en WebPage apenas llega a las 2-3 centésimas. Lo dicho, cada herramienta sigue su propio criterio a la hora de medir los tiempos de descarga.

Después…

Bueno, aquí mejoran las dos puntuaciones, sobre todo YSlow, y el tiempo de carga de la página se queda en algo menos, los 1.1 segundos. En este caso, este valor ha sido muy estable: alguna vez ha llegado a 0.9 segundos, pero nunca ha superado los 1.2 segundos. Por tanto, GTMetrix también evidencia que CloudFlare aporta mejoras al sitio web.

Veamos la representación en cascada:

Vaya, vaya, vaya… El mismo comportamiento que Pingdom: las descargas de los recursos estáticos se aceleran una barbaridad con CloudFlare; donde antes había décimas, ahora hay centésimas. Diríase que WebPageTest va un poco a su bola en este punto; ya sería cuestión de consultar en mucho más detalle su documentación técnica para intentar explicar esta disparidad.

Observad la flecha roja que ponga al final de la cascada: ese recurso estático es una imagen “emoji” (como ésta: 🙂 ). Pero fijaos cuándo se descarga: sólo necesita 7 ms, ¡pero pasa casi un segundo hasta que se descarga! ¿Por qué? Dado que estas imágenes se cargan con un JavaScript, probablemente haya alguna dependencia o bloqueo que impide que se ejecute antes. Hacía tiempo que estaba pensando en desactivar los emojis de WordPress (ya que no están optimizados) y meterlos a pelo en el texto. Después de ver esto, decididamente lo haré.

Aunque GTMetrix ya nos indica a través del panel que hay un CDN activado, también se puede comprobar a través de las cabeceras de respuesta en la vista de cascada, de la misma forma que con las otras dos herramientas:

Por tanto, pleno de tres: con CloudFlare nuestro sitio web carga más rápido que sin él, con una ganancia de entre 15% y 30%… ¡La vida puede ser maravillosa!

 

Efecto de CloudFlare en accesos distantes

De acuerdo, ya hemos visto que CloudFlare acelera nuestro sitio web, pero, la pregunta del millón: ¿también se notan sus beneficios cuando nuestro usuario de Tokyo o Sydney visita nuestra página? Después de todo, esa es una de las principales ventajas que nos venden de los CDN’s (vale, CloudFlare no es un CDN puro, pero a estos efectos se puede considerar que sí).

Bueno, no tenemos porqué quedarnos con la duda: tenemos tres maravillosas herramientas de medición que nos pueden ayudar a resolverlo. Veamos cómo…

En primer lugar, utilizaremos una característica del panel de control de CloudFlare, que nos permite activarlo/desactivarlo sin tener que cambiar ninguna configuración, encargándose CloudFlare de reajustar adecuadamente las direcciones IP que correspondan (como podéis comprobar vosotros mismos trazando la ruta a través de https://centralops.net/co/Traceroute.aspx):

Dándole al botón «Pause», desactivamos temporalmente CloudFlare en nuestra web, hasta que lo volvamos a pulsar.

Puesto que estas herramientas nos permiten seleccionar el servidor desde realizan sus tests, podemos utilizar esta característica para simular visitas desde lugares distantes a nuestra web, con y sin CloudFlare. Como no quiero alargar más este post (¿he oído algún bostezo?), sólo usaré WebPageTest y mostraré los tiempos obtenidos. El resto de análisis lo dejo como ejercicio para casa 😉

Esta es el test que ejecutaremos en WebPageTest:

Es decir, estoy simulando un acceso desde la lejana Sydney, Australia, al otro lado del mundo (desde donde me encuentro yo, claro).  Además, lo haremos tres veces, para reducir la influencia de fenómenos extraños.

Estos son los tiempos obtenidos SIN CloudFlare:

Y estos son los resultados CON CloudFlare:

¡Salta a la vista! CloudFlare, y por extensión, los CDN’s, mejoran los tiempos de descarga de nuestros visitantes lejanos, reduciéndolos a la mitad. Si os preguntáis porqué estos tiempos no son similares a los que hemos visto en las pruebas anteriores, recordad que los CDN’s alojan recursos estáticos, no las páginas dinámicas: éstas las tiene que seguir generando y entregando nuestro servidor de hosting.

Por tanto, ¡otro punto más para CloudFlare!

 

Conclusión

Las ventajas de los CDN’s son harto conocidas; la principal, reducir el tiempo de descarga de una página web. Sin embargo, su uso también está rodeado de algunas creencias generalizadas: sólo los sitios web con mucho tráfico web o visitantes foráneos pueden sacar provecho de estas ventajas.

Para comprobar el verdadero alcance de estas suposiciones, hemos utilizado un CDN muy popular y conocido, como CloudFlare, para un sitio web que (todavía 😉 ) no tiene miles de visitas diarias ni multitud de visitantes alrededor del mundo, con el fin de utilizarlo como banco de pruebas para medir los tiempos de descarga en diversas condiciones.

Aunque CloudFlare no es un CDN en el sentido tradicional del término, sino que comparte algunas características operativas con los proxies, constituye una excelente plataforma de entrada a esta tecnología, por su facilidad de instalación (mínima) y configuración (muy sencilla), aunque los resultados no son efectivos al 100% hasta pasadas un máximo de 48 horas (tiempo de propagación necesario para los cambios en los servidores de nombre).

Los resultados de las pruebas no pueden ser más concluyentes y positivos:

• Tres herramientas de medición distintas (Pingdom, GTMetrix y WebPageTest) arrojan un 15% y 30% de mejora en el tiempo de descarga de una página web, equivalente a entre 2 y 4 décimas de segundo.
• Los accesos distantes también reportan un beneficio sustancial en los tiempos de descarga, siendo aproximadamente la mitad cuando se utiliza el CDN CloudFlare con respecto al acceso directo al servidor de hosting.

Desde el punto de vista operativo, debemos tener en cuenta algunas consideraciones para integrar CloudFlare con nuestro sitio web:

• CloudFlare funciona como proxy, o intermediario, entre los visitantes y nuestro sitio web, cacheando las páginas de nuestro sitio web. Aunque esto mejora notablemente el rendimiento de nuestro servidor de hosting, también significa que cualquier cambio en una página no se verá hasta que CloudFlare la refresque o nosotros lo hagamos manualmente.
• Debemos seguir algunas buenas prácticas de configuración, de fácil ejecución técnica, tanto de nuestro gestor de contenidos como de CloudFlare, para conseguir una perfecta interacción entre ambos, sin interferencias que puedan producir errores en nuestras páginas.

En definitiva, no es necesario un sitio web con miles de recursos estáticos, miles de visitas y accesos distantes para disfrutar de las ventajas de un CDN (al menos, en lo que a CloudFlare se refiere), siendo CloudFlare una excelente plataforma para iniciarse, gracias a sus planes gratuitos, en esta prometedora tecnología.

Falta por determinar si CDN’s puros, como KeyCDN o MaxCDN, ofrecen resultados igual de positivos… pero esto, amigos y amigos, es historia para otro post 😉

Myth Busted!! No necesitamos un alto volumen de visitas para sacar provecho de los CDN, sino que su beneficio se observa ya desde la visita uno. ¿Te esperabas estos resultados? CloudFlare ofrece buenas prestaciones, pero ¿qué opinas de que funcione como un proxy? ¿Crees que es mejor un CDN tradicional?

Imágenes: CloudFlare, freepix, elaboración propia.