DEV Community: Rachid

title: "How We Built a Scalable Multi-Service Marketplace: Architecture & Lessons Learned"

Rachid — Tue, 04 Aug 2026 09:48:10 +0000

Connecting service providers with homeowners in real time comes with tough technical challenges: asynchronous job requests, local geofencing, real-time status updates, and scaling database indexing for dozens of categoris.

When we built Bricole, our goal was to create a fast, seamless service marketplace where users can connect directly with verified local professionals—from plumbing and electrical work to home healthcare.

In this article, Ill break down the architectural choices, tech stack, and key technical lessons we learned along the way.

Real-Time Matching

Instant connection between users and local service providers.

Scalable Backend

Cloud infrastructure structured for high concurrency and regional queries.

🛠️ The Tech Stack Overview

To balance mobile performance,rapid iterations, and developer velocity, we settled on a modern stack:

Mobile Frontend

Native Android built with Jetpack Compose and Material Design 3, giving us declarative UI rendering and smooth 60fps layout animations .

Backend & Infra

Powered by Firebase (Firestore, Cloud Functions, Auth) for real-time data sync and rapid API scalability across service hubs.

Key Architectural Challenges

1. High-Performance Mobile UI State

Managing asynchronous UI updates across job creation, provider tracking, and active status feeds required strict state boundaries. By leveraging Jetpack Compose state hoist strategies, we minimized unnecessary re-renders when polling position or processing updates.

2. Category & Location Indexing
A marketplace with categories ranging from plumbing to home care needs to serve fast search results without triggering heavy database reads. We restructured our database schemas to decouple static provider data from dynamic availability indexes.

Explore the platform on Bricole App

Lessons Learned

Keep Web & App Roles Clear: Use your web footprint as a high-converting gateway for discovery and SEO, while keeping deep provider interactions inside a responsive mobile application.
Optimize for Core Web Vitals Early: Web landing pages and gateway routes must load rapidly to maximize app install conversion rates.
Decouple Dynamic Data: Static metadata (service descriptions, standard pricing) should be aggressively cached, keeping real-time listeners strictly for active requests.

Looking for verified home services or interested in our engineering approach? Check out Bricole!

Visit Bricole

The 8 Performance Fixes That Finally Got My Astro Site to 100 on Mobile PageSpeed

Rachid — Sat, 01 Aug 2026 19:49:33 +0000

Still trying to hit that elusive 100 on PageSpeed Insights?

I was too.

I spent far longer than I'd like to admit stuck in the high 80s and low 90s on a real client project. I tried everything the internet recommends—compressing images, minifying JavaScript, lazy loading, removing unused CSS—and yet the score barely moved.

Mobile was the real challenge. That's where Lighthouse seems determined to humble you.

Eventually we got there on waxedoc.com, a waxing studio website I built with Astro.

Mobile PageSpeed:

✅ 100 Performance
✅ 100 Accessibility
✅ 100 Best Practices
✅ 100 SEO

(All tested in an incognito window so browser extensions weren't affecting the results.)

The interesting part is that there wasn't one magic optimization.

It was a collection of small improvements that, together, made a huge difference.

1. Start with a framework that ships less JavaScript

This almost feels unfair, but it's true.

Astro renders static HTML by default and only hydrates the components you explicitly make interactive through Islands Architecture.

For most pages on this site, the browser downloads almost no JavaScript during the initial load.

If you're building a content-heavy website, that gives you a head start before you've optimized a single line of code.

2. Stop loading fonts from Google Fonts

This change had a much bigger impact than I expected.

Using the standard Google Fonts <link> means the browser has to:

connect to fonts.googleapis.com
download the CSS
connect again to fonts.gstatic.com
finally download the font files

That's multiple network requests before your custom font even starts loading.

Instead, I downloaded the .woff2 files and hosted them locally.

@font-face {
  font-family: "Playfair Display";
  font-weight: 600;
  font-display: swap;
  src: url("/fonts/playfair-display-600.woff2") format("woff2");
}

font-display: swap is just as important—it allows text to appear immediately using a fallback font instead of staying invisible while the custom font downloads.

3. Preload only the fonts you actually use

One thing I learned is that browsers don't immediately download fonts just because they see an @font-face rule.

They first need to discover that an element actually uses that font.

Adding preload hints for fonts used above the fold helped reduce LCP.

<link
  rel="preload"
  as="font"
  type="font/woff2"
  href="/fonts/playfair-display-600.woff2"
  crossorigin
/>

One warning though: only preload fonts that are genuinely needed.

I had two font files declared in CSS that weren't used anywhere. Preloading them only wasted bandwidth and triggered Lighthouse warnings about unused preloads.

4. Inline your critical CSS

External stylesheets block rendering.

Until the browser downloads and parses them, it can't paint the page.

Astro makes this surprisingly easy.

// astro.config.mjs
export default defineConfig({
  build: {
    inlineStylesheets: "always"
  }
});

That single setting removes an extra network request before the first paint.

5. Give your LCP image real responsive images

This is one of the easiest mistakes to make.

Adding a sizes attribute by itself isn't enough.

Without a proper srcset, the browser still has only one image to choose from—which usually means your phone downloads the same massive image your desktop uses.

Astro's <Image> component makes this straightforward.

<Image
  src={image}
  width={image.width}
  height={image.height}
  widths={[480, 640, 768, 1024, image.width]}
  sizes="(min-width: 1024px) 50vw, 100vw"
/>

For your Largest Contentful Paint image (usually the hero), also add:

fetchpriority="high"

That tells the browser to prioritize downloading it instead of discovering it halfway through the waterfall.

6. Configure proper cache headers

This one's easy to overlook.

Hashed assets generated during your build are immutable, so they can safely be cached for an entire year.

On Firebase Hosting I added:

"headers": [
  {
    "source": "**/_astro/**",
    "headers": [
      {
        "key": "Cache-Control",
        "value": "public, max-age=31536000, immutable"
      }
    ]
  }
]

It's basically free performance.

7. Don't animate `box-shadow` or `text-shadow`

This one caught me by surprise.

The animations looked perfectly smooth, but Lighthouse flagged them as non-composited animations.

Animating shadows forces the browser to repaint every frame.

A better approach is keeping the shadow static and only animating opacity or transform.

.neon {
  text-shadow: 0 0 6px currentColor;
  animation: flicker 3s infinite;
}

.neon::after {
  content: attr(data-text);
  text-shadow: 0 0 14px currentColor;
  animation: flicker-glow 3s infinite;
}

Same visual effect.

Less work for the browser.

8. Avoid forced synchronous layouts

If you're repeatedly calling methods like getBoundingClientRect() during scrolling or dragging, you're probably forcing the browser to recalculate layout dozens of times every second.

Instead, read those values once and reuse them.

let box = null;

frame.addEventListener("pointerdown", () => {
  box = frame.getBoundingClientRect();
});

frame.addEventListener("pointermove", () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      // use the cached box
      ticking = false;
    });
  }
});

It doesn't sound exciting, but these little changes add up.

What actually got us to 100

There wasn't a single optimization that suddenly added 20 Lighthouse points.

It was fixing one small issue after another.

Fonts loaded a little faster.

Images became a little smaller.

Rendering started a little earlier.

JavaScript blocked the main thread a little less.

After enough of those improvements, the score finally reached 100.

More importantly, the site genuinely feels faster—not just in Lighthouse, but to real visitors.

If you'd rather see these optimizations on a real production website than a stripped-down demo:

See the actual site these optimizations shipped on—a live Astro-powered business website that consistently scores 100 on mobile PageSpeed Insights.

<a href="https://waxedoc.com" class="ltag-offer__button crayons-btn crayons-btn--primary">Visit Waxed OC</a>

I'd love to know: which Lighthouse audit has been the hardest for you to fix lately? Fonts? Images? Third-party scripts? Or something completely different?

Astro Is Built for Thousands of Static Pages. So Why Does Nobody Talk About It That Way?

Rachid — Fri, 31 Jul 2026 15:39:29 +0000

Most Astro content I come across falls into one of two buckets: "here's a nice website I built" or "here's how Astro compares to Next.js for a marketing page." Both fair, both true. But the site I work on doesn't look like either of those, and it's the use case I almost never see written about: hundreds of near-identical, dynamically generated pages, all needing to rank in search, all needing to load fast, in two languages and two markets.

Concretely: a home-services marketplace with city pages, service pages, and city × service combination page — the kind of programmatic SEO structure where the page count isn't in the dozens, it's in the hundreds today and headed toward tens of thouisands as the underlying data grows. That's a genuinely different problem than "make one fast landing page," and it turns out Astro is unusually well suited to it — better suited, in some concrete ways, than the frameworks that get all the programmatic-SEO blog posts.

The default that actually matters: zero JS unless you ask for it

Every "why Astro" post mentions the islands architecture. What gets undersold is what that means specifically for a large templated site: a city × service page — heading, worker cards, an FAQ block, some internal links — ships as plain HTML with no JavaScript bundle at all, by default. Not "a smaller bundle." None.

Compare that to a static export from a React-based meta-framework, where every page is still a component tree meant to hydrate, so you're shipping (and executing) framework runtime JS even for a page that never needs to do anything client-side. At one page, that's not a big deal. At a few hundred templated pages, each with real content and real images, it's the difference between a site that stays fast as it grows and one that needs constant bundle-splitting effort just to stand still.

In Astro, the handful of things that genuinely need JS — a filter widget, a search box — opt in explicitly, and you choose when:

astro

Everything else on the page is never shipped as JS at all, because it was never a component that needed to run in the browser — it just needed to render once, at build time.

Static generation that scales past "a few pages"

getStaticPaths() is the other underrated piece. It's not fundamentally different from what other SSGs offer, but in practice, generating a page per city, per service, and per city×service combination from plain data (JSON, a CMS, eventually a database) is exactly the shape of problem Astro's routing was designed around — and it stays boring at scale, which is what you want from build tooling. Add a new city to your data source, and the page exists at the next build with no template changes.

The place this gets interesting is exactly where it gets hard: once your data source stops being "a hundred hand-checked records" and starts being "tens of thousands of records from a real backend," you have to get deliberate about what actually deserves a static page versus what should be batched, tiered, or deferred — completeness of the underlying data becomes a real input into your routing strategy, not just an afterthought. That's less of an Astro-specific lesson and more a reminder that static-site scale problems are data problems first, framework problems second.

The sharp edge nobody warns you about

I wrote up one of these in detail recently: Astro's component can't gracefully handle a dead remote URL, because the actual network fetch happens inside an internal step that isn't part of the pluggable Image Service API — so one broken image URL in your dataset can take down an entire production build. Not a dealbreaker, but a real gap between "framework magic" and "framework you should validate your inputs before trusting."

The fix ended up being a small prebuild script that checks every remote image URL's reachability before Astro ever touches it, with a fallback UI for anything that fails the check. Worth knowing about before it takes down a deploy at 6pm on a Friday, not after.

Where it's genuinely not the right tool

To be fair to the frameworks that do get all the blog posts: Astro is not the right choice for the actual application layer. Our app itself is a separate native app; the Astro site is purely the public-facing, SEO-critical surface — city pages, service pages, profile pages. If you need authenticated dashboards, real-time state, or heavy client-side interactivity as the core product, reach for something built around that, not a static-first framework. Astro plays well as the SEO/marketing front door for a product that lives somewhere else, which is exactly our setup.

Why the silence, then?

My honest guess: programmatic SEO at real scale is a less glamorous problem than "look at this beautiful blog," so it doesn't get the same content. But if you're building a site where the page count is the whole point — city pages, product category pages, location pages, anything templated across a large dataset — the zero-JS-by-default model is doing more work for you than it gets credit for.

We run this pattern on

...

Visit Bricole

,
a bilingual marketplace across two North African markets — happy to go deeper on the pSEO/data side if that's useful to anyone hitting the same wall.

The Astro Image Gotcha That Broke Our Production Build and How We Fixed It

Rachid — Thu, 30 Jul 2026 23:07:05 +0000

We ship a bilingual (French/Arabic) marketplace site built on Astro — static output, hundreds of location plus service pages, and a few thousand professional profile pages, each with a photo pulled from Firebase Storage. Nothing exotic. Then one day the production build just... died. No warning during local dev, no failing test, no lint error. npm run build exited non-zero, and the stack trace pointed at astro:assets.

The cause, once I dug in: one profile's photo URL had gone stale. A Firebase Storage download token had rotated, so a request that used to return a JPEG now returned a 403. That's it. One dead URL, out of a few thousand, took the entire build down with it.

That surprised me, because I assumed Astro's image pipeline would fail soft on a bad remote image — log a warning, skip it, move on. It doesn't. Here's why, and what we did about it.

Why can't catch this

Astro's component and the underlying getImage() function both hand off to an Image Service, whose job is to transform() the image — resize it, convert format, whatever your config says. That's the part you can hook into and customize.

The problem is that transform() only ever receives an image that's already been fetched, as a raw buffer. The actual network request for a remote src happens earlier inside Astro's own internal loadRemoteImage step — whixh isn't part of the public, pluggable Image Service API. There's no supported hook that sits between "here's a remote URL" and "here's the fetched buffer" where you can intercept a failed request and decide what to do about it.

So from the framework's point of view, a 403 or a timeout on a remote image isn't a "handle this gracefully" situation — it's a fatal error during static generation. If even one image URL in your dataset is dead, the whole build stops.

The two-minute fix (and why it's not enough)

The fastest way out is obvious: swap for a plain tag. That sidesteps Astro's build-time fetch-and-transform step entirely, because a plain just emits the URL as-is and lets the browser deal with it at runtime.

That got our deploys unblocked immediately, but it's a real trade-off, not a fix — you lose automatic resizing, format conversion (WebP/AVIF), and the responsive srcset handling that's the entire reason to use in the first place. Fine as a stopgap. Not something to leave in place.

The actual fix: check before you build, not during

The real problem wasn't that Astro handles failures badly — it's that we were handing Astro URLs we hadn't verified. So we moved the verification earlier, into a prebuild step that runs before Astro ever touches an image.

The script is small: collect every unique remote image URL your pages will reference, HEAD-check each one with a timeout, and write the ones that fail to a JSON manifest.

js
// scripts/validate-image-urls.mjs
import fs from "node:fs";

const TIMEOUT_MS = 8000;
const CONCURRENCY = 10;

async function checkUrl(url) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), TIMEOUT_MS);
try {
const res = await fetch(url, { method: "HEAD", signal: controller.signal });
return res.ok;
} catch {
return false; // timeout, DNS failure, connection reset — all treated as "bad"
} finally {
clearTimeout(timer);
}
}

Two design decisions mattered more than the code itself:

Fail closed per URL, fail open in aggregate. If a single URL times out or errors, treat it as bad — that's the safe default for one image. But if, say, 70% of all URLs fail in the same run, that's not "most of our images died overnight," that's almost certainly the checker itself being broken — offline CI runner, DNS hiccup, rate limiting. In that case the script leaves the existing manifest untouched rather than blanking every photo on the site. A partial network failure in your validation step shouldn't be able to nuke your production content.

Hook it in with prebuild, not an Astro integration. We wired this through npm's own lifecycle ("prebuild": "node scripts/validate-image-urls.mjs" in package.json), which runs automatically before build. We deliberately skipped writing it as an Astro integration hook — it's simpler, it's fully decoupled from Astro's internal build order, and it'd survive a framework migration untouched.

On the component side, it's a one-line check:

astro

import { isBadImageUrl } from "../utils/badImageUrls";

const showFallback = isBadImageUrl(profile.thumbnail);

{showFallback
? /* render an initials avatar instead / null
: / render the optimized Image component with profile.thumbnail as the source */ null}

Known-bad URLs get a graceful fallback (initials avatar) instead of ever reaching . Everything else gets the full optimization pipeline as normal.

Does it actually work at scale?

The first real production run checked several thousand unique image URLs against the live network in a few seconds thanks to the concurrency limit, and it did exactly what it was supposed to: flagged a handful of genuinely dead URLs, left everything else alone, and the build stopped depending on the uptime of every single image host on the internet.

One small habit that paid off while shipping this: when I reverted the emergency fallback back to once the validator was in place, I diffed against git history (git show HEAD:path/to/file) instead of trusting my memory of what the original props looked like. Cheap insurance — worth doing any time you're undoing an emergency fix under time pressure.

The takeaway

If you're using Astro's or getImage() with remote sources you don't fully control — user uploads, a CMS, cloud storage — don't assume a bad URL fails gracefully. It doesn't, by design, because the fetch happens in a part of the pipeline you can't hook into. Validate before the build starts, not during it.

We run this on bricoleapp.com, a bilingual home-services marketplace for Morocco and Egypt — happy to go deeper on any part of this if it's useful.

DEV Community: Rachid

title: "How We Built a Scalable Multi-Service Marketplace: Architecture & Lessons Learned"

🛠️ The Tech Stack Overview

1. High-Performance Mobile UI State

The 8 Performance Fixes That Finally Got My Astro Site to 100 on Mobile PageSpeed

1. Start with a framework that ships less JavaScript

2. Stop loading fonts from Google Fonts

3. Preload only the fonts you actually use

4. Inline your critical CSS

5. Give your LCP image real responsive images

6. Configure proper cache headers

7. Don't animate box-shadow or text-shadow

8. Avoid forced synchronous layouts

What actually got us to 100

Astro Is Built for Thousands of Static Pages. So Why Does Nobody Talk About It That Way?

The Astro Image Gotcha That Broke Our Production Build and How We Fixed It

astro

const showFallback = isBadImageUrl(profile.thumbnail);

7. Don't animate `box-shadow` or `text-shadow`