arkorty/blog
1
0
Fork 0
mirror of https://github.com/arkorty/blog.git synced 2026-03-18 00:57:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

...

Browse Source
This commit is contained in:
Arkaprabha Chakraborty
2025-12-12 10:29:01 +05:30
committed by GitHub
parent f9bfa37d1a
commit b13f505ae3
2 changed files with 98 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
entries/Rebuilding My Website: Faster and Leaner.md Normal file
View File

@@ -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.

108
entries/Rebuilding-My-Website:-Faster-and-Leaner.md
View File

@@ -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.