The evolution of web frameworks and why Astro + Vue Islands is the state of the art

Island architecture with Astro and Vue is the state-of-the-art solution for websites that need 100/100 on Lighthouse without sacrificing interactivity or visual quality. It's not a last-minute optimization — it's an architectural decision made before writing the first line of a component. This post explains how we got here and how it works in practice.

The complexity spiral: how we ended up shipping 400KB of JS to display static text

Each generation of web frameworks solved a real problem for its moment:

• jQuery (2006) — abstracted cross-browser inconsistencies. Legitimate.
• Angular (2010) — brought structure to enterprise-scale applications. Legitimate.
• React / Vue (2013–2014) — reusable components, reactive state, declarative UI. Legitimate.

The problem wasn't any of these frameworks. The problem was that we started using them for everything — including sites that, 80% of the time, are static text and images that don't need reactive state or client-side hydration.

The result was predictable: sites with 400KB+ JavaScript bundles to display a portfolio. The browser downloads the JS, parses it, compiles it, executes it — and only then renders the content. The user sees a blank screen while all of that happens.

What Core Web Vitals started measuring — and Google started ranking

In 2021, Google incorporated Core Web Vitals as a ranking signal. The metrics that most impact the Lighthouse score are:

• LCP (Largest Contentful Paint) — time until the largest visible element loads. Weight: 25% of score.
• TBT (Total Blocking Time) — total time the main thread was blocked by JS, preventing it from responding to interactions. Weight: 30% of score.
• CLS (Cumulative Layout Shift) — visual stability during load. Weight: 15%.

A SPA built with React or Vue without Server-Side Rendering destroys TBT from the start — the entire JS bundle blocks the main thread on the first load. And even with SSR, you still pay the hydration cost for components that will never need reactive state.

Island architecture: Zero JS by default

Island architecture inverts the paradigm. Instead of loading a complete framework and deciding which parts are static, you start with pure static HTML and add interactivity only where it's needed — like islands in a sea of HTML.

Astro implements this natively. By default, it generates static HTML at build time. It sends no JavaScript to the client unless you explicitly request it with a hydration directive:

• client:load — hydrates immediately on load
• client:idle — hydrates when the main thread is free (without blocking LCP)
• client:visible — hydrates when the component enters the viewport

The result: HTML arrives at the browser already rendered. No hydration cost. No waiting. TBT at 0ms.

Vue as an island — the real case of leonleroy.com

At leonleroy.com — an architecture portfolio with 13 high-resolution photographs per project, three languages (ES/EN/FR), and fluid animations — I needed zero compromise between visual performance and user experience.

The final structure:

• Astro (SSG) as the main engine. All static content — text, navigation, project pages, about section — generated at build time. Zero JS sent to the client for these parts.
• Vue Hero Slider as an island with client:idle. The high-resolution image carousel hydrates only when the network is free — after critical content is already visible.
• Vue Mason Grid with client:visible. The masonry gallery hydrates only when the user scrolls to it. If they never get there, the JS is never downloaded.

Lighthouse mobile result: 100/100 Performance. LCP < 1s. TBT 0ms. CLS 0.

Sharp: the image pipeline that makes high-resolution photography possible without compromising LCP

The LCP in an architecture portfolio is almost always a photograph — the largest visual element on the page. An unprocessed 24MP RAW file destroys any Lighthouse score regardless of how good the framework is.

Sharp in Astro's build pipeline processes each image automatically during compilation:

• Converts RAW / JPEG to WebP and AVIF
• Generates multiple sizes for srcset based on the design's breakpoints
• Optimizes compression per dimension — doesn't apply the same quality to a thumbnail as to the hero

The result: the LCP photograph that originally weighed 3.8MB arrives in the browser at under 80KB with no perceptible visual loss. The browser downloads the exact size it needs, in the most efficient format it supports.

The decision criterion: when to use this stack and when not to

Astro + Vue Islands is the right solution when:

• The site is predominantly static content (portfolio, corporate site, landing pages, blogs)
• Interactivity exists but is punctual — sliders, modals, forms, filters
• Performance directly impacts the business — conversion, SEO, quality perception

It's not the right solution when:

• The application requires shared global state and real-time updates throughout the entire UI (complex dashboards, real-time collaborative apps)
• Most routes are authenticated and SEO doesn't matter

For those cases, Next.js with App Router or Nuxt remain the most mature options. The right architecture is not universal — it's the one that solves the specific problem of the product.

The conclusion that matters for business

A 100/100 Lighthouse score isn't a technical achievement to show in a demo. It's a measurable signal that the site was built with architectural criteria that have direct consequences:

• Organic ranking — Core Web Vitals are a ranking signal. A site with high TBT loses positions against one that doesn't.
• Conversion — every 100ms of additional load has a measurable impact on bounce rate. In B2B, where the prospect decides in seconds whether it's worth exploring, that translates to lost leads.
• Quality perception — a site that loads instantly communicates technical capability before the user reads a single line of copy.

Performance isn't an optional feature. It's infrastructure.