noderank . dev
All posts
Tutorials · 3 min read

Why I use Astro for every new landing page

Astro's zero-JS-by-default approach, content-first routing and native i18n make it the fastest way to ship a marketing site that actually ranks.

ShareCopied!

I’ve shipped around two dozen landing pages over the last couple of years, and for the last year I haven’t picked anything other than Astro. Here’s why.

The problem with most landing stacks

Most “modern” frontend stacks were built for app developers, not marketing sites. You pick Next.js because that’s what’s on the job ads, ship a 250KB JS bundle for a page that has three buttons, and then spend a week trying to stop Core Web Vitals from sinking your Lighthouse score.

For a landing page I want three things:

  1. Zero JS by default. If a section doesn’t need client interactivity, it shouldn’t ship any.
  2. Content in git. I don’t want a headless CMS for a page I update twice a month.
  3. Good SEO out of the box. Sitemap, meta, canonical, hreflang — all wired up without extra plugins.

Astro gives me all three without any ceremony.

What makes Astro click

Static-first, but not locked in

Astro renders HTML at build time. If you need interactivity, you opt in per-component with client:load, client:idle, or client:visible. The interactive bits become “islands” — isolated JS bundles that hydrate independently.

---
import Counter from './Counter.tsx';
---
<h1>Hello world</h1>
<Counter client:visible />

The <h1> ships as plain HTML. The <Counter> only downloads and hydrates when it scrolls into view. On a typical landing I end up with 15–20KB of JS total, most of it for the mobile menu.

Built-in i18n routing

If you’re building anything bilingual — and a lot of my clients ask for RU + EN — Astro’s i18n config just works:

export default defineConfig({
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'ru'],
    routing: { prefixDefaultLocale: false },
  },
});

Your English pages live at /about, your Russian ones at /ru/about. You get Astro.currentLocale for free, and the sitemap integration picks up the locales automatically.

Content Collections for non-CMS content

When you’re big enough to need a blog but small enough that a CMS is overkill, content collections hit the sweet spot:

  • Markdown or MDX files in src/content/
  • Typed frontmatter with Zod schemas
  • Autocomplete and type errors when you reference missing fields

That’s exactly the kind of “right-sized” tooling I want on a marketing site.

When not to pick Astro

Astro is great for content-heavy, mostly-static sites. It’s not the right call for:

  • Highly interactive SaaS dashboards — use Next.js or a dedicated SPA framework
  • Apps with heavy client state — the islands model starts to feel awkward
  • Things that need a lot of server-rendered user data per request — possible with Astro’s SSR, but other frameworks are more ergonomic

For a landing page, though, nothing else comes close.

The workflow I settled on

Every new landing starts from the same template:

  1. astro create with Tailwind v4 and Preact
  2. @fontsource-variable/inter + @fontsource-variable/jetbrains-mono for self-hosted fonts
  3. @astrojs/sitemap, astro-seo, astro-icon for the basics
  4. A shared design-system CSS file with tokens and primitives
  5. One Layout.astro with the header, footer and SEO component

It takes me about an hour to get to a blank home page that’s already scoring 100 in Lighthouse. The rest is just writing.

Next time you’re tempted to reach for Next.js to build a 5-page marketing site — try Astro first. You’ll probably never go back.

ShareCopied!