Measuring Performance: Lighthouse and Core Web Vitals

Lighthouse is the standard tool for measuring web performance. Run it in Chrome DevTools (Lighthouse tab) or via the CLI (npx lighthouse https://yoursite.com). When evaluating Islands Architecture, run Lighthouse on representative pages before and after migration to quantify the gains objectively.

LCP measures when the largest visible content element finishes rendering. Islands Architecture improves LCP because the server sends fully rendered HTML immediately — the browser does not wait for JavaScript to render content. A hero image or headline that would be LCP is painted from the initial HTML response.

In a React SPA, LCP is often delayed because the browser must download and execute JavaScript before React renders the LCP element. With Islands Architecture, LCP content is in the initial HTML, so JavaScript execution does not block LCP. This is one of the most significant measurable benefits.

Total Blocking Time measures how long the main thread is blocked by JavaScript tasks longer than 50ms. Hydrating a large React SPA can produce hundreds of milliseconds of TBT. Islands Architecture drastically reduces TBT because the JavaScript executed is proportional to the number of islands, not the page size.

Cumulative Layout Shift measures visual stability — elements moving around as the page loads. JavaScript-rendered content can cause layout shifts when React renders and changes dimensions. Server-rendered HTML from Islands Architecture avoids hydration-related layout shifts because the initial layout comes from static HTML that does not change on hydration.

First Input Delay (now replaced by Interaction to Next Paint, INP) measures how quickly the page responds to user interactions. Islands architecture improves INP because each island has a small, focused JavaScript bundle. Interactions within an island execute fast because there is no large React tree to schedule work through.

A typical comparison for a blog page: a full React SPA might score 45-65 on mobile Lighthouse (TBT: 800ms, LCP: 3.2s). The same content as an Astro site with one React island might score 90-98 (TBT: 80ms, LCP: 1.1s). The gains are most dramatic on content-heavy pages with limited interactivity.

Islands Architecture is not the right choice for highly interactive applications like dashboards, code editors, or collaborative tools. These apps have components that constantly share state and re-render together — the overhead of cross-island communication would eliminate the performance gains and add architectural complexity.

Islands Architecture excels for content-heavy sites with scattered interactivity: blogs (read content, occasional like or comment), documentation (read docs, occasional search or copy-code button), landing pages (mostly static, newsletter form island), and e-commerce product pages (images and description static, add-to-cart island).

Google uses Core Web Vitals (LCP, INP, CLS) as ranking signals. Improving these metrics with Islands Architecture directly benefits search rankings. A site that improves its Lighthouse mobile score from 55 to 92 by adopting Islands Architecture gains both user experience and SEO benefits simultaneously.

Teams migrating from Next.js React SPA to Astro for marketing and documentation sites report consistent patterns: JavaScript payloads drop 70-90%, mobile performance scores increase 20-40 points, and server hosting costs decrease because static files are served from CDN without server-side rendering overhead per request.

Why does Islands Architecture dramatically reduce Total Blocking Time (TBT)?

Islands Architecture improves all Core Web Vitals: LCP benefits from server-rendered HTML, TBT drops because JavaScript is proportional to interactivity, CLS is reduced by stable server-rendered layouts, and INP improves with small focused island bundles. Lighthouse scores for content-heavy pages improve dramatically. The pattern is not suitable for highly interactive apps but excels for blogs, docs, landing pages, and e-commerce.