La teoría vs. la práctica de los "sitios web estáticos"
(utcc.utoronto.ca)- A diferencia de la idea de que la diferencia entre los sitios web estáticos y dinámicos se ha difuminado, en una escala larga de operación los sitios web basados en archivos estáticos siguen teniendo una naturaleza distinta
- El método de despliegue de archivos que existe desde los inicios de la web y la eficiencia de servir archivos estáticos son razones por las que los sitios estáticos tienden a mantenerse por mucho tiempo
- Los sitios web estáticos tienen un límite claro de responsabilidades como un sistema de archivos entre el servidor web y el contenido, por lo que lo que ambos lados necesitan saber del otro es limitado
- En los sitios web dinámicos, la frontera entre el servidor web y el código del usuario es difícil de hacer pequeña y simple, y también es difícil estandarizarla en una sola interfaz o API
- El criterio de distinción no es la carga de trabajo ni la frecuencia de cambios, sino dónde está la frontera y de qué debe ocuparse cada lado
El punto de partida del debate sobre los sitios web estáticos
- Wesley Aptekar-Cassels, en There is no such thing as a static website, sostiene que la diferencia entre los sitios web estáticos y dinámicos es menor de lo que parece
- Los sitios web estáticos son más dinámicos y complejos de lo que aparentan
- Crear y operar sitios web dinámicos se ha vuelto más fácil que antes
- Aunque cada argumento individual está desarrollado de forma convincente, no lleva necesariamente a la conclusión de que la diferencia entre sitios web estáticos y dinámicos se haya reducido
La diferencia que crean la durabilidad y los límites de responsabilidad
- En una escala de tiempo larga, el contenido web basado en archivos estáticos ha mostrado una gran durabilidad
- Aunque cambien el servidor web específico o el hosting, la forma de ubicar archivos en archivos estáticos y árboles de directorios continúa desde los inicios de la web
- Servir archivos estáticos suele ser necesario y eficiente incluso en sitios web dinámicos, así que los sitios que solo tienen archivos estáticos aprovechan las mismas ventajas
- Si un sitio solo entrega contenido estático, resulta fácil seguir operándolo como un sitio estable, y esto históricamente no ha aplicado a los sitios web dinámicos
- La esencia de un sitio web estático es un límite de responsabilidades con aislamiento simple y fuerte
- De un lado está la complejidad del servidor web estático, incluyendo actualizaciones dinámicas como la renovación de certificados HTTPS
- Del otro lado están los archivos estáticos, y entre ambos hay un sistema de archivos o algo similar a uno
- Lo que cada lado le exige al otro es muy limitado
- En los sitios web dinámicos es difícil tener una frontera tan pequeña y clara entre el servidor web y el código del usuario
- También es poco probable que pueda estandarizarse con una sola frontera y API
- En cierto sentido, la web tiene un aspecto de haber sido diseñada para entregar archivos estáticos
- Esta diferencia hace que los servidores web de archivos estáticos sean más favorables para operar y migrar que los servidores web dinámicos y sus entornos de ejecución
- Los servidores web de archivos estáticos son fáciles de encontrar
- Incluso si el operador actual deja de mantenerlo, es fácil mover el sitio a otro lugar
- Esta durabilidad aplica al menos a los sitios web estáticos pequeños y medianos que caben en un solo servidor
- La distinción entre sitios web estáticos y dinámicos no es difusa
- El criterio no es la cantidad de trabajo necesaria para crear y operar el sitio, ni la cantidad de elementos que cambian periódicamente, como la renovación de certificados HTTPS
- El criterio es dónde está la frontera y de qué debe preocuparse cada lado
- Los sitios web estáticos tienen una frontera nítida que permite tratar ambos lados de forma independiente, mientras que los sitios web dinámicos carecen intrínsecamente de esa frontera y, si hace falta, hay que trazarla artificialmente
1 comentarios
Opiniones de Hacker News
Me gano la vida con un sitio web de contenido y este año me pasé de Craft CMS a un generador de sitios estáticos hecho por mí
Ahora no tengo que preocuparme por servidores ni CMS, no necesito actualizaciones y eliminé una base de datos pesada y una configuración compleja de caché. Ahora es simplemente un servidor de archivos estáticos, así que es más estable y casi no requiere mantenimiento
Lo mejor es que puedo trabajar sin conexión. Solo necesito un editor de texto, así que hasta una MacBook 12" pequeña se siente rapidísima
El control de versiones también es muy útil: puedo revisar o revertir cambios, y hacer buscar/reemplazar con expresiones regulares en todo el contenido. Los archivos de texto son fáciles de manejar
Escribí aquí cómo se sintió esta transición y por qué funciona bien: https://nicolasbouliane.com/projects/ursus
Dicho eso, me gustaría que esta tecnología fuera más accesible también para quienes no tienen la capacidad de recompilar y desplegar. Es una forma rápida y barata de crear sitios web, pero herramientas existentes como Hugo presuponen bastante del usuario, lo que genera una barrera de entrada
También leí el artículo con interés. Yo hice la versión original de html-to-markdown que usaste para la migración, y me alegra ver que todavía resulta útil
Es rápido, tiene bien cubierto lo necesario y no le sobra nada
Personalmente, me gustaría que tuviera una sección de series de TV y películas ambientadas en el Berlín de antes y de ahora, y también una calificación breve sobre qué tan realista es su representación del Berlín real
Probablemente, a más del 95% de todos los sitios web les habría alcanzado con cachear en RAM el 70% del contenido popular y servir el 30% restante desde un SSD capaz de lecturas aleatorias de 10.000 IOPS
Si no estás toqueteando constantemente el diseño del sitio, la generación del sitio y del HTML debería ocurrir en la máquina local, y la generación completa debería tomar menos de 1 segundo
Pero el enfoque centrado en GitHub, control de versiones y editores de texto sigue estando inclinado hacia técnicos y programadores. Hace falta algo tipo WordPress alojado, o algo más cercano a la época de Dreamweaver/Frontpage
Me gusta que, cuando quiero implementar algo especial, puedo meterme hasta el detalle. Por ejemplo, al editar el artículo Favorite Git Aliases, puedo hacer que se convierta en un archivo
.bash_aliases, se suba a GitLab y también se espeje en GitHubSi a alguien le interesa, está en https://jdsalaro.com. Todavía no escribí en detalle sobre el stack ni las razones, pero lo iré documentando poco a poco
Por ahora dejé escrito un cheatsheet de Markdown y Myst para Sphinx (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) y cómo cargar
environment.pickle(https://jdsalaro.com/howto/sphinx-load-environment-pickle/)Eso también significa usar menos recursos como electricidad, que alcanza con hardware más pequeño y, sobre todo, que mejora la seguridad. Los sitios web estáticos son más difíciles de atacar, y los posibles defectos quedan limitados al servidor web, no al código del sitio
Normalmente uso Hugo, que es muy completo y está muy maduro. También he hecho sitios web multilingües
Vale la pena considerar integrar Turbo Hotwired en sitios web estáticos. Puede mejorar la capacidad de respuesta de la navegación y reducir la carga tanto del servidor como del cliente
Si hace falta, también se puede integrar Turbo con Mercure para hacer streaming de páginas en tiempo real
La mayor diferencia entre los sitios estáticos y los dinámicos es la superficie de ataque de seguridad
En el peor caso, a un servidor web de sitio estático solo se lo puede inducir a servir el archivo equivocado, y eso se puede mitigar subiendo al servidor, desde el principio, solo archivos que esté permitido servir
A un sitio dinámico se lo puede inducir a ejecutar código, a devolver datos incorrectos desde una base de datos accesible, e incluso a modificar datos
Las intrusiones en WordPress ocurren todo el tiempo; las de Nginx, no
Técnicamente no existe un sitio web que no ejecute código. Desde el servidor web hasta el driver del sistema de archivos y el sistema operativo, todo es código
Es cierto que los archivos estáticos reducen la superficie de ataque, pero hay que pensar a fondo por qué, y diseñar sistemas dinámicos inteligentes con la seguridad de un sitio estático
Al final, lo central son las entradas y cómo se las maneja. Por más código complejo que ejecutes, si no recibes ninguna entrada, no hay forma de atacar. Claro que, sin entradas, ni siquiera puedes saber qué página mostrar, así que incluso los sitios estáticos tienen entradas. El punto de diferenciación importante está ahí
Estoy de acuerdo en que la superficie de ataque de un sitio estático es menor, pero creo que la razón más importante es que nginx recibe mucha más revisión y evoluciona más lentamente que la combinación promedio de plugins de WordPress
Si crearas tu propio servidor web estático, la primera versión probablemente sería más vulnerable a ataques que una instalación básica de WordPress
Un sitio estático, en teoría, podría no necesitar actualizaciones en absoluto. Mientras no cambie el objetivo, como la versión de HTML, casi ni existe el concepto de actualización
locationcon una directivaaliases la excepciónDesde la perspectiva de un desarrollador, la distinción queda bastante clara si se toma como criterio la abstracción que ofrece la web, es decir, el hipermedia que se proporciona sobre HTTP/S.
La semántica de esta abstracción consiste en una estructura donde entra una solicitud con encabezados y cuerpo hacia una ruta específica, y sale una respuesta con encabezados y cuerpo. Los detalles intermedios de red, como TLS, quedan ocultos.
De hecho, los frameworks modernos ocultan aún más cosas al desarrollador, administrando automáticamente incluso las sesiones de autenticación y los encabezados de solicitud. Dentro de esta abstracción, la distinción estándar de que “lo estático no depende de la solicitud/estado, y lo dinámico sí” es clara, pero esa distinción se apoya en la semántica que proporciona la abstracción.
Esto se parece a cómo TCP funciona como un protocolo orientado a conexión sobre una infraestructura subyacente que, fundamentalmente, está basada en paquetes. TCP puede usarse en aplicaciones que necesitan transmisión de datos en forma de stream o en forma de paquetes.
Se podría argumentar que “en realidad está sobre IP, así que no hay distinción”, pero eso es mirar desde la capa de abstracción equivocada.
Eso no significa que el punto del artículo sea incorrecto. Los desarrolladores siempre deberían tener presente la existencia de estado debajo de un “sitio web sin estado”, y conviene entender las abstracciones unas cuantas capas más abajo de lo que uno cree necesario.
Los sitios web personales mezclan lo estático y lo dinámico de una forma curiosa. La mayor parte es estática, pero la sección del blog usa renderizado dinámico.
Cuando se accede a una URL del blog, toma del disco un archivo Markdown, lo convierte a HTML y luego inserta ese HTML en una plantilla para armar el resto de la página, el CSS, etc.
Aun así, es rápido y eficiente. La semana pasada, cuando una entrada de mi blog llegó al puesto 1 en HN, un amigo me escribió: “espero que tengas configurado Cloudflare”. No lo tenía configurado, pero el promedio de carga de un VPS de 2 núcleos y 1 GB de memoria no pasó de 0.15.
Era algo como: “esto es mayormente HTML, pero cuando llegues a esta línea de este archivo, ejecuta código para parsear un archivo de otro formato e insertar el resultado en la salida”.
En 2001 era una forma muy razonable de crear un sitio web estático con algo como una sección de comentarios en cada entrada del blog. Este tipo de PHP era lo bastante barato como para que los ISP comunes permitieran subirlo a
/~userdir/y exponerlo a Internet pública.Con una estructura razonable que no dependa demasiado de una base de datos, incluso un VPS pequeño puede aguantar fácilmente el tráfico de Hacker News.
Si vas a lanzar Threads, necesitarás la forma de escalar que usa Facebook, pero para un sitio común de solo lectura no hace falta gastar mucho dinero en absoluto.
Se me ocurren razones como insertar contenido dinámico en una plantilla o reducir el tiempo y la complejidad de build, pero quizá haya otros motivos que no estoy considerando.
Desde la perspectiva de alguien externo que toca un poco wasm, no entendía por qué ejecutar código de usuario en el servidor para generar páginas web “dinámicas” sería mejor que un simple servidor de archivos.
Me parece que las partes dinámicas podrían ejecutarse en el navegador y el servidor limitarse a servir archivos. La excepción es que los navegadores de los 90 eran pésimos para este tipo de tareas.
En términos de simplicidad y escalabilidad, no hay nada que le gane a un servidor de archivos simple detrás de una CDN
También importa cuánta tecnología haya que no rompa las funciones básicas del navegador.
Como referencia, GitHub todavía me rompe el botón de volver al navegar código fuente en alrededor del 40% de los casos en mi entorno. Uso Chrome en OSX y ni siquiera sé cómo logran que pase eso.
En mi experiencia, los sitios que generan HTML del lado del servidor se sienten más rápidos y confiables que los que dependen del renderizado en el cliente. Abrir un booru con más de 50 imágenes por página cuando la caché del navegador está vacía siempre se siente más rápido y cómodo que abrir una página de GitHub que es solo texto, ya cacheada por todos lados y sin cambios desde hace días.
Por ejemplo, tal vez quieras guardar contenido enviado por usuarios en una base de datos, necesites autenticación o tengas que ofrecer búsqueda de texto completo sobre conjuntos de datos de varios GB. También podrías tener que ofrecer una interfaz para algo a lo que el navegador no puede acceder, o validar entradas de usuario.
Todo eso requiere código de usuario ejecutándose en el servidor. Entonces hay que convertir los datos del servidor a un protocolo de transporte bien definido, enviarlos al cliente, volver a convertirlos y luego transformarlos en HTML.
En la dirección inversa pasa lo mismo: para bloquear clientes personalizados maliciosos, hay que validar entradas tanto en el cliente como en el servidor.
O puedes generar directamente el HTML en el servidor y listo. Es mucho menos trabajo y, para la mayoría de las aplicaciones, ofrece prácticamente la misma experiencia.
Si hay secretos que deben ocultarse, como contraseñas de bases de datos, claves de API o claves criptográficas, deben ser manejados por código en el servidor. Si todo el código se ejecuta en el cliente, siempre existe la posibilidad de que un atacante descubra esos secretos.
También suele ser más fácil reducir la superficie de ataque ofreciendo al cliente una API más pequeña y limitada. Si dejas que el cliente se conecte directamente a la base de datos, los permisos y la configuración de seguridad tienen que ser exactos y no fallar; pero si tu app solo expone la lista de libros o películas que maneja, es más difícil atravesar las defensas.
Muchas veces, si la carga inicial entrega de una vez un bloque de datos listo para usar, el sitio se siente más responsivo. Aunque el tiempo real sea el mismo que descargar la aplicación, mostrar un indicador de carga, luego traer los datos y mostrarlos, para el usuario lo primero se siente más rápido.
El servidor suele estar junto a la base de datos y otros servidores necesarios, así que cargar en el front lo que se necesita puede ser más rápido. Las llamadas de red en ese entorno son más confiables. Si empujas todo el procesamiento hacia el lado del usuario, tienes que lidiar con llamadas más lentas e inestables.
Es probable que el servidor sea una plataforma mucho más consistente que el navegador del usuario. Los navegadores han mejorado, pero todavía tienen muchas diferencias sutiles. En el servidor puedes especificar con precisión las herramientas y versiones de runtime necesarias, y actualizar de forma más determinista.
Por supuesto, no siempre todo esto es cierto y hay excepciones. Trabajo principalmente con aplicaciones frontend, pero también hay muchísimo valor en aplicaciones bien diseñadas que hacen la mayor parte o todo el trabajo en el navegador. Solo que normalmente son apps web bastante complejas, o casos donde de todos modos se necesita cierto renderizado en el navegador.
La generación se hace una sola vez y termina muy rápido. Después, desde el punto de vista del usuario, se mantienen muchas de las ventajas de una página estática.
El uso de recursos es varios órdenes de magnitud menor y la página es mucho más responsiva. La experiencia de usuario también es mucho mejor, aunque en los últimos 10 años no nos haya importado demasiado.
rsync. Todas las páginas se renderizaban dinámicamente.La ventaja era que, después de configurarlo una vez, literalmente no tenía que volver a preocuparme por el sitio web y solo escribía el Markdown que me gustaba.
Era genial. Hasta que el proveedor de hosting web eliminó PHP.
Por estas razones me gusta mucho la exportación de páginas estáticas de NextJS.
Compilas y despliegas solo
.html,.jsy.cssestáticos en la CDN o servidor web estático que quieras. Las páginas y rutas individuales se prerenderizan durante la compilación, así que la primera carga es muy rápida y los motores de búsqueda pueden indexarlas.La forma en que NextJS divide el código
.jsen chunks y lo precarga también contribuye a una experiencia de carga rápida. Si necesitas funcionalidades ricas, puedes volverlo tan dinámico como quieras conectándolo con cualquier API REST.Con el plugin de MDX también puedes crear fácilmente áreas totalmente estáticas o sitios centrados en contenido dentro del mismo proyecto.
Sin embargo, desde que salió el app router de v13, siento que no están cuidando lo suficiente la función de exportación estática. Algunas funciones que existían en el pages router, como el enrutamiento superficial y las reescrituras/redirecciones estáticas, quedaron fuera de la exportación estática.
Como al usar exportación estática no necesitas para nada el producto comercial de Vercel, me preocupa que a largo plazo terminen eliminando esta función por completo.
La mayoría ni siquiera necesita JavaScript, y tampoco React, JSX, middleware o renderizado del lado del servidor.
Es difícil imaginar el mantenimiento a largo plazo de algo con tantas piezas móviles y dependencias de npm. No digo que no tenga usos, pero antes de lanzarse a un proyecto con un checkout de Git de 1.8 GiB y 828,128 líneas de código para hacer una landing page, conviene ir por lo simple.
Mira el ejemplo de Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
No es por el modelo de negocio de Vercel, sino porque este caso de uso es menos común dentro de la proporción de usuarios de Next.js.
No estoy seguro de qué quieren decir con “reescrituras estáticas”. ¿Eso no se maneja con middleware?
En algún momento de los 90 generé mi sitio con m4 antes de escuchar el término “generador de sitios estáticos”
Luego pasé a PHP y Python, y ahora volví a lo estático usando Jekyll
Siempre que sea posible, el enfoque estático es mucho mejor. Salvo por los certificados SSL, puedo arreglar todo según mi propio calendario
Compárese con una situación en la que una actualización de PHP rompe algo y hay que arreglarlo de inmediato, con el sitio caído hasta terminar
En un sitio estático, aunque el generador se rompa, el resultado fallido simplemente queda en estado estático. Si no necesitas publicar una entrada nueva, no hay problema
Aunque el servidor explote, basta con pedirle a un amigo que aloje unos cuantos archivos. No hace falta preguntar: “¿Estás corriendo PHP versión X con configuración Y? ¿También tienes postgres?”
Algunos amigos podrían decir: “No quiero instalar PHP en mi computadora”
En cuanto a complejidad, se siente apenas un nivel por encima de
sed "s/VERSION/1.2.3/g". Si puedes resolver todo con comandos externos de shell, no hace falta instalar algo como PythonDurante años he estado explorando patrones de arquitectura que den tanto las ventajas de lo estático como de lo dinámico
Es una forma de poder ejecutar código dinámico del lado del servidor, pero con costos de escalado muy bajos y con recuperación automática si algo se rompe
A esto lo llamo el patrón Baked Data: https://simonwillison.net/2021/Jul/28/baked-data/
La idea central es distribuir una copia completa de solo lectura de los datos del sitio como un asset incluido con la aplicación
Igual que con un sitio completamente estático, cada vez que hay cambios hay que volver a desplegar todo el sitio, así que no sirve para sitios que se actualizan continuamente
La ventaja es que se puede desplegar en un hosting dinámico barato con scale-to-zero, como Vercel; se pueden levantar varias copias de la app para manejar cualquier tráfico, y si la app muere, el host puede reiniciarla automáticamente
He visto sitios estáticos con búsqueda del lado del servidor o sistema de comentarios, donde cada artículo o comentario se envía como un archivo plano separado y a partir de ahí se regeneran automáticamente las páginas estáticas
Supongo que la diferencia es que se guarda en sqlite en vez de archivos Markdown y se construye desde ahí. Comparado con un sitio estático con funciones típicas de backend/del lado del servidor, esa parece ser la única diferencia significativa visible
No era raro que los ejecutables binarios compilados incluyeran recursos binarios codificados, como archivos o imágenes. No se metían demasiados porque aumentaban el tamaño del ejecutable
Ejemplos en C o C++: https://github.com/graphitemaster/incbin
Lo interesante es que los programas se hacían para que los datos dentro del ejecutable no cambiaran. El código compilado corre en la máquina y también tiene sentido desde el punto de vista de seguridad
Pero si pensamos en contenedores, por ejemplo docker, un contenedor en ejecución se parece a un ejecutable empaquetado, aunque también tiene un sistema de archivos
Si metes datos en un contenedor, conceptualmente se parece a un recurso embebido en un ejecutable, pero la diferencia es que esos datos pueden cambiar
Sin embargo, aunque los datos cambien en tiempo de ejecución dentro del contenedor, no persisten si no se adjunta almacenamiento persistente
Últimamente me pregunto por qué no se ha creado algo parecido a un único archivo que tenga “el ejecutable y un espacio de datos volátil dentro del ejecutable”. El programa y datos como los de una base de datos podrían combinarse en un solo archivo
Es una idea algo relacionada con “Baked Data”. Embeber recursos en un ejecutable, al final, es meter datos codificados dentro del ejecutable
En lenguajes de scripting se puede crear un archivo de script que contenga directamente en una variable datos codificados en base64
Las dos últimas formas solo sirven para datos estáticos relativamente pequeños, pero sería interesante crear alguna tecnología que de algún modo levante estas limitaciones de los ejecutables
También alojo así mi página de proyectos: https://usmanity.com/projects
Como no quería editar directamente archivos HTML cada vez que agrego un proyecto nuevo a la lista o cambio detalles de uno existente, uso Notion y horneo los datos antes de hacer commit en GitHub
Al activarlo, horneaba todas las páginas del sitio como HTML en un directorio y cambiaba
.htaccesspara enviar todo el tráfico allí. Cuando actualizabas contenido, volvía a hornear todohttps://www.drupal.org/project/boost
Creo que una parte que todavía falta mucho en los sitios estáticos es dónde alojar el CMS de edición.
Corríjanme si me equivoco, pero Decap CMS (antes Netlify CMS) se ejecuta en el navegador, puede leer/modificar a través de GitHub y luego disparar la recompilación y el despliegue. Pero, por CORS, el navegador no puede comunicarse directamente con la API de GitHub, así que entiendo que todavía hace falta un servidor pequeño o un proxy.
Netlify aloja un backend de GitHub que hace proxy de las solicitudes, pero eso te ata a Netlify y a los cambios en su política de precios.
GitLab y BitBucket probablemente tengan el mismo problema: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
¿Hay alguna forma sencilla de resolverlo con una configuración mínima? También se podría relajar CORS de forma selectiva con una extensión del navegador, pero no es lo ideal.
Un generador de sitios estáticos basado en Git, con un CMS que tenga edición en Markdown y vista previa en tiempo real, que se ejecute en el navegador y tenga pocas restricciones de hosting/servidor, me parece que encajaría con muchísimos sitios web pequeños y blogs.
El generador estático solo tendría que leer esos datos mediante algo como un feed JSON y crear las páginas. Por ejemplo, cada registro de producto podría incluir una descripción principal en formato HTML.
Así, aunque otra persona actualice la información de los productos, el sitio web seguiría siendo estático. Pensé que Airtable sería adecuado, pero sorprendentemente no soportaba bien los campos HTML.
Creas el sitio web como quieras, conectas Surreal por FTP y luego dejas que usuarios o clientes editen solo las partes permitidas.
12 dólares al mes es muy barato a cambio de no tener que preocuparte, y puedes ofrecer a usuarios no técnicos un editor WYSIWYG completo.
[1] https://www.surrealcms.com
Actualmente esta extensión funciona en VS Code instalado localmente en una laptop, pero no en GitHub Codespaces.
Si lograran hacerla funcionar dentro del plan gratuito de GitHub Codespaces, con un límite razonable de horas de uso, creo que sería una opción ganadora. Tendrías una configuración completamente en línea y versionada, sin necesidad de instalar el entorno de desarrollo en tu computadora, mientras el sitio estático se sirve desde algo como S3, y aun así obtendrías una experiencia completa de CMS.
Un punto muy importante de los sitios estáticos es que es mucho más fácil subirlos y olvidarse.
Si los subes a algo como un sitio en un bucket de S3, casi no tienes que preocuparte.
Si haces un sitio de “subir y olvidar” con PHP o, peor aún, con WordPress autoalojado, puede terminar lleno de anuncios porno rusos si no lo revisas cada pocos meses.
Tengo algunos sitios estáticos en operación y es realmente agradable saber que siempre están en línea y que no necesitan arreglos. En cambio, para los sitios dinámicos necesitas alertas que te avisen si se cayeron.