How This Website Works: A Technical Look at the Stack | Ammar NajjarSkip to content

×

On this pageThe Big Picture<br>Toolchain: Bun Instead of npm<br>Astro: Static by Default<br>JavaScript Delivery<br>Loading Performance and Core Web Vitals<br>Visual Design<br>Content Collections<br>Routing and Pages<br>Internationalization<br>Image Handling<br>Optimization and Responsive Variants<br>Automatic Dimension Injection<br>SEO and Discoverability<br>HTML Head<br>Sitemap<br>RSS Feeds<br>robots.txt<br>llms.txt<br>Deployment: GitHub + Cloudflare Pages<br>CI: GitHub Actions<br>HTTP Headers<br>Redirects<br>Comments: Giscus<br>The Full Picture<br>Where Does AI Fit In?<br>Your Turn<br>How This Website Works: A Technical Look at the Stack<br>Ammar Najjar · Posted on July 19, 2026, astrocloudflaredevopsarchitecturetoolsai<br>TL;DR A complete technical breakdown of how this site is built, from Bun + Astro content pipeline to Cloudflare deployment, minimal JavaScript, and performance optimizations.In a companion article, I wrote about why I rebuilt this website with Astro and how that decision grew into a much larger project. That article was about the journey and the thinking. This one is about the outcome: how the website actually works, every layer from writing a post to it appearing in a reader’s browser.

The Big Picture

At its core, the website is a static site. Every page is generated at build time and shipped as plain HTML, CSS, and minimal JavaScript. There is no server rendering requests, no database, and no runtime infrastructure to maintain. What Cloudflare serves to readers is exactly what Astro produced during the build.

┌──────────────────────────────────────────────────────────────┐<br>│ Author │<br>│ Write Markdown/MDX → git push → GitHub │<br>└───────────────────┬────────────────────────┬─────────────────┘<br>│ PR (parallel) │ merge to main<br>▼ ▼<br>┌────────────────────┐ ┌──────────────────────────────────┐<br>│ GitHub Actions │ │ Cloudflare Pages │<br>│ build check only │ │ build → deploy to CDN │<br>│ (no deploy) │ │ PR → preview at *.workers.dev│<br>└────────────────────┘ └──────────────┬───────────────────┘<br>Reader's Browser<br>(HTML + CSS + ~0 JS per page)<br>That simplicity is intentional. Static sites are fast, cheap, and straightforward to reason about. The toolchain around them can still be interesting though, and that’s what this article explores.

Toolchain: Bun Instead of npm

The project requires Bun >=1.0.0 as its JavaScript runtime and package manager. Bun replaced npm during the migration, and the difference in day-to-day experience is noticeable. Installation is faster, the lockfile (bun.lock) is more compact, and the commands feel snappier for a project of this size.

The package.json scripts are straightforward:

"scripts": {<br>"dev": "astro dev",<br>"build": "astro build",<br>"preview": "astro preview",<br>"deploy": "bun run build && wrangler pages deploy dist/ --project-name=website"<br>bun run dev starts a local dev server with hot module reloading. bun run build produces the static output in dist/. The deploy script is a local escape hatch: in practice, production deploys happen automatically through Cloudflare Pages’ git integration rather than manually.

Astro: Static by Default

Astro is the framework responsible for transforming content and components into the pages that ship to readers. The configuration reflects a clear set of priorities:

// astro.config.mjs<br>export default defineConfig({<br>site: "https://ammar-najjar.com",<br>trailingSlash: "always",<br>output: "static",<br>markdown: {<br>shikiConfig: { theme: "css-variables" },<br>rehypePlugins: [rehypeImgDimensions],<br>},<br>integrations: [<br>mdx(),<br>sitemap({<br>filter: page => !page.includes(".xml") && !page.includes("/404/"),<br>}),<br>],<br>});<br>output: 'static' means the build produces pure HTML files. The site runs entirely as static assets on Cloudflare Pages, with no server adapter needed.

JavaScript Delivery

One of Astro’s core design principles is shipping zero JavaScript by default. Every .astro component renders to static HTML at build time and sends nothing to the browser unless you explicitly opt in with a client:* directive. This site uses none of those directives. Every component is purely server-rendered HTML.

The only JavaScript that actually ships to readers is:

A small inline script in that reads localStorage and applies data-theme before first paint, preventing a flash of wrong theme

A script that wires up the dark mode toggle button and the locale switcher

The Giscus comment widget, loaded lazily only when a reader scrolls to the bottom of a post

That’s it. No framework runtime, no hydration overhead, no component tree bootstrapping in the browser. The previous site (Docusaurus, built on React) shipped a full React runtime and component bundle on every page regardless of whether any interactivity was needed. The difference in bundle size is significant: most pages on this site deliver under 10KB of JavaScript, compared to the 100-200KB React bundle that loaded unconditionally before.

Loading Performance and Core Web Vitals

Core Web Vitals measure three...