Hey folks, grab a coffee or whatever you're into, because I'm about to spill the beans on this fun little adventure I had recently. Picture this: It's a lazy afternoon, I've just wrapped up some work stuff, and I'm mindlessly scrolling through YouTube like we all do. Suddenly, this video pops up from ThePrimeTime (check it out here). It's all about website load times and this wild idea that your site should clock in under 14KB to be truly snappy. I mean, come on – 14KB? In 2025, with all these bloated JavaScript frameworks and fancy libraries we're slinging around? I was straight-up baffled. "No way," I thought. "That's gotta be impossible unless you're building a plain HTML page from the '90s."
But curiosity got the better of me, as it always does. The video dives deep into the why behind it, referencing this super insightful blog post over at endtimes.dev. If you haven't read it yet, do yourself a favor and click that link. It's packed with eye-opening stats and explanations on how even tiny delays in loading can tank user experience, especially on slower connections. Like, did you know that in some parts of the world, people are still rocking 2G or spotty Wi-Fi? Yeah, that post really hammered home why size matters in web dev – not just for speed, but for accessibility and keeping folks from bouncing off your site in frustration.
The Spark of Inspiration
Anyway, after watching that video, my brain was buzzing. I'd been putting off making a personal portfolio site for ages. Why? Pure laziness, my friends. I'm that dev who has a million ideas but somehow never gets around to personal projects. But this time, inspiration struck hard. "Alright," I told myself, "let's turn this into a challenge. Build something cool, keep it under 14KB, and make it actually useful – like a portfolio that shows off my skills without all the fluff."
Getting Started: Tools and Choices
So, where did I start? I went with the path of least resistance: Vite.js. If you're not familiar, Vite is this blazing-fast build tool that's perfect for modern web apps. It's simple to set up and handles a lot of the heavy lifting out of the box. But here's the catch – I initially thought about using React because, well, it's my go-to. Turns out, React's bundle size was way too chunky for my goals. No shade to React; it's awesome for complex stuff, but for a lightweight site? Nah.
That's when I remembered Preact. I've tinkered with it before, and man, it's a gem. Preact is basically a super-slim alternative to React – it weighs in at just a few KB, has compatible APIs, so you can drop in your React knowledge without missing a beat. Perfect fit! I fired up a new project, swapped React for Preact, and started building.
Now, to make things even more interesting (and challenging), I decided to throw Tailwind CSS into the mix. Yeah, I know – Tailwind can bloat things if you're not careful, but I wanted to prove I could keep it lean while styling an interactive site. The concept? A terminal-style portfolio. You know, like those old-school command-line interfaces, but web-ified. I vaguely remember seeing something similar years ago – maybe on some dev's GitHub or a tutorial? Can't find the link now, but it stuck in my head as this retro-cool way to present info. Imagine typing commands to navigate my about page, projects, or contact info. It's interactive, fun, and surprisingly engaging without needing heavy animations or libraries.
The Optimization Magic
The real magic happened in optimization. I dove into the vite.config.ts file to tweak things for better chunking – basically splitting my vendors and code into smaller, smarter bundles. This way, the browser only loads what it needs. And after enabling Gzip compression (which most servers do anyway), each file ended up under 13KB. Under 13KB! I was grinning like an idiot when I saw those numbers. It felt like winning a mini-hackathon against myself.
Wanna see it in action? Head over to moonshadowrev.me. Poke around, type some commands – it's all there. And if you're the code-curious type, the full repo is open on GitHub: github.com/moonshadowrev/moonshadow.me-portfolio. I even sprinkled in some basic SEO tricks, like meta tags and semantic HTML. It's not pro-level SEO wizardry, but hey, it's a start. Feel free to fork it, tweak it, or just browse for ideas.
Testing and Real-World Performance
Of course, I didn't stop at building – I had to test this bad boy. Fired up Google's PageSpeed Insights, and the scores were off the charts. Then, for the real torture test, I simulated a 2G connection in dev tools. Holy smokes, it loaded almost instantly. I've built sites before that chug on slow networks, but this? It was like butter. And get this: I'm hosting it on shared Hostinger plans, which aren't exactly known for lightning TTFB (more on that in a sec). Even with static HTML, CSS, and JS files served from a budget host, it performs like a champ. Proves you don't need fancy CDNs or VPS to make things fast if you optimize from the ground up.
Breaking Down the Jargon: Server Response Time and TTFB
Speaking of TTFB and all that jargon, let's break it down real quick because it's key to understanding why this matters. Server response time is basically how long your server takes to chew on a request and start spitting back data. It's the behind-the-scenes hustle before anything shows up on the user's screen. TTFB, or Time to First Byte, is a bit broader – it measures from the moment the browser sends the request until it gets that very first byte of response. This includes stuff like DNS lookup (finding the server's address), establishing a secure connection (handshakes and all), and the initial server processing. Why care? Because a snappy TTFB makes your site feel responsive right away, even if the full load takes a second. High TTFB can kill conversions, SEO rankings, and user patience. In my tests, keeping everything lightweight shaved off precious milliseconds here, making the whole experience smoother.
Wrapping It Up
Looking back, this project was a blast – a reminder that sometimes, constraints breed creativity. It pushed me out of my lazy rut and taught me a ton about performance without overcomplicating things. If you're a dev reading this, give it a shot. Optimize that next project, chase those low KB goals, and see how it feels.
What about you? Ever obsessed over TTFB or load times in your apps? Got tips, stories, or even critiques of my site? Drop 'em in the comments below – I'd love to chat and learn from ya. Let's keep the web fast and fun! 🚀
Top comments (0)