I took fluin.io from 7MB to 1MB this week, and the embarrassing part is it only took a few hours. Here's what I did and how you can do the same.

I have to admit, I've been lazy for the last couple of years. I only focused on the fun parts of development: making something new and shipping it to the world. This meant I made some pretty lazy architectural decisions for fluin.io over the years.

For example, all of the blog content was downloaded directly from Firebase via JSON on every page load, regardless of what you were actually looking at. When I added an image to a blog post, I never pre- or post-processed it. That meant the homepage, with its article preview thumbnails, was pulling in giant full-resolution images and just shrinking them down in CSS. The result was a homepage around 7MB. I know. It's embarrassing for someone who cares about user experience and the health of the web.

What Got Me Moving

This week I was at Cloud Next and got inspired to think differently about how I organize and rely on agents for development. It's April 2026 and I haven't handcrafted code in months. I miss it, but if you look at the volume of fixes I shipped this week across the fluin.io GitHub repo and my other projects like the new stoic.fluin.io, I feel like things are actually working.

The Numbers

I got the bundle size down from 7MB to 1MB. That 1MB includes async-loaded content like 473kb of Google Analytics and other non-blocking preloaded resources, so the critical path is even leaner.

Now that the baseline debt is cleared, I can actually start worrying about real architectural problems, like whether running on Cloud Run with cold starts is meaningfully hurting my time to first byte (TTFB). That's a legitimate problem to solve. Serving 7MB thumbnails was not a legitimate problem to solve, it was just something I should have never done.

Easy Site Performance Wins You Should Make (if you're dumb like me)

Here's what I actually shipped this week. Most of these took under an hour with an agent doing the heavy lifting. Any of them could apply to your site.

  • Move markdown rendering to the API layer. If you're shipping raw markdown to the client and parsing it in the browser, you're making your users pay for work the server should do once. Render it server-side and cache the output. (ef03160)
  • Stop fetching everything on every page load. Pulling your entire content list from a database on every route is lazy architecture. Fetch only what the current page actually needs. (e901063)
  • Add an image proxy with resizing and caching. Raw images uploaded by humans are never the right size for the web. A simple proxy that resizes, compresses, and caches images can cut your page weight dramatically. (de90bf7, 9ebe169)
  • Add srcset support while you're at it for mobile. (c820b58)
  • Understand how lazy loading can hurt your critical path. Lazy loading sounds like a win, but if you're lazy-loading something needed immediately on page load, you're just adding a round trip. Audit what's deferred vs what should be preloaded. (7772828, a0c0046, 518e20a)
  • Ditch Angular Animations in favor of CSS view transitions. The Angular animations library is heavy. If you're only using it for simple transitions, native CSS view transitions do the same job with zero bundle cost. (372797b, 0c15bbc)
  • Remove heavy dependencies you're barely using. It's easy to pull in a component library or design system for two or three styles. Strip it out and write those styles by hand. The bundle savings are real. (a0abbb3)
  • Proxy and compress your API responses. If your data is coming from a third party without compression, put a proxy in front of it that gzips the response before it hits the client. (6d36386)
  • Fix your analytics so it's not blocking anything. A misconfigured analytics tag can throw critical errors and block rendering. Worth auditing, and worth making sure the script is non-blocking and deferred. (2cd11ca, 8c978f7)

The Bigger Point

I know it can feel like AI and agents are a big pain, and strongly correlated with putting more and more slop into the world. That's a real concern, but with a little human love, you can put LLMs to good use and make things better for yourself and for the people using your site. When I reviewed, tested, and directed the work this week rather than just accepting it, the results were genuinely better than what I'd been living with for years of "I'll fix it later."