Every developer wants their website to be fast. But achieving a perfect 100/100 score on Google PageSpeed Insights while using a modern library like React is a challenge that requires more than just "clean code."
In this post, I’ll share how I built my portfolio and the specific steps I took to ensure it flies on both Desktop and Mobile.
🖼 The Proof
I didn't just aim for green zones; I aimed for perfection. Here are my latest Lighthouse results:
Desktop: 100/100 across the board.
Mobile: 95+ Efficiency, with 0ms Total Blocking Time.
🛠 My Technical Stack
Framework: React 18
Language: TypeScript (Strict mode)
Build Tool: Vite (for lightning-fast HMR and optimized builds)
Styling: SCSS Modules + BEM
Deployment: High-speed hosting with global CDN
🚀 Key Optimization Strategies
- Zero Layout Shift (CLS) One of the hardest metrics to master. I used CSS aspect-ratio and reserved space for my profile image before it even loaded. This ensured that the content didn't "jump" when the photo appeared.
- Mastering the Critical Rendering Path I used link rel="preload" for my Largest Contentful Paint (LCP) image. By setting fetchpriority="high", I told the browser to prioritize my main visual asset over everything else.
- Delayed Non-Critical Rendering I implemented a decorative "code background" that contains an SEO-rich article. To keep the First Contentful Paint (FCP) fast, I used a setTimeout strategy to mount this heavy component only after the core UI became interactive.
- Font Optimization Instead of blocking the render with Google Fonts, I used the print media query trick and font-display: swap to ensure text is visible immediately. 💡 What I Learned Performance isn't a "final step" — it's a mindset. Every library you add and every image you use must be questioned. As a developer based in Liberec, Czechia, I strive to bring this level of technical discipline to every project I touch. 🔗 Check it out live: I’d love for you to test the speed yourself and give me some feedback! 👉 www.webdevcompass.com What's your best tip for squeezing that last 5% out of mobile performance? Let's discuss in the comments! 👇
Top comments (2)
This was a solid read because it stayed grounded in the real work instead of turning performance into vague frontend mythology.
A lot of posts talk about Lighthouse like it is some magical badge you stumble into if you tweak enough random things. This did the opposite. It showed that strong performance is usually the result of deliberate choices stacking on top of each other: controlling layout shift, being honest about what needs to load first, stripping decorative weight off the critical path, and not letting fonts quietly sabotage the page.
That is the part I respect most. The score is nice, but the discipline behind it is the real story. Every dependency, render path, asset, and visual flourish either serves the experience or taxes it. Too many people build as if those costs are invisible until the audit exposes them.
Also worth saying: it is refreshing to see this done in React and TypeScript without the usual defeatist undertone that modern stacks are just doomed to be bloated. They are not. They just punish carelessness more aggressively.
Strong post. Not because it chases a perfect number, but because it makes performance feel like craft instead of superstition.
Thank you! I really appreciate your detailed feedback. It’s great to meet someone who values the discipline and 'craft' behind the performance scores. I’ll keep working on it to make the site even better. Cheers