Los visitantes de tu sitio web odian tener que esperar a que se carguen las páginas, tanto en el escritorio como en los dispositivos móviles. Las páginas que tardan en cargarse pueden hacer que se vayan corriendo al sitio de la competencia. También te preocupa el impacto del rendimiento del sitio web en los resultados de las búsquedas.

En Kinsta, nos tomamos la velocidad muy en serio, y siempre buscamos que los sitios de nuestros clientes sean más rápidos.

La incorporación de Kinsta Edge Caching a nuestros planes de Alojamiento Administrado WordPress en diciembre de 2022 añadió nuevas herramientas para ayudar a los clientes a que las páginas de sus sitios web lleguen más rápido a los navegadores.

Al medir el time to first byte (TTFB), observamos un tiempo medio de respuesta en todas las pruebas de 207 milisegundos con el edge caching activado, frente a 402,59 milisegundos sin el edge caching. Esto supone un descenso de casi el 49%. Pero algunos de los sitios web del mundo real de nuestras pruebas obtuvieron resultados mucho mejores que ese, con rendimientos TTFB casi un 80% más rápidos con el edge caching. Más adelante profundizaremos en estas cifras.

Echemos un vistazo a cómo puedes mejorar el rendimiento de tu sitio web WordPress cuando una mayor parte de tu contenido está «en el borde»

¿Qué Es el Edge Caching?

Muchos de nuestros clientes de alojamiento de WordPress ya aprovechan nuestra integración con Cloudflare y sus servidores edge a través de la CDN Kinsta. Esta red de distribución de contenidos coloca los activos estáticos de un sitio – como imágenes, fuentes y archivos que contienen CSS y JavaScript – en ubicaciones 260+ de la red de Cloudflare en todo el mundo. Eso significa que esos activos están disponibles más cerca de la ubicación física de los visitantes de tu sitio web. Los trayectos más cortos para esos activos se traducen en una menor latencia de la red.

Utilisar el Edge Caching en el HTML de las páginas de WordPress es muy parecido a gestionar los activos en la CDN. La diferencia es que gestionar una caché de archivos como imágenes – que raramente cambian – es relativamente sencillo. Es más difícil gestionar el contenido que WordPress genera inicialmente de forma dinámica, que se almacena en caché como contenido estático y que luego se regenera cada vez que se edita el contenido.

¿Cómo Se Almacena el Contenido en la Caché Edge?

Las cachés edge se llenan con las peticiones de las páginas de tu sitio por parte de los navegadores. Si una página no está ya almacenada en la caché, la petición se pasa a tu sitio WordPress de origen, donde la página puede estar en la caché local o puede ser generada de nuevo por WordPress. La página se almacena en la caché de edge en el camino de vuelta al navegador. Las futuras peticiones en la misma ruta se beneficiarán de la caché hasta que se borre.

Así es también como se rellenan las cachés móviles. Si la solicitud de una página procede de un dispositivo móvil, el contenido se guarda en una caché móvil. (La caché móvil no distingue entre, por ejemplo, dispositivos iOS y Android. Las solicitudes procedentes de tabletas se agrupan con el contenido de escritorio)

Caché Local de WordPress y Caché Edge

Kinsta ofrece un enfoque libre de plugins para la caché local de WordPress en el propio servidor de tu sitio. La versión de Kinsta de Edge Caching mantiene esa simplicidad: los mismos pasos que has estado dando para limpiar tu caché local ahora también mantendrán sincronizada la caché edge.

Además, el panel de control MyKinsta incluye funciones para borrar la caché edge – y sólo la caché de edge – directamente.

Una novedad de la caché edge es la posibilidad de habilitar una caché para dispositivos móviles. Si tu sitio web genera marcas exclusivas para dispositivos móviles, puedes almacenar en caché ese HTML por separado del contenido para dispositivos de escritorio…

¿Es Kinsta Edge Caching lo Mismo que APO de Cloudflare?

Kinsta Edge Caching comparte la misma potente red de servidores de edge utilizada por el servicio Automatic Platform Optimization (APO) de Cloudflare. APO también está diseñado para proporcionar caché edge a los sitios de WordPress.

Esto es lo que diferencia a Kinsta Edge Caching:

Poniendo a Prueba Kinsta Edge Caching

Antes de lanzar oficialmente la función, invitamos a algunos de nuestros clientes a probar una versión Beta del nuevo servicio Edge Caching para recabar sus opiniones. Los sitios web reales de nuestros probadores Beta de todo el mundo proporcionaron el entorno perfecto para probar la velocidad de la tecnología.

Desde el centro de datos de Google conocido como us-central1 en Council Bluffs, Iowa, las herramientas automatizadas de nuestro equipo sondearon los sitios web de los probadores Beta y registraron los tiempos de respuesta para tres escenarios de almacenamiento en caché:

  1. Cuando se entrega una página desde la caché de un servidor edge de Cloudflare.
  2. Cuando una página no se encontraba en un servidor edge de Cloudflare y se extraía de la caché «local» del servidor de origen.
  3. Cuando no había ninguna página en la caché y WordPress tenía que lanzar scripts PHP y realizar consultas a la base de datos para construir la página dinámicamente.

El objetivo principal era la conocer la diferencia en los tiempos de respuesta de las cachés locales y de edge.

Medimos los tiempos de respuesta de dos formas:

  1. Tiempo hasta el primer byte (TTFB): intervalo entre la solicitud de una página y la llegada del primer byte de datos.
  2. Tiempo de descarga de una página HTML completa.

La medición del TTFB se centra en la latencia en la red entre un servidor web y un navegador, ya que es en gran medida independiente de la cantidad de datos transferidos para completar una página. Cronometrar la transferencia de una página completa es una medida útil que refleja la tarea real de entregar HTML a los navegadores.

Edge Caching en Números

Tras cientos de pruebas dirigidas a sitios de WordPress en centros de datos de todo el mundo, descubrimos que, de media, Kinsta Edge Caching reducía en más de un 50% el tiempo necesario para entregar páginas completas a los navegadores.

Echa un vistazo:

TTFB: 402,59 ms (caché local), 207 ms (Edge). Página completa: 490,99 ms (caché local), 223,98 ms (Edge).
TTFB: 402,59 ms (caché local), 207 ms (Edge). Página completa: 490,99 ms (caché local), 223,98 ms (Edge).

Según nuestras pruebas, Edge Caching redujo el TTFB una media de casi un 48,6%, y el tiempo de transferencia de páginas completas disminuyó casi un 54,4%.

Superando un 80% de Mejora en Largas Distancias

Aunque las medias de todas las pruebas de velocidad eran impresionantes, esa visión puede ocultar datos importantes, sobre todo para quienes se dirigen a un público global.

Nuestras pruebas descubrieron algunas mejoras espectaculares en el rendimiento cuando Edge Caching redujo la distancia entre los navegadores y los servidores de origen más distantes.

Por ejemplo, Edge Caching redujo el TTFB en un 83,6% y los tiempos de transferencia de página en un 85,6% entre nuestra ubicación de pruebas de Iowa y el centro de datos asia-southeast1 de Google en Singapur:

TTFB: 672,01 ms (caché local), 110,05 ms (Edge). Página completa: 901,1 ms (caché local), 129,79 ms (Edge)
TTFB: 672,01 ms (caché local), 110,05 ms (Edge). Página completa: 901,1 ms (caché local), 129,79 ms (Edge)

Al conectarse a sitios de WordPress en el centro de datos de Sydney australia-southeast1, el TTFB se redujo casi un 73,6%, y los tiempos de transferencia de páginas cayeron un 77,3%.

TTFB: 898.26 ms (caché local), 237.21 ms (edge). Página completa: 1,130.48 ms (local cache), 256.95 ms (edge).
TTFB: 898.26 ms (caché local), 237.21 ms (edge). Página completa: 1,130.48 ms (local cache), 256.95 ms (edge).

Vimos cifras similares en el centro de datos australia-southeast2 de Melbourne. Los sitios WordPress de los clientes de Kinsta allí vieron cómo el Edge Caching redujo el TTFB una media del 77,8% y la transferencia de páginas en casi un 82,7%:

TTFB: 607,37 ms (caché local), 134,63 ms (Edge). Página completa: 812.46 ms (caché local), 140,62 ms (Edge).
TTFB: 607,37 ms (caché local), 134,63 ms (Edge). Página completa: 812.46 ms (caché local), 140,62 ms (Edge).

Al conectarse a sitios alojados en el centro de datos europe-north1 de Hamina (Finlandia), el TTFB se redujo casi un 41,7%, y los tiempos de transferencia de página cayeron más de un 56,3%.

TTFB: 579,81 ms (caché local), 338,17 ms (Edge). Página completa: 822,21 ms (caché local), 358,89 ms (Edge).
TTFB: 579,81 ms (caché local), 338,17 ms (Edge). Página completa: 822,21 ms (caché local), 358,89 ms (Edge).

En los sitios alojados en St. Ghislain (Bélgica), en el centro de datos europe-west1, los tiempos de TTFB y de transferencia de página se redujeron un 69%.

TTFB: 464,64 ms (caché local), 143,13 ms (Edge). Página completa: 464,92 ms (caché local), 143,38 ms (Edge).
TTFB: 464,64 ms (caché local), 143,13 ms (Edge). Página completa: 464,92 ms (caché local), 143,38 ms (Edge).

Los sitios web probados en el centro de datos europe-west2 de Londres, Reino Unido, mostraron una caída del TTFB del 58%, y de los tiempos de transferencia de página del 60,8%.

TTFB: 372,4 ms (caché local), 156,17 ms (Edge). Página completa: 458,18 ms (caché local), 179,34 ms (Edge).
TTFB: 372,4 ms (caché local), 156,17 ms (Edge). Página completa: 458,18 ms (caché local), 179,34 ms (Edge).

En el centro de datos europe-west3 de Frankfurt (Alemania), el TTFB se redujo casi un 64% y los tiempos de transferencia de página, un 67,5%.

TTFB: 409,27 ms (caché local), 147,42 ms (Edge). Página completa: 507,52 ms (caché local), 164,98 ms (Edge).
TTFB: 409,27 ms (caché local), 147,42 ms (Edge). Página completa: 507,52 ms (caché local), 164,98 ms (Edge).

Al conectar con sitios alojados en el centro de datos europe-west4 de Eemshaven (Países Bajos), el TTFB se redujo casi un 56%, y los tiempos de transferencia de página, un 63,6%.

TTFB: 394,49 ms (caché local), 173,76 ms (Edge). Página completa: 538,84 ms (caché local), 195,82 ms (Edge).
TTFB: 394,49 ms (caché local), 173,76 ms (Edge). Página completa: 538,84 ms (caché local), 195,82 ms (Edge).

Durante las pruebas de los sitios en el centro de datos northamerica-northeast1 de Montreal (Canadá), el TTFB se redujo algo más del 10%, y los tiempos de transferencia de página se redujeron algo más del 16,2%.

TTFB: 325,3 ms (caché local), 292,28 ms (Edge). Página completa: 351,1 ms (caché local), 294,15 ms (Edge).
TTFB: 325,3 ms (caché local), 292,28 ms (Edge). Página completa: 351,1 ms (caché local), 294,15 ms (Edge).

En el centro de datos us-east5 de Columbus (Ohio), los tiempos de TTFB y de transferencia de página se redujeron casi un 59%.

TTFB: 326,69 ms (caché local), 133,97 ms (Edge). Página completa: 341,15 ms (caché local), 140,5 ms (Edge).
TTFB: 326,69 ms (caché local), 133,97 ms (Edge). Página completa: 341,15 ms (caché local), 140,5 ms (Edge).

En el centro de datos us-west4 de Las Vegas (Nevada, EE.UU.), el TTFB se redujo algo más de un 54,7% y el tiempo de transferencia de página casi un 57,3%.

TTFB: 366,73 ms (caché local), 165,88 ms (Edge). Página completa: 413,39 ms (caché local), 176,63 ms (Edge).
TTFB: 366,73 ms (caché local), 165,88 ms (Edge). Página completa: 413,39 ms (caché local), 176,63 ms (Edge).

Pero no sólo Kinsta está poniendo a prueba el Edge Caching.

Brian Jackson, cofundador de la agencia digital forgemedia, cronometró el TTFB y la renderización completa de páginas de WordPress en un navegador después de Edge Caching. También se fijó en el Largest Contentful Paint (LCP), el punto en el que se ha renderizado suficiente contenido principal de una página como para que un usuario la perciba como utilizable. Publicó sus conclusiones en Twitter:

Twitter/Brian Jackson.
Twitter/Brian Jackson. (Ver en Twitter)

Simon Harper, de SRH Design, probó Kinsta Edge Caching probando TTFB y LCP, así como el first contentful paint(FCP), que es la aparición inicial de cualquier contenido en una pantalla, aunque no sea el contenido principal de la página. También informó a través de Twitter:

Twitter/Simon Harper.
Twitter/Simon Harper. (Ver en Twitter)

La estructura de las páginas web y los activos vinculados, como JavaScript, CSS e imágenes, pueden afectar a FCP y LCP, pero todo comienza con la entrega del HTML de una página a un navegador.

Los Primeros Pasos con Kinsta Edge Caching

Edge Caching está activado por defecto cuando creas un sitio web WordPress en el panel de control de MyKinsta. Eso significa que no tienes que mover un dedo para aprovechar la mejora de velocidad de Edge Caching.

A partir de enero de 2023, Kinsta habilitará automáticamente Edge Caching en los sitios existentes que sean compatibles con el servicio. Si quieres que Edge Caching funcione en tu sitio existente de inmediato, puedes habilitarlo ahora así:

  • Selecciona Sitios WordPress en la barra de navegación de la izquierda.
  • Selecciona el nombre del sitio para el que quieres activar Edge Caching.
  • Selecciona Edge Caching.
  • Haz clic en el botón Activar Edge Caching.
Activar Edge Caching en el panel de control MyKinsta.
Activar Edge Caching en el panel de control MyKinsta.

Cachea tu Contenido Móvil en el Edge

Si tu sitio web detecta los navegadores móviles y genera páginas con marcado exclusivo para esos dispositivos, puedes habilitar una caché móvil separada del contenido para usuarios de escritorio.

Habilita la caché móvil en MyKinsta así:

  • Selecciona Sitios de WordPress en la barra de navegación de la izquierda.
  • Selecciona el nombre de un sitio para el que esté activado el Edge Caching.
  • Selecciona Edge Caching.
  • Haz clic en el botón Activar Caché Móvil
Activar Edge Caching para dispositivos móviles.
Activar Edge Caching para dispositivos móviles.

No necesitas habilitar la caché móvil si el diseño de tu sitio web es compatible con navegadores de escritorio y móviles con el mismo marcado HTML/CSS responsivo.

Gestiona tu Contenido en Caché

Kinsta Edge Caching está diseñado para funcionar perfectamente con las herramientas de gestión de caché que la mayoría de nuestros clientes ya utilizan en sus sitios web de WordPress. También puedes orientar el contenido en la caché edge directamente en MyKinsta aquí:

  • Selecciona Sitios de WordPress en la barra de navegación de la izquierda.
  • Selecciona el nombre de un sitio para el que esté activado el Edge Caching.
  • Selecciona Edge Caching.
Borrar la caché edge en el panel de MyKinsta.
Borrar la caché edge en el panel de MyKinsta.

Para borrar todas las páginas de tu sitio de la caché de borde global, haz clic en el botón Borrar Caché.

Si necesitas borrar sólo páginas o rutas específicas, pega una URL de destino en el campo Borrar caché de URL y haz clic en el botón Borrar caché URL. Borra la caché de todo el contenido de una ruta específica marcando la opción Borrar caché de cada subdirectorio bajo la URL especificada.

Desactivar el Edge Caching

Si sabes que Edge Caching no va a ser adecuado para tu sitio web, puedes excluirte antes de que empecemos a habilitar el servicio para la mayoría de los sitios existentes en enero de 2023.

En MyKinsta:

  • Selecciona Sitios de WordPress en la barra de navegación de la izquierda.
  • Selecciona el nombre de tu sitio de WordPress.
  • Selecciona Edge Caching.
  • Activa la opción «Quiero excluirme…«.
Exclusión voluntaria de Edge Caching mediante el panel de control de MyKinsta.
Exclusión voluntaria de Edge Caching mediante el panel de control de MyKinsta.

Si Edge Caching ya está activado para un sitio web, encontrarás un botón Desactivar en la esquina superior derecha de la página:

Desactivar Edge Caching
Desactivar Edge Caching

Preguntas rápidas sobre el Edge Caching

Te estarás preguntando…

¿Es el Edge Caching Gratuito en Todos los Planes?

Sí. El Edge Caching está activado por defecto en todos los sitios activos creados en el panel de control de MyKinsta. El Edge Caching también está disponible en los sitios de prueba de las cuentas Premium.

¿Mejora el Edge Caching el Rendimiento de la Versión Móvil de Mi Sitio Web?

Puedes habilitar una caché específica para móviles en los sitios web que generan marcas adaptadas a dispositivos móviles. Si el diseño de tu sitio web es compatible con navegadores de escritorio y móviles con el mismo marcado HTML/CSS responsivo, no es necesaria una caché móvil.

¿Necesito Utilizar Plugins de Optimización de WordPress?

No. La plataforma de alojamiento administrado de WordPress de Kinsta proporciona caché local, Edge Caching y una CDN perfectamente ajustada para soportar el CMS más popular del mundo. No se necesitan plugins de WordPress de terceros.

¿Puedo Desactivar el Edge Caching?

Sí, puedes desactivar Edge Caching en cualquier momento desde el panel de control de MyKinsta. Si no estás seguro de si tu sitio es compatible con Edge Caching, ponte en contacto con el equipo de soporte de Kinsta para que te asesoren.

Resumen

La promesa de Internet siempre ha sido conectar a las personas de todo el mundo. Pero resulta que la distancia física entre los servidores y los visitantes tiene un impacto real en el rendimiento percibido de los sitios web. Edge Caching acerca ese contenido a los navegadores web y acelera el primer paso esencial para una carga más rápida de las páginas.

Kinsta hace del Edge Caching un componente fundamental de su servicio de Alojamiento Administrado de WordPress, complementando las funciones de CDN y seguridad de red que vienen con nuestra integración de Cloudflare.

De media, Kinsta Edge Caching reduce a la mitad el tiempo que se tarda en entregar el HTML de las páginas web a los visitantes de tu sitio. Para sitios web con audiencias verdaderamente globales, el aumento de velocidad puede ser drásticamente superior.

Edge Caching está disponible para todos nuestros clientes sin coste adicional. Si sigues buscando un alojamiento para WordPress construido pensando en la seguridad, la facilidad de uso y el rendimiento, tenemos un plan de alojamiento adecuado para ti.

Steve Bonisteel

Kinsta

Steve Bonisteel is a Technical Editor at Kinsta who began his writing career as a print journalist, chasing ambulances and fire trucks. He has been covering Internet-related technology since the late 1990s.