Skip to content
Rezha Julio
Go back

Redesigning my blog, part 5: what I learned

5 min read

The redesign is done. For now. It’s never really done, because personal sites are the software equivalent of a car that’s always in the garage with the hood up. But the major work is finished, the series is wrapping up, and I want to look back at what actually worked and what didn’t.

This isn’t a postmortem. It’s a blog post. I’ll keep it honest.

Phased implementation beats big-bang rewrites

The single best decision I made was splitting the redesign into phases. Audit first, then new features (links collection, blogroll), then the visual overhaul, then polish. Each phase was independently deployable. When the typography changes broke the note layout, I could revert that one commit without losing the trailing slash fixes from two weeks earlier.

I’ve tried the big-bang approach before. Change everything at once, in a branch that lives for three months, and merge it all in one terrifying afternoon. The result was always the same: nothing shipped. The branch would drift so far from main that merging felt like defusing a bomb. Eventually I’d just abandon it and start over.

Phases meant I could ship something every week. Momentum matters more than perfection.

Things that got immediately deleted

Some ideas didn’t survive first contact with the actual site.

I added a “shipping data pipes” status line to the header. Thought it was funny and on-brand. Looked at it for about five minutes, felt embarrassed, and deleted it. It was trying too hard to be quirky.

I also renamed the navigation labels. “Posts” became “Logs”, “Links” became “Bookmarks”, and “About” became ”./about” in a terminal-cosplay phase. My wife asked me where the blog posts were. I almost changed them back, but the dropdown items inside still say “Posts”, “Notes”, “About”, so once you click, everything makes sense. The top-level labels are just flavoring. They’ve grown on me. Keeping them.

Then there were the hover animations. I had this elaborate scale-and-glow effect on the post cards. Looked great in isolation, on a page with one card. On a page with eight cards, it felt like the site was having a seizure. Stripped it down to a simple color shift.

Audit before you design

This is the thing I’d tell past-me if I could. The audit caught problems that would have been painful to fix later.

The trailing slash inconsistency was the big one. Some internal links had trailing slashes, some didn’t. Astro treats these as different routes. If I’d done the visual redesign first and then tried to fix URLs, I’d have broken every internal link I’d just carefully styled.

Self-hosting fonts early also paid off. By the time I swapped in JetBrains Mono during the visual phase, the infrastructure was already there. No FOUT debugging at the last minute.

Same with the render-blocking theme script. Fixing that during the audit meant I had a faster baseline before adding more CSS complexity. Performance problems are easier to prevent than to diagnose after the fact.

Accessibility is easier to build in than bolt on

I used <details> for the dropdown navigation, which gave me keyboard support for free. No custom JavaScript state management, no aria attribute juggling. The browser just handles it.

The view transition work had some nasty memory leak potential. setInterval timers that weren’t being cleared on page transitions, duplicate event listeners stacking up. I caught these during implementation because I was thinking about cleanup from the start. Using AbortController for event listener cleanup became a pattern I used everywhere. It’s one of those things where the upfront cost is tiny and the debugging cost of not doing it is enormous.

prefers-reduced-motion went in as part of the visual redesign, not as an afterthought. The typewriter animation respects it. The page transitions respect it. Adding it later would have meant auditing every animation individually.

AstroPaper is a good base

I like AstroPaper. The content collections work well, the RSS generation is solid, and the overall structure makes sense. The Astro content layer does what it’s supposed to do.

The challenge is making it look like yours and not like a theme demo. I found that typography and layout changes go much further than color changes. You can swap the entire palette and the site still reads as “AstroPaper with different colors.” Change the font stack, adjust the line height, widen the content area, and suddenly it feels different.

I kept all the core functionality: Pagefind search, RSS and Atom feeds, dynamic OG images. Didn’t need to rebuild any of that. The work was almost entirely in the presentation layer.

Honest assessment

The blog looks like mine now. That was the goal and I think I got there.

Some things are still rough. There’s no mobile sidebar, which is intentional but also lazy. I went with a simplified header nav on mobile instead of building a proper slide-out menu. It works, but it’s not great.

The typewriter animation on the homepage is fun. I like it. I also suspect some visitors find it annoying. I’m keeping it anyway because this is my site and I get to be a little self-indulgent.

I’ll keep tweaking things. That’s what personal sites are for. They’re never finished, and that’s fine.

The series

If you’ve followed along, here’s the full list:

  1. Part 1: The audit
  2. Part 2: The blogroll
  3. Part 3: From stock theme to terminal blueprint
  4. Part 4: The small stuff
  5. Part 5: What I learned (you’re here)

If you’re thinking about redesigning your blog, start with the audit. Ship in phases. Delete things that try too hard. The rest sorts itself out.


Related Posts