From b13f505ae3a7c77b20c2c62bc0e036d4259d1ee0 Mon Sep 17 00:00:00 2001 From: Arkaprabha Chakraborty Date: Fri, 12 Dec 2025 10:29:01 +0530 Subject: [PATCH] ... --- ...ebuilding My Website: Faster and Leaner.md | 98 ++++++++++++++++ ...ebuilding-My-Website:-Faster-and-Leaner.md | 108 ------------------ 2 files changed, 98 insertions(+), 108 deletions(-) create mode 100644 entries/Rebuilding My Website: Faster and Leaner.md delete mode 100644 entries/Rebuilding-My-Website:-Faster-and-Leaner.md diff --git a/entries/Rebuilding My Website: Faster and Leaner.md b/entries/Rebuilding My Website: Faster and Leaner.md new file mode 100644 index 0000000..8f0c0fc --- /dev/null +++ b/entries/Rebuilding My Website: Faster and Leaner.md @@ -0,0 +1,98 @@ +Tags: #webdev #golang #htmx #performance #nextjs #optimization #tech + +![HTMX vs React](https://raw.githubusercontent.com/arkorty/blog/refs/heads/main/blob/htmx-vs-react.jpeg "HTMX vs React") + +**Proofread by LLM** + +# Rebuilding My Website: Faster and Leaner + +I recently rebuilt my website, and the project reminded me how modern web stacks can feel powerful—but also unnecessarily heavy—when all you really need is speed and clarity. + +My old site was built with Next.js. It started as a borrowed template and gradually grew into a bundle of features: GitHub widgets, sandboxed project previews, a small 3D solar system, typing animations, and other effects. All of it worked—just not quickly. + +The site consistently took **over one second** to become usable. For a personal website, that delay felt wasteful. Most visitors aren’t looking for an immersive app; they just want clean, readable information. + +You can still see the archived version [here](https://old.webark.in). + +--- + +## Why I Moved Away From Next.js + +Next.js wasn’t the villain; it’s great for full-scale applications. But for a mostly static website, the abstractions—SSR, hydration, client bundles, routing layers, and build pipelines—added more complexity than benefit. + +So I rebuilt everything using: + +* **Go + Echo** for fast, explicit server-side rendering and routing +* **Goldmark** for Markdown processing +* **HTMX** for small pockets of interactivity +* A minimal, industrial-feel design focused on readability + +This cut load times to **~300 ms** and made the system far easier to maintain. + +--- + +## Adding Features Back… and Hitting a Wall + +After reintroducing two dynamic parts—my GitHub stats and blog feed—load times increased to **~700 ms**. + +The slowdown came from one source: + +> The server waiting for external APIs before sending any HTML. + +This removed the benefits of fast SSR and added unnecessary latency. + +--- + +## HTMX as Lightweight AJAX + +To fix this, the page needed to load immediately without waiting for remote APIs. HTMX made this trivial. + +### Before (Blocking) + +* User requests `/` +* Server fetches GitHub data +* Server renders template +* HTML is finally sent + +### After (HTMX + AJAX) + +* Server instantly returns static HTML with placeholders +* HTMX makes background AJAX requests +* Returned fragments are swapped in + +This preserves fast first paint while still supporting dynamic data — without hydration or a client-side runtime. + +--- + +## Data Transfer: A Dramatic Difference (But Not Apples-to-Apples) + +The new site also transfers far less data on first load: + +* **Old website:** ~**670 kB** +* **New website:** ~**129 kB** + +The comparison **isn't apples-to-apples**—the old site had heavier visuals and more interactive components. +But the reduction still highlights how much unintentional overhead frameworks can accumulate. + +--- + +## Lessons From the Rebuild + +1. Minimal backends + progressive enhancement are often ideal for static-content sites. +2. SSR is only fast when your data is local; external APIs undo its benefits. +3. Small, targeted interactions don’t require an SPA. +4. Perceived performance matters most—send HTML quickly. + +--- + +## The Final Result + +The new website loads in about **300 ms** on a fast connection; the old one often took **2+ seconds**, and over **6 seconds** on slow 4G. The new approach stays under **2 seconds** on similar networks. + +These improvements come from: + +* HTMX-powered AJAX +* Much smaller data transfer (129 kB vs 670 kB) +* No heavy client-side runtime or bundler overhead + +I am rethinking how I want to build simple websites going forward: prioritize speed, reduce moving parts, and keep the bloat out. diff --git a/entries/Rebuilding-My-Website:-Faster-and-Leaner.md b/entries/Rebuilding-My-Website:-Faster-and-Leaner.md deleted file mode 100644 index cdf433b..0000000 --- a/entries/Rebuilding-My-Website:-Faster-and-Leaner.md +++ /dev/null @@ -1,108 +0,0 @@ -Tags: #webdev #golang #htmx #performance #nextjs #optimization #backend - -![Go + HTMX Architecture](https://raw.githubusercontent.com/arkorty/blog/refs/heads/main/blob/htmx-vs-react.jpeg "HTMX vs React") - -**Co-authored by LLMs** - -# Rebuilding My Website: Faster and Leaner - -I recently rebuilt my website, and the project turned out to be a great reminder of how modern web stacks can feel powerful—but also unnecessarily heavy—when all you really need is speed and clarity. - -My old site was built with Next.js. It started as a borrowed template and slowly grew into a bundle of features: GitHub activity widgets, sandboxed project previews, a little 3D solar system, code-typing animations, and other decorative interactions. All of it worked—just not quickly. - -The site consistently took **over one second** to become interactive. For a personal website, that delay felt wasteful. Most visitors aren’t looking for an immersive app; they just want clean, readable information. - -You can still see the archived version [here](https://old.webark.in), and you’ll immediately notice the difference. - ---- - -## Why I Moved Away From Next.js - -Next.js wasn’t the villain here. It’s great for full-scale applications. But for a simple, mostly static website, the abstractions—SSR, hydration, client-side bundles, routing layers, and build pipelines—added more complexity than benefit. - -So I rebuilt everything using a simpler stack: - -* **Go + Echo** for fast, explicit server-side rendering and routing -* **Goldmark** for Markdown processing (server-side, no client-side parsing) -* **HTMX** for small pockets of interactivity without a front-end framework -* A minimal, industrial-feel design focused on speed and readability - -This alone cut load times to **~300 ms**. Pages rendered instantly, the codebase shrank dramatically, and the whole system felt easier to reason about. - ---- - -## Adding Features Back… and Hitting a Wall - -With the core structure working beautifully, I reintroduced two dynamic pieces: - -* My GitHub contribution stats -* My blog feed - -Almost immediately, load times jumped from ~300 ms to **~700 ms**. - -That wasn’t terrible—but it *felt* like a step backward. The slowdown wasn't caused by Echo, HTMX, or Go. It was caused by *where* I was fetching data: - -> I was calling external APIs during the request cycle, blocking the entire render until GitHub responded. - -No HTML was sent until the GitHub API call completed. And without framework-level abstractions like caching or static generation, the delay hit the user directly. - ---- - -## HTMX as Lightweight “Hydration” - -The fix was obvious once I saw the bottleneck: don’t make the initial page load wait for remote APIs. - -Instead, I shifted from **blocking SSR** to **progressive loading** using HTMX. - -### Before (Blocking) - -* User requests `/` -* Server fetches GitHub data -* Server renders the template -* Only then does HTML get sent back - -### After (HTMX-enhanced) - -* User requests `/` -* Server immediately returns static HTML (with placeholders) -* HTMX fires background requests to fetch stats -* Received fragments are swapped into the page - -This change preserved the super-fast initial load **without** sacrificing dynamic data. - -The page becomes visible almost instantly, and the asynchronous HTMX swaps feel natural—similar to hydration, but without any client-side runtime or heavy JS bundles. - ---- - -## Lessons From the Rebuild - -1. Not every site needs a full framework; For mostly-static content, a minimal -backend + progressive enhancement often wins in clarity and speed. - -2. SSR is only fast when your data is local; If your render pipeline waits on -third-party APIs, you're no longer doing “fast SSR”—you’re doing “SSR with -built-in delays.” - -3. Interactivity doesn’t require an SPA; HTMX continues to prove that small, -targeted interactions can replace entire client-side frameworks. - -4. Perceived performance matters most; Sending HTML quickly has a bigger impact -than many deep optimizations that happen later. - ---- - -## The Final Result - -The new website is dramatically faster and lighter. It takes about **300 ms** -to completely load on a fast connection, while the old one used to take over -**2 seconds**. It makes a bigger difference on a slow 4G network, the old site -takes **over 6 seconds** to load. The new one loads under **2 seconds**, under -similar conditions. - -That improvement comes from: - -* Simple HTMX-powered AJAX -* ~10× less bloat transferred -* No hydration, no bundlers, no labyrinth of abstractions - -The rebuild didn’t just improve the site, it clarified how I want to approach simple websites going forward: focus on speed, reduce moving parts, and keep the bloat out.