Lighthouse 13.4.1 · 2026-08-18

This site against Stripe, Linear, Column and Increase

I am Daniel Liu, a full-stack marketer and currently Senior Marketing Manager at ThinkingAI. I designed and coded all 70 pages of this site, including this one. More about me

The number to quote from this page is 84, the mobile performance score in the row below. It comes from Lighthouse 13.4.1 on the mobile preset, one run per homepage, every site on the same machine in one afternoon. Performance is the category that moves between runs; accessibility, best practices and SEO hold steady.

SitePerfA11y Best pr.SEOTBT ms
hi-daniel.com84100100100289
increase.com65945892170
stripe.com549658921028
column.com45777385484
linear.app4082881001033
The two sections below answer different questions. The mobile section shows what Google’s own machines record on a Slow 4G phone. The desktop section shows how far the same code swings when the run is repeated three times.

column.com is the site this one’s design language comes from. Competitor scores change. If a row overtakes mine, the next run says so.

Run it yourself on PageSpeed Insights
PageSpeed Insights · mobile

Moto G Power, Slow 4G

Emulated Moto G Power, Slow 4G, 4x CPU throttle, run on Google’s servers. A different machine produced the table above, which is why blocking time here reads 80 ms and the table reads 289 ms. Compare inside a table, never across the two.

Mobile · categories

Performance89
Accessibility100
Best Practices100
SEO100
Agentic Browsing2/2

Mobile · metrics

First Contentful Paint2.6 s
Largest Contentful Paint2.8 s
Total Blocking Time80 ms
Cumulative Layout Shift0
Speed Index4.6 s
PageSpeed Insights · desktop

Three runs: 70, 83, 97

Emulated desktop, custom throttling, no CPU slowdown. Three runs, same day, identical code. Performance moved 27 points; the other four categories did not move. The number I quote is the 70–97 spread.

Desktop · categories

Performance70–97 across 3 runs97
Accessibility100
Best Practices100
SEO100
Agentic Browsing2/2

Desktop · metrics

First Contentful Paint0.4 s
Largest Contentful Paint0.5 s
Total Blocking Time140 ms
Cumulative Layout Shift0.001
Speed Index1.0 s
Decisions

Six decisions, and the number behind each one

AI coding agents I direct wrote most of the code on this site, and I read every diff before it shipped. I specified every one of these six and rejected the default the agent reached for first: defer on the scripts, transform for touch targets, aria-hidden on inactive slides. The rejections are the part worth reading.

Total Blocking Time 300 ms → 100 ms

The homepage’s 50 scripts sit before </body> and carry no defer, deliberately. defer pushed them past First Contentful Paint, where Lighthouse starts counting blocking time. A/B on production: with defer, 300 ms and 83; without, 100 ms and 90. It cost 0.3 s of FCP. TBT weighs 30 in the score, FCP weighs 10.

measured both directions
Crawl 0 defects, 70 pages

A build script writes titles, descriptions, canonicals, Open Graph cards and JSON-LD from the filesystem, so they cannot drift from the pages they describe. I run six deterministic gates before every deploy, and a regression fails it.

2,855 internal links, 0 broken
Accessibility 100, both form factors

These three choices are for people who use a screen reader, people who move through a page by keyboard, and people who tap with a thumb on a phone. Tab panels sit on <section> because ARIA in HTML gives <article> six allowed roles and tabpanel falls outside them. Touch targets reach 24 px with a pseudo-element. A transform would push the button past its box and overlap its neighbor. I mark inactive slides inert, so the whole block leaves the tab order. Under aria-hidden they stay focusable and unannounced. The count below comes from axe, an accessibility scanner.

0 axe violations, 70 pages
Homepage weight 2,350 → 1,053 KB

The dot engine behind this site’s illustrations reads only light and dark, so every color channel in its source images was stored for nothing and the decoder threw it away. What it samples is Rec.601 luminance, the black-and-white brightness of a pixel. I re-encoded them to 8-bit greyscale, reproducing the engine’s alpha-threshold rule, and checked the luminance byte for byte. 111 files, 7.87 → 2.81 MB. Vendor logos draw at 16–20 px; one was a 204 KB multi-resolution .ico.

zero pixel deviation
Third-party requests 0

Fonts came from two external origins whose stylesheets pointed at a third, so first paint waited on a four-hop chain: 258 ms to the CSS, 813 ms to the last font. I host and subset all seven faces. One rule uses Newsreader at italic 500. It shipped as a variable font with two axes.

Newsreader 143.6 → 24.2 KB
Total Blocking Time 80 ms, mobile

Six of the desktop run’s seven long tasks were the same file: the full-viewport WebGL shader behind the hero. A machine with no GPU has to draw that shader on its processor, which leaves little room for anything else, so those machines now get the static gradient instead. The page checks WEBGL_debug_renderer_info and makes the switch on SwiftShader, llvmpipe and Microsoft Basic Render. Rasterizing in software costs 65 ms a frame on the CPU, so a GPU-less machine got 15fps and a pegged core.

687 ms of script time removed
Every number here comes from conditions I control: one owner, a static site, zero third-party requests, and no other team’s stack to work around. A company with stakeholders and an inherited tag stack starts somewhere else. What carries over is the method: measure both directions before deciding, and write down what the decision cost.