Performance teardown: why about.gitlab.com scores a D

We pointed Harpoon's deterministic engine at a fresh capture of about.gitlab.com, the GitLab marketing homepage. It's a polished, JavaScript-heavy page from a company that knows the web — which makes it a useful teardown, because the things dragging it down are the same things dragging down most modern marketing sites.

The engine scored it 46/100 — grade D. Here's the request-level story behind that number, and the short list of changes that would move it.

Every figure below is derived by the deterministic engine from a single cold capture — no raw capture, cookies, or response bodies are published, only the numbers. One capture is a snapshot, not a benchmark; a warm cache or a different geography would shift the timings.

The numbers

Metric	Value
Harpoon Score	46/100 (grade D)
Requests	150
Transferred	1.1 MB
Domains	5 (4 third-party)
Third-party share of bytes	7%
Load span	~2.8 s

Two things jump out. First, this is a first-party-heavy page — only 7% of bytes come from third parties, which is genuinely good and increasingly rare. GitLab isn't drowning in trackers. Second, almost all of the 150 requests and 1.1 MB are GitLab's own scripts, fonts, and CSS — which means the performance problem is one they fully control.

Where the score comes from

Harpoon builds the overall score from five weighted dimensions, so you can see exactly which one hurt:

Dimension	Sub-score
Render-blocking JS/CSS	0/100
Cache quality	0/100
Critical path length	77/100
Third-party overhead	83/100
Asset efficiency	90/100

The asset efficiency and third-party scores are strong. The page is sunk by two dimensions scoring zero: render-blocking resources and caching.

Issue 1: 89 render-blocking resources

The single biggest problem: 89 scripts and stylesheets are fetched before the browser can paint, with the last of them finishing around 3.36 s in. Until they resolve, the page can't render — so first paint is gated by the slowest of nearly ninety requests.

This is the classic modern-framework tax. A component-driven marketing page ships a large graph of JS chunks, and if they're loaded render-blocking, the user stares at nothing while the network works through them. The heaviest resource type on the page is script, at 527 KB — more than fonts (395 KB) and images (87 KB) combined.

The fix is well-trodden: defer or async non-critical scripts so they don't block paint, inline the small amount of CSS the first screen actually needs, and preload only the fonts and assets that first paint depends on. Even moving the bulk of that JS off the critical path would pull first paint forward by seconds.

Issue 2: 977 KB of assets with weak caching

The second zero: roughly 977 KB of assets lack adequate cache headers. On a repeat visit, the browser has to revalidate or refetch assets it already has — work that a long Cache-Control: max-age with a content hash in the filename would eliminate entirely.

For fingerprinted static assets (hashed JS/CSS/font filenames that change when their content changes), the standard is Cache-Control: public, max-age=31536000, immutable. It's one of the cheapest wins in web performance: a header change, no code change, and every returning visitor benefits.

What GitLab does well

A fair teardown says so. The third-party footprint is small and well-contained. The engine flagged only ~118 KB of recoverable bytes from compression and right-sizing — meaning the assets themselves are already reasonably optimized. The problem isn't bloat; it's scheduling. The bytes are fine, they're just delivered in a way that blocks rendering and doesn't cache well.

The takeaway

about.gitlab.com is a good example of a page where the score is misleading if you stop at the grade. It's not a heavy, tracker-laden mess — it's a well-built page held back by two fixable delivery choices: too much render-blocking JavaScript, and caching left on the table. Fix those two and the same page would jump multiple grade bands without touching a single asset's contents.

That's the pattern we see over and over: the expensive-looking problems (bloat, third parties) are often fine, and the score is decided by a couple of unglamorous delivery settings. The only way to know which is which for your page is to look at the requests.

---

Want the same breakdown for your site? Drop a capture into the analyzer — it's free, no signup, and the AI only ever sees the findings, never your raw requests. New to HAR files? Here's how to export one.