Optimization on Lorbic

Critical Rendering Path Optimization: 8 Proven Strategies to Boost Web Performance

Sat, 11 Apr 2026 16:00:00 +0530

TL;DR: The Critical Rendering Path (CRP) is how browsers convert code into pixels. Optimizing it means reducing bottlenecks at five stages: Network, Parsing, Tree Building, Layout, and Paint. Use this guide to reduce First Contentful Paint by 40-60%, improve Lighthouse scores, and master the eight optimization strategies that separate fast sites from slow ones.

To master web performance, stop guessing and start engineering. View the browser as a single-threaded virtual machine that must convert raw text into pixels 60 times per second. Every performance delay is a bottleneck in the Critical Rendering Path (CRP).

A Tale of Web Vitals

Sat, 11 Apr 2026 14:30:00 +0530

TL;DR: I achieved 95+ Lighthouse scores by removing abstractions and automating browser fundamentals. This guide details how to solve LCP network discovery, main thread congestion, and third-party accessibility traps using Hugo pipelines and vanilla JavaScript.

“Why is the LCP 4.2 seconds? It’s just a static site”.

I was staring at a Lighthouse report that felt like an insult. Lorbic.com is a zero-dependency Hugo site. No React, no heavy frameworks, just vanilla CSS and minimal JS. Yet, the mobile performance was tanking.

Go Struct Field Alignment: How Memory Padding Wastes Your RAM

Sat, 24 Jan 2026 10:00:00 +0530

You write a struct to represent a database entity. Maybe 10 fields, maybe 20. What could possibly go wrong?

Nothing, according to your tests. But somewhere in production, your heap is 30% larger than it should be, your Garbage Collector is working overtime, and your L1 cache is not used properly. The reason? Invisible padding bytes silently inflating every instance of your struct.

This is the story of struct field alignment: a memory optimization that costs nothing to implement but can significantly improve performance.

Go Garbage Collector Mechanics: Pacer, GOGC, and Allocation Latency

Wed, 07 Jan 2026 00:21:12 +0530

In the world of high-throughput backend services, we often obsess over the usual suspects of performance: database indexing, network latency, and algorithmic complexity. But recently, while debugging our core gateway service (backend-gw), I encountered a bottleneck that defied standard logic.

The service was CPU-bound, yet active heap usage was surprisingly low (~200MB). P99 latency was spiking at random intervals, but database queries were returning in milliseconds.

The culprit was not the business logic. It was memory management. I was effectively running a Denial-of-Service attack on my own runtime.