--- title: "Rendimiento de un sitio en Astro: datos reales y costo" description: "Core Web Vitals reales de dardo.studio, un sitio en Astro sobre Cloudflare Workers: p75 por página y pantalla, Lighthouse, peso, costo y lo que falló." url: "https://dardo.studio/es/blog/rendimiento-sitio-astro/" language: "es" translations: {"en":"https://dardo.studio/en/blog/astro-website-performance/","pt":"https://dardo.studio/pt/blog/desempenho-site-astro/"} updated: "2026-10-22T19:51:01.142Z" --- [Blog](https://dardo.studio/es/blog/) # Rendimiento de un sitio web en Astro: lo que mide dardo.studio Core Web Vitals de campo, Lighthouse, peso de página y costo de dardo.studio, un sitio en Astro sobre Cloudflare Workers, incluido lo que falló. Por [Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/) · 22 de octubre de 2026 ![Una maqueta de papel de una casa en una mesa de arquitecto de noche, rodeada de una regla, un calibrador y un cronómetro de bronce con la aguja carmesí](https://dardo.studio/_astro/01M5JG2FJFSK6MVDVG5CCPXYAD_ZrwxP9.webp) ## Puntos clave - En 28 días de datos de campo propios, el p75 de dardo.studio fue de 1.114 ms en LCP, 80 ms en INP y 0,08 en CLS, todos dentro de los umbrales buenos de Google. - La página de inicio en pantallas grandes falló con un CLS p75 de 0,239, causado por un efecto hover que corregimos el 22 de octubre; en celulares, su INP p75 quedó justo en la línea de 200 ms. - Nuestras páginas de contenido transfieren de 663 a 820 KB en Lighthouse, frente a medianas de septiembre de 2026 de 1.326 KB para páginas de inicio en Astro y de 2.656 a 3.398 KB para WordPress, Framer y Webflow. - Unos 287 KB de los cerca de 432 KB de JavaScript de una página de contenido son analítica; los scripts propios del sitio pesan unos 145 KB. - El costo fijo de la plataforma es el plan Workers Paid de Cloudflare, USD 5 al mes; el uso por encima de lo incluido se cobra aparte, y no publicamos las facturas. ## La respuesta corta dardo.studio es un sitio en Astro servido por un Worker de Cloudflare, con contenido en un CMS headless y cada página en inglés, español y portugués. En 28 días, del 24 de septiembre al 22 de octubre de 2026, el percentil 75 de las visitas reales fue 1.114 ms en Largest Contentful Paint (LCP), 80 ms en Interaction to Next Paint (INP) y 0,08 en Cumulative Layout Shift (CLS). Los umbrales buenos de Google son 2,5 segundos, 200 ms y 0,1: el sitio en conjunto aprueba. Las cifras generales esconden dos problemas. En pantallas grandes, el CLS p75 de la página de inicio fue 0,239, más del doble del límite, porque un efecto hover reorganizaba una cuadrícula; lo corregimos el 22 de octubre. En celulares, su INP p75 fue exactamente 200 ms, bueno pero sin margen, y aún sin explicar. En laboratorio, nuestras páginas sacaron de 90 a 99 en móvil, y el punto débil es el JavaScript: cerca de dos tercios del de una página de contenido es analítica. ## Cómo está construido el sitio y por qué cada pieza - Astro 7.3.2 con salida estática, porque una página de marketing debe ser HTML primero: Astro quita el JavaScript de cliente de cada componente que no esté marcado como isla interactiva. Solo /preview/ se renderiza en cada solicitud, para que el CMS muestre borradores. - Un Worker de Cloudflare, con el adaptador @astrojs/cloudflare 14.3.4, para que redirecciones, enrutamiento por idioma, la API del formulario de contacto y las verificaciones de servidor de nuestras herramientas gratuitas vivan junto a los archivos. - EmDash, un CMS headless sobre Cloudflare, para que los editores publiquen sin un desarrollador y ningún visitante espere una consulta al CMS. Guarda las páginas, 41 páginas de servicio, casos de estudio, artículos, herramientas, textos de la interfaz y configuración; cada publicación dispara una compilación en Workers Builds que sale en vivo minutos después. Más en [desarrollo de CMS headless](https://dardo.studio/es/servicios/desarrollo-cms-headless/). - Cloudflare D1, una base de datos SQLite, para las solicitudes de contacto y nuestras mediciones de Core Web Vitals (guardadas 35 días), así que los datos de campo son nuestros; R2 para los archivos multimedia. - Tres idiomas para Estados Unidos, Latinoamérica y Brasil, con alternativas hreflang: 418 URL en el sitemap el 22 de octubre de 2026, 145 en inglés. Mira [sitios web multilingües](https://dardo.studio/es/servicios/sitios-web-multilingues/). Todo, salvo la vista previa de borradores, cambia cuando un editor publica, no cuando llega un visitante, así que se construye una vez y se sirve como archivos. Nuestra [comparación de Astro vs Next.js](https://dardo.studio/es/blog/astro-vs-nextjs/) explica cuándo conviene lo contrario. Desarrollo con Astro ¿Quieres que Dardo lo haga por ti? Cuéntanos qué necesitas. Nico te responde personalmente en un día hábil. [Pedir una propuesta](https://dardo.studio/es/contacto/?service=astro-development) · [Ver el servicio](https://dardo.studio/es/servicios/desarrollo-astro/) ## Datos de campo: lo que recibieron los visitantes reales Estos números vienen de nuestra propia medición, no del Chrome UX Report de Google. Cada vista de página envía sus Core Web Vitals, Time to First Byte (TTFB) y First Contentful Paint (FCP) a una tabla de D1. Reportamos el percentil 75, como recomienda Google, en celulares y en pantallas grandes (tableta y escritorio). La recolección respeta la elección de analítica de cada visitante: los navegadores que la rechazan o envían Do Not Track o Global Privacy Control quedan fuera de la muestra. Las muestras son pequeñas: lee las filas con n bajo como tendencia, no como prueba. | Tipo de página, pantalla | LCP p75 | INP p75 | CLS p75 | TTFB p75 | | -------------------------------- | ------------------ | -------------- | --------------- | ------------------ | | Todo el sitio | 1.114 ms (n=1.414) | 80 ms (n=883) | 0,08 (n=1.223) | 457 ms (n=1.712) | | Todo el sitio, celulares | 1.016 ms (n=291) | 184 ms (n=183) | 0,001 (n=153) | 489 ms (n=389) | | Todo el sitio, pantallas grandes | 1.192 ms (n=1.123) | 64 ms (n=700) | 0,089 (n=1.070) | 438,9 ms (n=1.323) | | Inicio, celulares | 1.018 ms (n=182) | 200 ms (n=148) | 0,0 (n=75) | 476 ms (n=232) | | Inicio, pantallas grandes | 792 ms (n=607) | 56 ms (n=465) | 0,239 (n=574) | 380,9 ms (n=663) | | Servicios, celulares | 640 ms (n=42) | 48 ms (n=14) | 0,067 (n=32) | 485 ms (n=47) | | Servicios, pantallas grandes | 716 ms (n=96) | 64 ms (n=42) | 0,089 (n=89) | 475,6 ms (n=129) | | Artículos, celulares | 1.076 ms (n=13) | 40 ms (n=2) | 0,001 (n=13) | 281,8 ms (n=13) | | Artículos, pantallas grandes | 648 ms (n=30) | 40 ms (n=8) | 0,005 (n=32) | 162,3 ms (n=55) | El LCP es el mejor resultado: el 90 % de las lecturas fue bueno, y la fila más lenta, todo el sitio en pantallas grandes, marca 1.192 ms. El TTFB p75 fue 457 ms, bajo los 0,8 segundos que web.dev considera buenos, y el FCP p75 fue 1.068 ms frente a una marca buena de 1,8 segundos. De las seis filas por tipo de página y pantalla, cinco aprueban las tres Core Web Vitals; la de inicio en pantallas grandes falla en CLS. El INP depende del dispositivo: 64 ms en pantallas grandes y 184 ms en celulares, donde 148 de las 183 lecturas vinieron de la página de inicio, la única con una ilustración pesada. ## Lo que falló y lo que cambiamos el 22 de octubre Nuestra tabla de D1 guarda los valores sin atribución, así que el 21 y el 22 de octubre encontramos cada causa reproduciéndola en un navegador con trazas de rendimiento. ### CLS de la página de inicio en pantallas grandes El CLS p75 fue 0,239 (n=574), con solo el 65 % de lecturas buenas; un corte de 21 días marcaba 0,306. Al pasar el cursor sobre una tarjeta del mosaico de servicios, esta se expandía cambiando las columnas de la cuadrícula y movía todas las demás: cada hover desplazaba el diseño entre 0,13 y 0,26. Un hover no es una entrada discreta como un clic, así que el navegador no excusa sus desplazamientos, como sí hace con los de los 500 ms posteriores a un clic. Los celulares no tienen hover, lo que cuadra con su 0,0. Ahora las tarjetas mantienen un solo origen y se mueven con transformaciones CSS, que no cambian el diseño. Una prueba de laboratorio que pasa el cursor por cada tarjeta bajó de 0,331 a 0,0008. La contrapartida: la ilustración del mosaico puede quedar hasta 1 px fuera de su posición de reposo. La cifra de campo tardará unas semanas de datos nuevos en moverse. ### INP en celulares en la página de inicio El INP p75 en celulares fue 200 ms (n=148), con un 75 % de lecturas buenas. Un corte de 21 días marcaba 232 ms (n=126); desde el 15 de octubre, 128 ms con 32 lecturas. En laboratorio, la peor interacción que logramos tarda 64 ms. La única interacción lenta que capturamos cayó en un fotograma de arranque de 295 ms sin scripts largos, lo que apunta a la GPU o a la compilación de un shader de la ilustración en WebGL. Hacer que cinco escrituras de atributos por fotograma corran solo cuando cambian redujo un 23 % las mutaciones del DOM, pero el laboratorio siguió en 64 ms. Sigue abierto. Agregar atribución a nuestra medición, como describe nuestra [guía para mejorar el INP](https://dardo.studio/es/blog/mejorar-inp/), señalaría el fotograma o el script responsable. ### Desplazamientos en servicios y una página de proyectos lenta Las páginas de servicio en pantallas grandes tuvieron un CLS p75 de 0,089, pero cuatro lecturas en tres minutos el 21 de octubre marcaron 0,223. Las portadas usaban aspect-ratio: auto, así que el texto saltaba unos 435 px al llegar la imagen, y las introducciones en unidades ch se ensanchaban un 24 % al cargar la fuente de la marca. Ahora las portadas reservan su proporción, esos anchos tienen un mínimo en em y las fuentes de respaldo están escaladas a las de la marca. En laboratorio, los servicios bajaron de 0,03–0,21 a 0,04 o menos, y las vistas de tableta de hasta 0,50 a 0,004 o menos. En la página de proyectos, el LCP p75 en escritorio fue 4.740 ms en un corte de 21 días (n=36; 2.868 ms en 28 días, en un tipo de página que también incluye los casos de estudio). Su elemento más grande, un fondo desenfocado, no tenía fetchpriority, y en cambio la recibían imágenes de filas ocultas. Ahora las imágenes principales cargan con prioridad alta y el resto con baja, y un video de 4,4 MB espera a su póster. El LCP de laboratorio bajó de 1,80 a 1,45 segundos con densidad de píxeles 1x y de 2,20 a 1,57 con 2x, en un servidor HTTP/2 que respeta la prioridad. ## Datos de laboratorio y peso frente a las medianas por plataforma Corrimos Lighthouse 12.8.2 en local el 22 de octubre de 2026 y reportamos la segunda corrida en móvil, porque la primera tras una compilación encuentra la caché fría. Según la documentación de Lighthouse, buena parte de la variación entre corridas viene de fuera de la herramienta. | Página | Puntaje móvil | LCP móvil | CLS móvil | Puntaje escritorio | LCP escritorio | | ----------------------------------------------- | ------------- | --------- | --------- | ------------------ | -------------- | | Inicio | 96 | 1,6 s | 0,000 | 95 | 0,6 s | | Servicio: desarrollo en Astro | 90 | 3,5 s | 0,000 | 99 | 0,7 s | | Artículo: de Framer a Astro | 96 | 2,8 s | 0,000 | 99 | 0,8 s | | Herramienta: generador de mapa de redirecciones | 99 | 1,8 s | 0,000 | 100 | 0,4 s | El LCP móvil de la página de servicio (3,5 segundos) y del artículo (2,8) pasa la línea de 2,5 segundos, aunque las visitas reales a esos tipos de página tuvieron un LCP p75 de 640 a 1.076 ms. La corrida móvil de Lighthouse simula un teléfono lento con conexión limitada, más lento de lo que nuestros datos de campo sugieren para la mayoría de los visitantes, así que la usamos como alarma de regresiones y dejamos el veredicto a los datos de campo. El CLS de laboratorio fue 0,000 en todas, por eso el desplazamiento del hover pasó inadvertido: una prueba de carga no pasa el cursor por nada. ### Peso de página frente a los sitios típicos por plataforma El HTTP Archive mide las páginas de inicio de los sitios que detecta en cada plataforma. Como el público de cada plataforma es distinto, sus medianas describen sitios típicos, no lo que logra una construcción cuidadosa. Las nuestras son tamaños de transferencia de Lighthouse, una corrida por página. | Página o plataforma | Total | JavaScript | Imágenes | Lighthouse móvil | | ---------------------------------------- | -------- | ---------- | -------- | ---------------- | | dardo.studio, inicio | 1.168 KB | 709 KB | 218 KB | 96 | | dardo.studio, servicio | 820 KB | 433 KB | 207 KB | 90 | | dardo.studio, artículo | 716 KB | 432 KB | 120 KB | 96 | | dardo.studio, herramienta | 663 KB | 440 KB | 43 KB | 99 | | Mediana de Astro, 47.277 orígenes | 1.326 KB | 399 KB | 346 KB | 70 | | Mediana de Framer Sites, 11.319 orígenes | 3.011 KB | 797 KB | 934 KB | 67 | | Mediana de Webflow, 59.483 orígenes | 3.398 KB | 904 KB | 793 KB | 62 | | Mediana de WordPress, 2.658.175 orígenes | 2.656 KB | 661 KB | 1.017 KB | 43 | Cada una de nuestras páginas pesa menos en total que la página de inicio mediana en Astro y menos de la mitad que las medianas de Framer, Webflow y WordPress, y lleva menos bytes de imágenes que cualquiera de ellas. El JavaScript es la excepción: todas las páginas envían más que los 399 KB de la mediana de Astro. Las tasas de aprobación muestran menos diferencia. En septiembre de 2026, el 71,1 % de los orígenes en Astro aprobó las tres Core Web Vitals en móvil, cerca de Framer (70,8 %) y Webflow (71,3 %), y muy por encima de WordPress (48,3 %). En escritorio, las cifras fueron 84,6 %, 87,9 %, 82,6 % y 53,7 %. Una página mediana más liviana no garantiza aprobar; la construcción decide. ## En qué se va el JavaScript Las páginas de contenido cargan unos 432 KB de JavaScript. Unos 287 KB son analítica, cargada desde terceros o por nuestro proxy: la etiqueta de Google (gtag.js, 160 KB) y los módulos de grabación, encuestas, autocaptura y web-vitals de PostHog (unos 127 KB). Nuestros propios scripts pesan unos 145 KB, un paquete de interfaz compartido de 96 KB más pequeños módulos por página. Las fuentes suman 126 KB. La página de inicio carga 709 KB por su ilustración interactiva, el vuelo de un dardo en WebGL que avanza con el scroll. Así, dos tercios del script de un artículo o una página de servicio son medición, no la página. Cuestan transferencia, además de análisis y ejecución en el hilo principal del teléfono, del que depende el INP. Aun así, las páginas de contenido responden rápido en nuestros datos de campo, con un INP p75 de 40 a 64 ms en muestras pequeñas. Mantenemos la analítica porque muestra qué páginas y herramientas llevan a solicitudes de contacto; si los números empeoran, lo más barato es usar menos módulos de PostHog, cargarlos después o quitar una herramienta. Un proyecto de [optimización de velocidad web](https://dardo.studio/es/servicios/optimizacion-de-velocidad-web/) debería empezar igual: listar cada script, su tamaño y quién lo necesita. ## Cuánto cuesta operarlo El costo fijo de la plataforma es USD 5 al mes, el plan Workers Paid de Cloudflare, verificado en las suscripciones de la cuenta el 22 de octubre de 2026. R2 y Stream están en planes por uso sin tarifa base, la zona está en el plan gratuito de Cloudflare, y el dominio y el CMS corren en la misma cuenta. En octubre de 2026, Workers Paid incluye 10 millones de solicitudes y 30 millones de milisegundos de CPU al mes; después, USD 0,30 por millón adicional de solicitudes y USD 0,02 por millón adicional de milisegundos de CPU. Las solicitudes a archivos estáticos son gratis e ilimitadas, lo que importa en un sitio casi todo estático. D1 incluye 25.000 millones de filas leídas, 50 millones de filas escritas y 5 GB de almacenamiento al mes, y la salida de datos de R2 es gratis. Los USD 5 no incluyen el uso por encima de esos montos, el uso de R2 y Stream, el registro del dominio, los servicios fuera de Cloudflare como la analítica ni el tiempo de las personas. No publicamos las facturas, así que tómalo como un piso, no como nuestra factura mensual. ## Cómo atiende el sitio a los rastreadores y agentes de IA - robots.txt permite los rastreadores de búsqueda y de IA, con preferencias Content-Signal de search=yes y ai-input=yes. - /llms.txt (42 KB) y /llms-full.txt (unos 877 KB), generados desde el CMS. - Una copia en Markdown de cada página: agrega index.md a la dirección o envía Accept: text/markdown. - Un endpoint MCP público y de solo lectura en /mcp y una agent card A2A en /.well-known/agent-card.json, que responden preguntas sobre nuestros servicios publicados con el mismo contenido de las páginas. Lo que no podemos afirmar: no conocemos ninguna empresa de búsqueda con IA que documente un efecto del llms.txt, las copias en Markdown o un endpoint MCP sobre si una página es citada. Los publicamos porque cuesta poco generarlos a partir de contenido estructurado y son útiles para los agentes que los leen. Nuestra [guía de llms.txt](https://dardo.studio/es/blog/que-es-llms-txt/) explica qué es el archivo y quién lo lee, y el [verificador de visibilidad en IA](https://dardo.studio/es/herramientas/verificador-visibilidad-ia/) muestra cómo trata tu robots.txt a cada rastreador de IA. Esperamos que el HTML rastreable, los datos específicos y las fuentes con nombre pesen más. ## Qué significa esto si estás pensando en Astro Astro nos facilitó mantener livianas las páginas de contenido: nuestro propio código en un artículo pesa unos 145 KB de JavaScript, y nada corre si no lo agregamos. No evitó nuestros dos problemas. Un efecto hover rompió el CLS y la ilustración en WebGL es la sospechosa del INP en celulares; ambas, decisiones de diseño que darían el mismo problema en cualquier plataforma. Astro encaja cuando el sitio es sobre todo contenido que cambia al publicar, quieres el código, el hosting y los datos en tus propias cuentas, y tienes desarrolladores que se hagan cargo de las plantillas. Es la decisión equivocada cuando tu equipo de marketing edita el diseño visualmente cada semana y el sitio actual ya aprueba las Core Web Vitals; las tasas de aprobación de Framer y Webflow están cerca de las de Astro. Una migración debería comprar algo concreto: código propio, un backend que el constructor visual no ofrece o control sobre cada script. Astro sobre Cloudflare Workers es nuestro stack por defecto en [desarrollo con Astro](https://dardo.studio/es/servicios/desarrollo-astro/), y hacemos migraciones [de Framer a Astro](https://dardo.studio/es/servicios/migracion-framer-a-astro/), [de Webflow a Astro](https://dardo.studio/es/servicios/migracion-webflow-a-astro/) y [de WordPress a Astro](https://dardo.studio/es/servicios/migracion-wordpress-a-astro/). ## Cómo medir tu propio sitio 1. Empieza por el contexto: nuestro [informe de velocidad por plataforma](https://dardo.studio/es/herramientas/velocidad-plataformas-web/) muestra el último mes del HTTP Archive para tu plataforma. 2. Consigue datos de campo. El Chrome UX Report de Google solo cubre páginas y orígenes con suficientes visitantes de Chrome; si el tuyo no alcanza, envía las Core Web Vitals desde el navegador a tu propio almacenamiento, como hacemos con D1. 3. Reporta el p75 con el tamaño de la muestra, por tipo de página y tamaño de pantalla. Nuestras cifras globales aprobaban y escondían los dos problemas. 4. Corre Lighthouse dos veces, quédate con la segunda y úsala para detectar regresiones, no como veredicto. 5. Prueba lo que una prueba de carga omite: hover, menús, ilustraciones que avanzan con el scroll. Ahí estaba nuestro peor desplazamiento. 6. Corrige una causa a la vez y espera datos de campo nuevos antes de darla por corregida. Nuestra [guía para mejorar las Core Web Vitals](https://dardo.studio/es/blog/mejorar-core-web-vitals/) explica las causas y soluciones habituales de cada métrica. ## Preguntas frecuentes **¿Un sitio en Astro es más rápido que uno en Framer o Webflow?** No automáticamente. En septiembre de 2026, la página de inicio mediana en Astro pesaba 1.326 KB en móvil, frente a 3.011 KB en Framer y 3.398 KB en Webflow, pero la proporción que aprobaba las Core Web Vitals en móvil era casi igual: 71,1 %, 70,8 % y 71,3 %. Astro no envía JavaScript a menos que lo agregues; que un sitio apruebe depende de lo que agregas. **¿Por qué Lighthouse reporta un LCP más lento que el que ven los visitantes reales?** Su corrida móvil simula un teléfono lento en una red limitada, más lento de lo que parece tener la mayoría de nuestros visitantes. Nuestra página de desarrollo en Astro tuvo un LCP de 3,5 segundos en laboratorio, y las visitas reales a páginas de servicio, un LCP p75 de 640 ms en celulares y 716 ms en pantallas grandes. Usa el laboratorio para detectar regresiones y los datos de campo para juzgar lo que reciben los visitantes. **¿Cuánto cuesta alojar un sitio en Astro en Cloudflare Workers?** Nuestro costo fijo es el plan Workers Paid, USD 5 al mes en octubre de 2026, con 10 millones de solicitudes y 30 millones de milisegundos de CPU incluidos y las solicitudes a archivos estáticos gratis. El uso por encima de eso, el almacenamiento, el video, el dominio y las herramientas externas se pagan aparte, así que compara los precios de Cloudflare con tu propio tráfico. **¿Un llms.txt o un endpoint MCP hacen que un sitio sea citado en respuestas de IA?** No conocemos ninguna empresa de búsqueda con IA que documente ese efecto. Publicamos /llms.txt, copias en Markdown y un endpoint MCP de solo lectura porque cuesta poco generarlos desde el contenido del CMS y son útiles para los agentes que los leen. Tómalos como una comodidad, no como una palanca, y cuida que el HTML rastreable y los datos con fuentes estén bien. **¿Cuántas lecturas se necesitan para que los datos de campo signifiquen algo?** No hay un número único. Reporta el tamaño de la muestra junto a cada p75 y lee los cortes pequeños como una tendencia. Nuestro LCP de todo el sitio se apoya en 1.414 lecturas; el de artículos en celulares, en 13, y su INP en 2, así que de esas filas solas no sacamos conclusiones. ## Fuentes y lecturas Fuentes de esta página, con más detalles de sus publicaciones originales. - [HTTP Archive: informe de tecnologías](https://httparchive.org/reports/techreport/tech) · httparchive.org - [web.dev: Métricas web esenciales (Web Vitals)](https://web.dev/articles/vitals?hl=es) · web.dev - [web.dev: Largest Contentful Paint (LCP)](https://web.dev/articles/lcp?hl=es) · web.dev - [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp?hl=es) · web.dev - [web.dev: Cumulative Layout Shift (CLS)](https://web.dev/articles/cls?hl=es) · web.dev - [web.dev: Tiempo hasta el primer byte (TTFB)](https://web.dev/articles/ttfb?hl=es) · web.dev - [web.dev: First Contentful Paint (FCP)](https://web.dev/articles/fcp?hl=es) · web.dev - [Chrome for Developers: metodología de CrUX](https://developer.chrome.com/docs/crux/methodology?hl=es) · developer.chrome.com - [Chrome for Developers: puntuación de rendimiento de Lighthouse](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring?hl=es) · developer.chrome.com - [Documentación de Astro: arquitectura de islas](https://docs.astro.build/es/concepts/islands/) · docs.astro.build - [Documentación de Astro: @astrojs/cloudflare](https://docs.astro.build/es/guides/integrations-guide/cloudflare/) · docs.astro.build - [Documentación de Cloudflare: precios de Workers](https://developers.cloudflare.com/workers/platform/pricing/) · developers.cloudflare.com - [Documentación de Cloudflare: precios de D1](https://developers.cloudflare.com/d1/platform/pricing/) · developers.cloudflare.com - [Documentación de Cloudflare: precios de R2](https://developers.cloudflare.com/r2/pricing/) · developers.cloudflare.com - [Documentación de Cloudflare: Workers Builds](https://developers.cloudflare.com/workers/ci-cd/builds/) · developers.cloudflare.com [Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/) Nicolás Cerón es el fundador de Dardo, un estudio de marca, diseño y desarrollo web en Bogotá, Colombia. ## Artículos relacionados - [**Astro vs WordPress en 2026: edición, mantenimiento, costo anual, velocidad y cuándo migrar**Astro vs WordPress para un sitio de marketing: edición, plugins, costo anual de hosting, velocidad real, WordPress headless y cuándo quedarse.](https://dardo.studio/es/blog/astro-o-wordpress/) - [**Sanity vs Contentful vs Payload: el mejor CMS headless para tu equipo en 2026**Sanity, Contentful, Payload, Strapi y Storyblok comparados en hosting, vista previa, traducciones, exportación y costo mensual real para equipos de 5 y 12.](https://dardo.studio/es/blog/sanity-vs-contentful-vs-payload/) - [**Alternativas a Webflow en 2026: cuánto cuesta cada una y qué implica salir de Webflow**Framer, WordPress, un sitio programado, Wix Studio, Squarespace o HubSpot: cuánto cuesta cada uno para un sitio con blog y qué exige salir de Webflow.](https://dardo.studio/es/blog/alternativas-a-webflow/) - [**Precios de Webflow 2026: cuánto cuesta, qué cambia al renovar y cuándo dejarlo**Webflow unió sus planes CMS y Business en Premium. Cuánto paga tu sitio al renovar, en USD, COP y MXN, y cuándo conviene pasarse a Framer o a Astro.](https://dardo.studio/es/blog/precios-webflow-2026/) ## Sigue explorando. - [Servicio · **Desarrollo con Astro: sitios rápidos y migraciones**](https://dardo.studio/es/servicios/desarrollo-astro/) - [Tu proyecto · **Inicia una conversación**](https://dardo.studio/es/contacto/)