DEV Community

Cover image for I Built the Zimnovate Agency Site With Astro and Google PageSpeed Gave It a Perfect Score Here's Why You Should Learn Astro
vincent mugondora
vincent mugondora

Posted on

I Built the Zimnovate Agency Site With Astro and Google PageSpeed Gave It a Perfect Score Here's Why You Should Learn Astro

I'll be honest, when I first heard about Astro, I was skeptical. Another JavaScript framework? I already had React, Next.js was doing fine. Why bother?

Then I actually used it. I built the website for Zimnovate, my AI-native digital product studio based in Harare, Zimbabwe, with Astro, ran it through Google PageSpeed Insights, and got scores I'd never seen before on a site I actually built myself. That changed everything for me.

Let me tell you what Astro is, why it's architecturally different, and why it's worth learning, especially if you care about performance and SEO.


What Even Is Astro?

Astro is a web framework built around one radical idea: ship zero JavaScript by default.

Most modern frameworks (React, Vue, Svelte) are component-based and hydrate the entire page on the client. Even if your page is mostly static content, the user's browser still downloads and runs JavaScript to render it.

Astro flips this. It renders your components to pure HTML at build time. JavaScript only runs in the browser when you explicitly need it, and only for the specific components that need it.

This isn't just a config option. It's the core architecture.


The Architecture: Islands

Astro uses a pattern called Islands Architecture.

Think of your page as a static ocean with interactive "islands" floating in it. The ocean (static content, headings, text, images) ships as plain HTML. The islands (a navbar with a dropdown, a contact form, a live counter) are the only parts that hydrate with JavaScript.

---
// This runs only at build time zero runtime cost
const services = await fetch('/api/services').then(r => r.json())
---

<html>
  <body>
    <!-- Pure static HTML, no JS needed -->
    <h1>Zimnovate</h1>
    {services.map(service => <ServiceCard service={service} />)}

    <!-- This island hydrates only when visible -->
    <ContactForm client:visible />
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

The client:visible directive tells Astro: "only load this component's JavaScript when it scrolls into the viewport." You get full interactivity where you need it and zero overhead where you don't.

Other hydration directives include:

  • client:load — hydrate immediately on page load
  • client:idle — hydrate when the browser is idle
  • client:media — hydrate only on certain screen sizes

This level of control is something no other framework gives you out of the box.


What Google PageSpeed Actually Measures

Before I show you my scores, let me quickly explain what PageSpeed Insights tests, because it matters for understanding why Astro excels.

PageSpeed uses Core Web Vitals:

Metric What It Measures Good Score
LCP (Largest Contentful Paint) How fast the main content loads < 2.5s
FID / INP (Interaction to Next Paint) How fast the page responds to input < 200ms
CLS (Cumulative Layout Shift) Visual stability (no content jumping) < 0.1
FCP (First Contentful Paint) First pixel painted on screen < 1.8s
TTFB (Time to First Byte) Server response speed < 800ms

These metrics directly impact your Google search ranking. A slow site isn't just a bad user experience — it's an SEO penalty.


The Zimnovate Site: Astro + Tailwind CSS + Supabase

I built zimnovate.co.zw using Astro 4.x with Tailwind CSS and Supabase as the backend for blog content. No heavy UI library. Just Astro components, a clean layout, and a simple data layer.

The site has:

  • A landing page with the studio's positioning and services
  • A projects/case studies section
  • A blog powered by Supabase fetched at build time and rendered as static HTML
  • A contact section

Fetching Supabase Data at Build Time

This is where Astro really shines for a CMS-backed site. Instead of fetching blog posts on the client (slow, bad for SEO), the Supabase query runs once at build time. Every blog post page is pre-rendered to pure HTML before it ever reaches a user.

---
// src/pages/blog/index.astro
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  import.meta.env.SUPABASE_URL,
  import.meta.env.SUPABASE_ANON_KEY
)

const { data: posts, error } = await supabase
  .from('posts')
  .select('id, title, slug, excerpt, published_at')
  .eq('published', true)
  .order('published_at', { ascending: false })
---

<html>
  <body>
    <h1>Blog</h1>
    <ul>
      {posts.map(post => (
        <li>
          <a href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
            <p>{post.excerpt}</p>
            <time>{new Date(post.published_at).toLocaleDateString()}</time>
          </a>
        </li>
      ))}
    </ul>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

And for individual post pages using dynamic routes:

---
// src/pages/blog/[slug].astro
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  import.meta.env.SUPABASE_URL,
  import.meta.env.SUPABASE_ANON_KEY
)

// getStaticPaths tells Astro to pre-render a page for every post
export async function getStaticPaths() {
  const { data: posts } = await supabase
    .from('posts')
    .select('slug')
    .eq('published', true)

  return posts.map(post => ({ params: { slug: post.slug } }))
}

const { slug } = Astro.params
const { data: post } = await supabase
  .from('posts')
  .select('*')
  .eq('slug', slug)
  .single()
---

<html>
  <head>
    <title>{post.title}</title>
    <meta name="description" content={post.excerpt} />
  </head>
  <body>
    <article>
      <h1>{post.title}</h1>
      <div set:html={post.content} />
    </article>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

At build time, Astro calls getStaticPaths, gets every post slug from Supabase, and pre-renders a fully static HTML page for each one. When a user visits /blog/my-post, they get a cached HTML file — no database query, no JavaScript, instant load.

This is the best of both worlds: a dynamic CMS (Supabase) with the performance of a static site.


Why Astro Is Good for SEO Beyond the Scores

Performance is one part of SEO. But Astro helps in other ways too.

1. Server-side rendering by default

Content is in the HTML when the page loads. Crawlers don't have to wait for JavaScript to render your page they read it immediately. This is a massive advantage over React SPAs where content often depends on client-side fetching. With Supabase content pre-rendered at build time, every blog post is fully indexable the moment it's deployed.

2. Built-in sitemap support

npx astro add sitemap
Enter fullscreen mode Exit fullscreen mode

One command. Astro generates your sitemap automatically based on your routes — including every dynamically generated blog post page from Supabase.

3. Structured metadata is first-class

---
const { title, description, image } = Astro.props
---
<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:image" content={image} />
  <meta name="twitter:card" content="summary_large_image" />
</head>
Enter fullscreen mode Exit fullscreen mode

You're writing HTML. There's no abstraction layer hiding what goes into your <head>. What you write is what the crawler sees.

4. Automatic static optimization

Every page Astro can pre-render, it will no configuration needed. Your Supabase-backed blog posts are no exception. They're cached at the CDN edge, load instantly worldwide, and the crawler reads fully-formed HTML on the first request.


Framework Agnostic — Bring What You Know

One of Astro's most underrated features: you can use React, Vue, Svelte, Solid, and even plain web components all in the same project.

---
import ReactComponent from './ReactComponent.jsx'
import VueWidget from './VueWidget.vue'
---

<ReactComponent client:load />
<VueWidget client:idle />
Enter fullscreen mode Exit fullscreen mode

If you're learning Astro coming from React, you don't have to throw away everything. You can migrate gradually, use what you know, and let Astro handle the performance layer.


When Should You Use Astro?

Astro is a great fit for:

  • Agency and company websites - exactly what I used it for
  • Marketing and landing pages - static, fast, SEO-critical
  • CMS-backed blogs — pair it with Supabase, Sanity, or any headless CMS
  • Portfolios and personal sites - where first impressions matter
  • Documentation sites - content-heavy, mostly static

Astro is not the right tool for:

  • Highly interactive apps (dashboards, real-time tools) - Next.js or SvelteKit fits better
  • Apps that need complex client state across many routes - React + a state manager makes more sense

But for content-driven, public-facing sites? Astro is the best tool I've used.


Getting Started (It's Simpler Than You Think)

npm create astro@latest my-site
cd my-site
npm install @supabase/supabase-js
npm run dev
Enter fullscreen mode Exit fullscreen mode

The CLI walks you through setup, starter templates, TypeScript options, and whether to add Tailwind. You're running locally in under two minutes.

From there:

  1. Edit src/pages/index.astro this is your homepage
  2. Add your Supabase credentials to .env
  3. Fetch your data in the frontmatter (it runs at build time, not in the browser)
  4. Run npm run build and deploy to Vercel or Netlify

Final Thoughts

The web got bloated. We started shipping entire application runtimes to render a paragraph of text. Astro is a course correction a framework that takes performance seriously at the architectural level, not as an afterthought.

The Supabase + Astro combination hits a sweet spot I haven't found elsewhere: a proper relational database for content management, with the performance profile of a fully static site. You write to Supabase, trigger a rebuild, and every page is pre-rendered HTML at the edge. No client-side data fetching. No hydration penalty. Nothing for crawlers to wait on.

For me, building zimnovate.co.zw in Astro wasn't just a project. It changed how I think about what I ship to users. Every kilobyte of JavaScript has a cost. Astro just makes it very easy to not pay that cost unless you have to.


Vincent Mugondora — Software Engineer & Founder of Zimnovate, an AI-native digital product studio based in Harare, Zimbabwe. Building Africa-optimized software products.

Have questions about the Astro + Supabase setup? Drop them in the comments.

Top comments (0)