When I first looked at Astro, the promise of shipping almost no JavaScript was hard to resist. Once a content site is real, though, fonts, CSP, CMS updates, and previews interrupt me more often than a few kilobytes on the homepage. Astro 6 Beta made me happy because it pays attention to these unglamorous problems that do not fit neatly into a benchmark.
Astro has long suited blogs, documentation, and brand sites. It produces HTML first and sends JavaScript only to the parts that need interaction, which is the easiest way to understand its Islands architecture.
Astro 6 Beta added a new development server, a Fonts API, CSP support, and Live Content. The Fonts API offers a consistent loading path; CSP restricts which sources may execute code; Live Content allows updates without necessarily rebuilding the whole site.
These features do not turn Astro into another Next.js. Its focus remains content sites, while common needs around fonts, security, and dynamic data become more complete.
Most blog pages contain an article and little interaction. Astro treats them as HTML, then loads a component locally for search, comments, or a chart. Compared with a React-centered site, it provides less full-stack integration and sends less unnecessary browser JavaScript.
A beta is better for understanding direction than for immediately migrating production. Adapter, CMS, and Markdown plugin compatibility often matters more than the headline features.
Live Content is particularly interesting for editorial teams. Traditional static sites rebuild after every article update, and the wait grows with the site. Fetching content at request time shortens publishing, but the page is no longer completely static, so caching and source reliability become part of the design.
Neither model is inherently more modern. A personal blog updated once a day may be perfectly happy with a five-minute build; a news or pricing page that changes every minute should not wait for a full rebuild. I would measure publishing frequency and acceptable delay before deciding which collections truly need to be live.
CSP has a similar reality. Enabling an option is easy; inventorying analytics, embeds, and inline scripts takes the time. During a beta trial I would begin in report-only mode, collect violations, and tighten the policy gradually rather than accidentally blocking resources needed by login or payment pages.