Sitios Astro listos para producción , hechos para agentes de IA. SEO, i18n, rendimiento, páginas legales y email — preconfigurados con valores sensatos que tú posees.https://astroignite.dev/es-EShttps://astroignite.dev/es/blog/lighthouse-as-a-build-target/https://astroignite.dev/es/blog/lighthouse-as-a-build-target/Tratar el rendimiento como una invariante que el build impone — contratos de presupuesto en frontmatter y CI que falla antes que regresión.Fri, 15 May 2026 00:00:00 GMT<p>La mayoría de equipos tratan Lighthouse como un chequeo de salud trimestral. astro-ignite parte de la idea opuesta: el rendimiento es un test, no una métrica — tu build falla antes de que la regresión llegue a producción. La mecánica no es novedosa; la disciplina sí.</p> <p>Este post explica el contrato de presupuesto, lo que aprendimos migrando cuatro proyectos, y por qué los agentes manejan especialmente bien este tipo de restricción.</p> <h2>El contrato de presupuesto</h2> <p>Cada ruta puede declarar su presupuesto de rendimiento junto a la ruta misma, no en un config global. CI ejecuta Lighthouse contra el build de producción y rechaza el merge si algún score baja de 95 o el bundle de JS crece más de un 5%.</p> <pre><code>export const budget = { lcp: 2500, // ms cls: 0.1, inp: 200, // ms — antes FID pre-2024 js: 18000, // bytes, gzipped }; </code></pre> <p>Mantener el presupuesto en la ruta hace que cambiarlo sea una revisión de código, no una conversación de ops. El reviewer ve el delta del presupuesto en el mismo diff que la funcionalidad que lo necesitó. Eso solo ya atrapa la mayoría de las regresiones antes que CI.</p> <h2>Lo que aprendimos</h2> <p>Llegar a 100 una vez no es lo difícil. Mantener el 100 mientras se agregan funcionalidades sí. Trata el rendimiento como tratas a los tipos: una invariante que el build impone. El primer mes de cualquier proyecto es ruidoso; la gente romperá el presupuesto sin querer. Después de eso, el equipo se auto-edita. Las descripciones de PR empiezan a incluir deltas de presupuesto sin que nadie lo pida.</p> <h3>Modos de fallo</h3> <p>El falso positivo más común es una medición de LCP inestable en caché frío. Ejecuta Lighthouse tres veces por ruta y toma la mediana. El positivo <em>real</em> más común es una imagen nueva sin <code>width × height</code> explícitos. Una regla de lint lo atrapa barato.</p> <blockquote> <p>El rendimiento es una feature. En el momento en que lo haces falible, dejas de discutir sobre él.</p> </blockquote> <h2>Por qué encaja con agentes</h2> <p>Los agentes son buenos en optimizaciones pequeñas y locales y malos recordando restricciones globales. Los presupuestos como código les dan un feedback loop sobre el que pueden actuar — fallar, leer el diff, arreglar, reintentar. En la práctica los agentes convergen a un presupuesto que pasa en dos o tres iteraciones sin intervención humana.</p> <p>Cuidado con esto: si dejas que un agente ajuste dinámicamente el presupuesto para que un build falle pase, tendrás un sitio lento con el tiempo. Los presupuestos deben editarse a mano. El build impone el contrato; el contrato mismo queda fuera del alcance del agente.</p> <h2>Cierre</h2> <p>Los Lighthouse 100 no son un número de marketing. Son el artefacto de tratar el rendimiento como una invariante. astro-ignite trae estos presupuestos pre-cableados — modifícalos, ajústalos, cambia las métricas, pero no borres el chequeo.</p> https://astroignite.dev/es/blog/what-is-astro-ignite/https://astroignite.dev/es/blog/what-is-astro-ignite/astro-ignite es una CLI estilo shadcn para crear sitios Astro listos para producción con SEO, rendimiento, i18n, legal y email.Tue, 12 May 2026 00:00:00 GMT<p>astro-ignite es una CLI para empezar proyectos Astro desde algo más cercano a un producto terminado que a un starter vacío. Genera un sitio Astro real con rutas, content collections, SEO, i18n, páginas legales, consentimiento de analítica y un flujo de contacto ya conectado.</p> <p>Lo importante es la propiedad: el sitio generado es código dentro de tu repositorio. Después del scaffold no hay dependencia en runtime de astro-ignite, ni capa de framework oculta, ni obligación de seguir una ruta de actualización. Puedes conservar las convenciones, cambiarlas o borrarlas.</p> <h2>Por qué existe</h2> <p>La mayoría de sitios Astro repiten el mismo trabajo inicial: elegir estructura, preparar metadata, añadir content collections, configurar imágenes, construir navegación, pensar en páginas legales, añadir un banner de cookies y evitar que el rendimiento se degrade mientras haces todo eso.</p> <p>astro-ignite empaqueta esas decisiones en un scaffold para que empieces desde una base sólida en vez de una lista de tareas. Los defaults son opinados porque la calidad de producción necesita decisiones, pero siguen siendo visibles porque el resultado te pertenece.</p> <h2>Qué crea</h2> <p>Un sitio generado con astro-ignite puede incluir:</p> <ul> <li>Una home de marketing con patrones de layout listos para producción.</li> <li>Un blog basado en Astro content collections y MDX.</li> <li>Páginas de proyectos o casos de estudio para trabajo tipo portfolio.</li> <li>i18n nativo de Astro con rutas del idioma por defecto en <code>/</code> y traducciones bajo <code>/[lang]/</code>.</li> <li>JSON-LD tipado de Schema.org compuesto en un único grafo.</li> <li>Imágenes responsivas con dimensiones estables y salida optimizada.</li> <li>Selector de modo oscuro, selector de idioma, banner de cookies, RSS, sitemap, robots y manifest.</li> <li>Formulario de contacto con Astro Actions, validación, protección honeypot y el transporte de email que elijas.</li> </ul> <p>El objetivo no es esconder la complejidad. El objetivo es colocar las piezas correctas para que puedas inspeccionarlas, aprender de ellas y publicar con menos básicos pendientes.</p> <h2>Qué lo hace diferente</h2> <p>astro-ignite sigue el mismo espíritu que shadcn: no instalas una biblioteca caja negra, copias código que puedes poseer. La CLI es el instalador. Tu app es el producto.</p> <p>Ese enfoque importa para equipos pequeños y desarrollo asistido por IA. Los agentes trabajan mejor cuando el proyecto tiene convenciones claras, datos tipados, carpetas predecibles y ejemplos locales que copiar. Las personas reciben el mismo beneficio: menos decisiones quedan implícitas y el sitio sigue siendo editable sin aprender una abstracción privada.</p> <h2>Para quién es</h2> <p>astro-ignite está pensado para desarrolladores que quieren un punto de partida serio en Astro para sitios de marketing, blogs, sitios cercanos a documentación, portfolios y webs pequeñas de producto. Es especialmente útil cuando SEO, velocidad, internacionalización y código propio importan desde el primer día.</p> <p>No intenta ser un CMS, una herramienta de diseño ni un framework completo de aplicación. Te da la base de producción. Tú pones el producto, el contenido y las partes que hacen específico al sitio.</p> <h2>Hacia dónde va</h2> <p>El foco actual es un v1 sólido: plantillas suficientemente completas para publicar, una CLI que pregunta lo necesario y un registro de primitivas UI pensadas para Astro. Más plantillas y bloques pueden llegar después, pero la promesa central no cambia.</p> <p>Ejecuta la CLI, obtén un sitio y posee cada línea.</p>