DEV Community: Vishal Agrawal

How We Build Blazing-Fast Websites with Astro (and Why It Beats a JS-Heavy Stack)

Vishal Agrawal — Sun, 19 Jul 2026 10:27:28 +0000

TL;DR

Astro ships zero JavaScript by default — pages render to static HTML, so they load fast without hydration overhead.

Islands architecture lets you add interactivity only where you need it, hydrated independently, instead of shipping one giant JS bundle.

We lean on client:visible / client:idle directives, astro:assets image optimization, content collections, and view transitions to hit 95–100 Lighthouse scores.

Astro is framework-agnostic — bring React, Svelte, or Vue components as islands without rewriting them.

It's the right call for content-and-marketing-heavy sites where speed and SEO matter more than app-like complexity.

Every developer has shipped the site that looked great in dev and crawled in production. A marketing page — mostly text and images — somehow pulls 400KB of JavaScript, blocks the main thread, and posts a Largest Contentful Paint that makes your Core Web Vitals dashboard turn red. The content didn't need a framework runtime. The framework shipped one anyway.

That mismatch — static content paying the tax of a client-side app — is exactly the problem Astro was built to kill. Over the last couple of years it's become our default for performance-critical marketing sites, and the speed difference isn't marginal. So here's the practical version: how we build fast websites with Astro, the specific techniques that move the needle, and the honest cases where you shouldn't reach for it.

Why Loading Speed Is Non-Negotiable in 2026

Speed stopped being a "nice to have" a while ago. Google's Core Web Vitals are a ranking factor, and Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift all reward pages that render fast and stay stable. Slower than your competitors and you rank below them, full stop.

It's also a conversion issue. The correlation between load time and bounce rate is well documented — every extra second of load time bleeds users before they read a word. For a marketing site whose entire job is to convert visitors, performance is the product.

The frustrating part is that most slow sites are slow by accident. They're content pages built on tools designed for applications, so they ship an application's worth of JavaScript to render a paragraph. Astro's whole thesis is: stop doing that.

What Actually Makes Astro Fast

Two ideas do most of the work.

Zero JavaScript by default. Astro renders your components to HTML at build time and ships no client-side JS unless you explicitly ask for it. A page of content becomes a page of HTML. The browser has almost nothing to parse, execute, or hydrate — it just paints. This alone eliminates the biggest cause of slow content sites.

Islands architecture. When you do need interactivity — a carousel, a search box, a menu — that component becomes an "island": a small, independently hydrated piece of interactivity in a sea of static HTML. Instead of hydrating the entire page, the browser hydrates only the islands, only when needed. You get interactivity where it matters and static speed everywhere else.

Put together: you ship the least JavaScript possible, and you ship it surgically. That's the foundation every technique below builds on.

How We Build in Astro: The Techniques That Matter

Here's the actual playbook we run on a performance-first Astro build.

1. HTML-first, JS-only-when-earned

We start every component as static. If it doesn't need to be interactive, it never becomes a client component. The default is HTML; interactivity is the exception you justify.

2. Selective hydration with client directives

For the islands that do need JS, we hydrate them precisely:

client:idle for non-urgent widgets (hydrate when the browser is free)
client:visible for below-the-fold components (hydrate only when scrolled into view)
client:media for interactivity that's only relevant at certain breakpoints
client:load reserved for the rare above-the-fold interactive element

Most sites default everything to load-on-hydrate; deferring islands to visible/idle is one of the biggest wins for Interaction to Next Paint.

3. Image optimization with `astro:assets`

Images are usually the real LCP culprit, not JS. Astro's built-in <Image /> component handles responsive sizing, modern formats (AVIF/WebP), and lazy loading automatically. We serve correctly sized, next-gen images without a manual pipeline — which quietly fixes most LCP problems.

4. Content collections for content-driven sites

Blogs, case studies, and resource libraries live in type-safe content collections (Markdown/MDX with schema validation). Content stays fast, structured, and version-controlled — no CMS runtime tax on the front end.

5. View transitions for app-like nav without the SPA weight

Astro's view transitions (ClientRouter) give smooth page-to-page transitions and can prefetch links, so navigation feels instant — without adopting a heavy client-side router or turning the whole site into a single-page app.

6. Framework-agnostic islands

We're not locked into one UI library. Astro lets us drop in a React, Svelte, Solid, or Vue component as an island where it earns its place — reusing existing components without a rewrite, and still shipping zero JS everywhere else.

7. Static-first deploy, SSR where needed

Most marketing pages are prerendered to static HTML and served from the edge (Vercel/Netlify/Cloudflare) for near-instant TTFB. For genuinely dynamic bits, Astro's server islands and SSR let us render just those on demand — without giving up static speed on the rest of the page.

The Results (and How to Verify Them)

The payoff of this approach is consistent: content pages that render fast, ship minimal JavaScript, and post green Core Web Vitals. In practice we routinely land Lighthouse performance scores in the 95–100 range on Astro marketing builds, with sub-second Largest Contentful Paint on a decent connection.

e.g., "Our site: LCP 0.8s, Lighthouse Performance 99, total JS shipped: 18KB." Real numbers from your own build are far more credible than generic claims. Run it through PageSpeed Insights and quote the actual results.

Astro vs the Usual Suspects (When It's the Right Call)

vs Next.js: Next is excellent for app-like, highly dynamic products. For content and marketing sites, Astro ships far less JS by default — you're not paying an app framework's overhead for a brochure site.
vs WordPress: WordPress carries plugin bloat and render-blocking scripts that tank performance. Astro's static output sidesteps that entire category of problem.
vs a no-code builder (Webflow/Framer): No-code wins when non-developers need to own and edit the site independently. Astro wins when you want maximum performance and full control and have engineers to maintain it. (In our shop we pick per project — Webflow when the client edits daily, Astro when raw speed is the priority.)

When You Should Not Use Astro

Honesty matters. Astro is not the answer for a heavily interactive, app-like product (a dashboard, a real-time tool) — that's what a full client framework is for. It's also overkill if a non-technical team needs to build and edit everything themselves with no developer involved; a no-code platform serves them better. Astro shines for content-and-marketing-heavy sites where speed and SEO are the priority. Match the tool to the job.

FAQ

Is Astro good for SEO?
Yes. Static, fast-loading HTML with strong Core Web Vitals is exactly what search engines reward, and Astro's output is clean and crawlable by default. Fast pages plus semantic HTML is the foundation of technical SEO.

Does Astro work with React or other frameworks?
Yes — Astro is framework-agnostic. You can use React, Svelte, Vue, or Solid components as hydrated islands, reusing existing components while keeping the rest of the page as zero-JS static HTML.

Can Astro handle dynamic content?
Yes. Beyond static generation, Astro supports SSR and server islands, so you can render dynamic pieces on demand while keeping the rest of the page static and fast.

Is Astro faster than Next.js?
For content and marketing sites, typically yes — because Astro ships zero JS by default while Next hydrates a client app. For highly interactive products, Next's model may fit better. Match the framework to the workload.

The Bottom Line

Fast websites aren't about a magic framework — they're about not shipping what you don't need. Astro makes that the default: static HTML first, JavaScript only where it earns its place, images optimized automatically, interactivity added as isolated islands. For content and marketing sites where speed, SEO, and conversion are the goals, it's the cleanest path we've found to a site that loads in a blink and stays green on Core Web Vitals.

Written by the team at *Windmark** — a strategy-first design & development studio. We build fast, high-converting websites the right way for each project: Webflow when your team needs to own and edit it, Astro when raw performance is the priority. See our work at thewindmark.com or start a conversation.*

AI Web Development vs No-Code Tools: Which Should You Actually Use in 2026?

Vishal Agrawal — Sun, 19 Jul 2026 10:11:26 +0000

TL;DR

"AI web development" (Cursor, Copilot, v0, Bolt, Lovable, Claude Code) and "no-code" (Webflow, Framer, Bubble) solve the same problem — ship faster — from opposite directions.

AI-assisted coding wins when you need custom logic, own the codebase, and have engineers to maintain it.

No-code wins when non-developers need to build and edit — especially marketing sites — without a deploy pipeline.

The real 2026 answer is usually hybrid: AI to scaffold, no-code to let the team own the front end.

Both are tools, not religions. Pick based on who maintains it in 12 months, not what's trending on your timeline.

You open your laptop to build a new marketing site. Two voices start arguing. One says "just prompt Cursor, it'll scaffold the whole thing in an hour." The other says "or drop it into Webflow and hand it to marketing, done." Both are right. Both are wrong. And the internet's takes are useless because they're written by people selling one side.

So here's a working developer's honest breakdown of AI web development vs no-code tools — where each genuinely wins, where each quietly costs you, and how to decide without picking a tribe. No hype, no "X is dead," just the trade-offs you actually live with after launch.

Why This Comparison Matters in 2026

A year ago these were two separate conversations. Now they've collided. AI coding assistants got good enough to generate whole working front-ends from a prompt, and no-code platforms bolted AI on top of their visual builders. The line between "writing code" and "not writing code" is blurrier than it's ever been.

The stakes aren't academic. Choosing wrong means one of two failure modes: you build a marketing site in raw code that your marketers can't touch (so every copy change becomes a Jira ticket), or you build an app-like product in a no-code tool it was never meant for (so you hit a wall and rebuild). The cost isn't the tool — it's the rebuild.

The useful frame isn't "which is better." It's "which matches the job, the team, and the timeline." Let's define the two camps first, because both terms have drifted.

What "AI Web Development" Actually Means Now

This isn't autocomplete anymore. In 2026, AI web dev spans a spectrum:

In-editor assistants — Copilot, Cursor, Claude Code — you're still writing code, the AI accelerates it.
Prompt-to-app generators — v0, Bolt, Lovable — describe a UI, get working React/Next.js code you can edit.
Agentic builders — tools that scaffold a repo, wire up components, and open a PR.

The common thread: the output is code you own. That's the whole point. You get a real codebase, real version control, real freedom to do anything the language allows. The AI collapsed the time to first draft, not the nature of the work. You still need someone who can read, debug, and deploy that code.

What "No-Code" Actually Means Now

No-code didn't stand still either. Webflow, Framer, and Bubble are visual builders where you assemble sites and apps without touching a codebase — and they've added their own AI layers (generation, personalization, content).

The common thread here: the platform owns the runtime. You trade some control for enormous leverage — a non-developer can build, edit, and ship independently, with hosting, CMS, and forms handled for you. For a huge class of projects (marketing sites, landing pages, content-driven sites), that trade is a win, not a compromise. The ceiling is lower than raw code, but most projects never hit it.

AI Web Dev vs No-Code: Head to Head

Factor	AI Web Development	No-Code Tools
Speed to first draft	Minutes (generation)	Minutes (templates/AI)
Ceiling / flexibility	Unlimited (it's code)	Bounded by the platform
Who can maintain it	Developers	Anyone (visual editor)
Ownership	Full — you own the repo	Platform lock-in risk
Custom logic / integrations	Anything	Limited to platform + plugins
Deploy pipeline	You manage it	Handled for you
Best-fit project	Apps, custom products, complex logic	Marketing sites, content, MVPs
The hidden cost	Maintenance burden	Migration cost if you outgrow it

Notice neither column is "worse." They're optimized for different owners and different jobs.

Where AI-Assisted Coding Genuinely Wins

Reach for AI web dev when the project is software: custom application logic, complex state, deep third-party integrations, or anything where you'll need to do something the platform vendor never anticipated. If your team is engineers who'll live in the codebase, AI-assisted coding gives you the speed of generation with the freedom of owning every line.

It also wins on portability. Your code isn't hostage to a vendor's pricing or roadmap. If a platform triples its price or sunsets a feature, code doesn't care. For a product you'll invest in for years, that ownership compounds.

The catch, stated honestly: AI writes the first 80% fast and the last 20% — the edge cases, the security, the "why is this re-rendering" — still needs a human who knows what they're doing. AI lowered the cost of starting, not the cost of maintaining.

Where No-Code Genuinely Wins

Reach for no-code when the bottleneck is people, not possibility. The classic case: a marketing team that needs to publish, test, and iterate on a website without a developer in the loop. On a no-code platform, a marketer ships a new landing page in an afternoon. In a hand-coded site, that's a ticket, a branch, a review, and a deploy.

No-code also wins on total cost for the right job. For a marketing site, you don't want to pay engineers to maintain a bespoke React app forever. A visual platform means the people who own the content also own the tool. That's not a limitation — for that job, it's the correct architecture.

The catch: you're renting the runtime. If your needs escape the platform's model, you migrate — and migration has a real cost. Choose no-code when you're confident the project fits inside the platform's lane for the foreseeable future. For most marketing sites, it does.

The 2026 Reality: It's Usually Hybrid

The "vs" framing is mostly a content trope. In practice the strongest workflow uses both. AI generates the wireframes, first-draft components, and copy; a no-code platform becomes where the marketing team owns and edits the final site. Tools like Relume already generate AI layouts that build straight into Webflow. AI for speed, no-code for ownership.

So the real question isn't "AI or no-code." It's: who needs to maintain this in 12 months, and what will they need to change? Answer that and the tool picks itself.

A Simple Decision Rule

Skip the debate, answer three questions:

Is it software or a website? Software (custom logic, app behavior) → AI-assisted code. Website (content, marketing) → no-code.
Who edits it after launch — developers or a non-technical team? Developers → code. Everyone else → no-code.
Will you outgrow the platform's model in 2 years? Yes → code. No → no-code (and enjoy the speed).

Two "code" answers → build it in code with AI. Two "no-code" answers → use the platform and don't over-engineer.

FAQ

Will AI replace no-code tools?
No. They're converging, not competing — no-code tools are adding AI, and AI tools are getting more visual. AI lowers the cost of writing code; no-code removes the need to. Both survive because they serve different owners.

Is AI-generated code production-ready?
The first draft, rarely. AI is excellent at scaffolding and boilerplate, but security, edge cases, and long-term maintainability still need an engineer's review. Treat AI output as a fast junior's draft, not a senior's final.

Should a startup use AI coding or no-code for its marketing site?
Almost always no-code (Webflow/Framer) — so the team can iterate without engineering time. Save AI-assisted coding for the actual product. Don't burn engineers maintaining a marketing site.

Can you use AI and no-code together?
Yes, and it's the strongest 2026 workflow: AI to generate wireframes, layouts, and copy; a no-code platform to build the final, editable site. Speed from one, ownership from the other.

The Bottom Line

"AI web development vs no-code tools" is a false fight. AI-assisted coding is the right call when you're building software your engineers own. No-code is the right call when non-developers need to own and edit a site — which describes most marketing websites. And the best teams don't choose a side; they use AI for speed and no-code for ownership. Match the tool to who maintains it, not to what's trending, and you'll rarely rebuild.

*Written by the team at Windmark - a strategy-first design & development studio and Webflow Premium Partner. We help teams pick the right path — AI-assisted, no-code, or hybrid — and then build the fast, high-converting site to match. Browse our work at thewindmark.com or start a conversation.

DEV Community: Vishal Agrawal

How We Build Blazing-Fast Websites with Astro (and Why It Beats a JS-Heavy Stack)

Why Loading Speed Is Non-Negotiable in 2026

What Actually Makes Astro Fast

How We Build in Astro: The Techniques That Matter

1. HTML-first, JS-only-when-earned

2. Selective hydration with client directives

3. Image optimization with astro:assets

4. Content collections for content-driven sites

5. View transitions for app-like nav without the SPA weight

6. Framework-agnostic islands

7. Static-first deploy, SSR where needed

The Results (and How to Verify Them)

Astro vs the Usual Suspects (When It's the Right Call)

When You Should Not Use Astro

FAQ

The Bottom Line

AI Web Development vs No-Code Tools: Which Should You Actually Use in 2026?

Why This Comparison Matters in 2026

What "AI Web Development" Actually Means Now

What "No-Code" Actually Means Now

AI Web Dev vs No-Code: Head to Head

Where AI-Assisted Coding Genuinely Wins

Where No-Code Genuinely Wins

The 2026 Reality: It's Usually Hybrid

A Simple Decision Rule

FAQ

The Bottom Line

3. Image optimization with `astro:assets`