DEV Community: Deian

The 34 pixels that made PageSpeed think my static site was slow

Deian — Thu, 03 Sep 2026 13:07:33 +0000

Originally published at deianisac.com.

TL;DR

On deianisac.com, Speed Index stayed near four seconds after the page looked finished. Lighthouse scores a video of the load, not Largest Contentful Paint. 34 one-pixel flecks on Deian Isac's arrival canvas kept the first screen changing.

That canvas now waits for a mouse move, tap, or key, not idle time. Clean Speed Index runs landed next to first paint. There is no Lighthouse user-agent check.

My static site looked finished after about 1.1 seconds. PageSpeed sometimes said it took four.

I looked for a huge hero, a JavaScript framework, and layout shift. It was 34 one-pixel flecks on a canvas.

This happened while I was rebuilding deianisac.com with Astro 7.2.10. The site ships static HTML, hand-written CSS, two small module scripts, and a few AVIF stills. I expected that to be boring to optimize.

It wasn’t.

The page was already done

The DebugBear filmstrip, not the score, showed the page visually complete at 883 ms. First Contentful Paint and Largest Contentful Paint both landed at 846 ms. The full TTFB was 404 ms, with no layout shift.

PageSpeed was less consistent. I saw Speed Index land at 1.1 s, 2.3 s, 4.1 s, then 3.9 s on the same deployed build.

Lighthouse calculates Speed Index from a video of the page loading. It compares the visual progression between frames. The browser can finish the largest element, satisfy LCP, and keep changing enough small pixels to drag out Speed Index.

My network waterfall was mostly innocent. The screenshots were not.

The 34 pixels

The arrival scene has a full-screen canvas over a static coast image. It draws 24 short dashes on the water and 34 tiny flecks in the air, about 30 times a second.

A person sees a little weather. Lighthouse sees a first screen that keeps changing.

I had deferred the canvas until the browser was idle. That made the result unpredictable. If the main thread became idle early, the animation started inside the measurement window. If it became idle later, Speed Index finished before the first fleck appeared.

Idle was the wrong trigger. The canvas now waits for real interaction.

window.addEventListener("pointermove", onPointerMove, { passive: true });
window.addEventListener("pointerdown", start, { passive: true });
window.addEventListener("keydown", start);

There is no Lighthouse user-agent check. A mouse move starts it on desktop. A tap starts it on a phone. A key press covers keyboard use. Visitors who only read the first screen do not spend CPU on decorative weather, and prefers-reduced-motion still skips it entirely.

Once started, the flecks ease in from the left instead of snapping into view.

That change pulled the clean Speed Index runs back beside first paint.

The images were still too big

The canvas explained the four-second result. Phones were downloading 1,672-pixel stills for much smaller slots.

I added 400, 800, 1,200, and native-width variants, with AVIF first and WebP as the next choice. Each `now has asizes` value that matches its layout, and the map stays lazy while the arrival image is eager and preloaded.

I also compressed the 800-pixel arrival AVIF from 30.0 KiB to 19.4 KiB. That removed the image-delivery warning without producing an obvious visual loss. Going lower did.

Changing the hero from synchronous to asynchronous decoding did not help. Across controlled runs, the median Speed Index moved by about 2 ms. That is noise, so I reverted it.

The page got cheaper to load. Bytes were never the whole problem.

A 244-byte placeholder

After the image work, the frames showed one small blemish. The text appeared over a flat blue fallback, then the coast arrived 37 ms later.

I looked at a ThumbHash approach for Astro and at astro-lqip. Fine if you have a folder of images. I had one hero.

The smallest thing that worked was a 48-pixel WebP generated from the same hero. It is 244 bytes. I put its base64 data URL behind the real `` as a CSS background, so it adds no request and no browser script.

.arrival__picture {
  background: var(--arrival-placeholder) center 52% / cover no-repeat;
}

A small local Lighthouse test produced this median across three simulated mobile runs:

Fallback	Speed Index	LCP
Solid sky color	922 ms	1,503 ms
Inline 48 px WebP	902 ms	1,502 ms

Twenty milliseconds is small. It closes the visible gap for roughly 350 bytes of HTML, so I kept it. I did not add a dependency or a blur transition.

The optimization I threw away

At one point I inlined some first-screen color, broadened font preloads to every page, and preloaded each inner-page hero. The dependency tree looked cleaner. The screenshots got worse, including one run that did not become visually complete until 8.56 s.

I liked that cleaner tree. The pass did not improve repeated tests, so I reverted it. One ugly run is not evidence about request order or render-blocking CSS.

An unscored warning is not a reason to rearrange a working critical path. My later tree was HTML, one small stylesheet, and two small module scripts. The stylesheet blocks first paint because stylesheets do that. The scripts did not.

The remaining bad run was real

After the canvas and image changes, I ran production Lighthouse three times.

Run	Score	Speed Index	Blocking time
1	100	1.13 s	25 ms
2	100	1.18 s	19 ms
3	68	3.02 s	1.36 s

A managed Cloudflare challenge script injected by the hosting layer spent 3.42 s on the main thread in that last run.

My static host does not expose a switch for that script. I cannot compress an AVIF until third-party main-thread work disappears. The outlier is still part of the experience for a visitor who receives it, but it needs a hosting-layer fix, not another image tweak.

A 68 is a bad score for a page that already looked finished. I stopped treating the integer score as the result. The frames, the trace, and the repeated runs tell me what changed. The badge does not.

Next time

I would open those frames first.

If the first screen looks done while Speed Index keeps climbing, I would look for a canvas, font swap, transition, or anything else that continues to repaint. Then I would pause decorative work until interaction and test again.

I would still do the boring file work. Responsive images, honest sizes, preload only the actual LCP asset, keep below-the-fold art lazy.

I would change one thing at a time and keep the failed runs. They are usually more useful than the screenshot with 100 in the corner.

Speed Index was not wrong. I thought I had asked when the page looked done. It was asking when the pixels stop changing.

Stop when the picture is done.

The browser used more CPU than the recorder

Deian — Tue, 01 Sep 2026 16:00:00 +0000

I sampled capkiku every second through a 65-minute call. 17% of one core, 85 MB of RAM, and Brave did the expensive work.

Meeting recorders have a reputation for cooking the laptop. Fans, battery, a guest in the call, something uploading in the background.

I don't run that. As an SEO agency owner (goBOFU), I need my device to stay lean. There’s tons of stuff constantly running, including multiple sessions of Grok and Codex.

Before building capkiku, I used Audio Highjack, only for it to completely bog down my Mac and make it almost crash, eating away 4GB of RAM. What for?

Anyway, now I just hit Record Audio in the menu bar and leave the recording running.

For my most recent session, a 65-minute call with my client, it recorded two tracks, the client in Brave (Google Meet) plus my Tula mic, on capkiku 1.0.19, an M3 MacBook Air with 16 GB, macOS 26, sampled every second.

The recorder sat at 17% of one core, median 17.5%. Almost every second of the hour lived between 15 and 20%. Brave as a whole, every helper process included, sat around 73% of one core and spiked past three.

If the laptop got warm, that was the meeting.

What 65 minutes wrote

The audio is 1 hour 5 minutes 42 seconds. The charts run closer to 67 minutes because that is the monitor window, from the files appearing to pressing the Stop button. Others came out at 67.5 MiB and my own track at 72.0 MiB, both AAC at 48 kHz stereo. A 64 KB Markdown file sits next to them with an on-device transcript.

That is about 2 MB per minute, written at 37 KB/s, in a straight line. It did not buffer the hour in RAM and dump it at the end.

The app capkiku started around 97 MB idle, sat near 85 MB while recording, and peaked at 111 MB. RAM did not climb as the files grew. Idle used 16 threads, recording used 21, then it dropped back.

CPU-time for the hour was 699 seconds, 540 user and 159 system, which integrates to 17.4% of one core.

My app doesn’t need an account, and it doesn’t upload the captures. The files landed in a folder I already use as a knowledge base, and I review them before I save. Only thing it doesn’t do is diarization.

Of course, there are some network requests for updates, and on macOS 26 the speech model can initiate a download.

Stop, then the transcript

I hit Stop, and Review Audio showed up in about 12 seconds. The capkiku process barely moved: a few 7–26% flickers, RAM from 110 MB to 137 MB, then idle.

12 seconds is what you need for the on-device model to transcribe 65 minutes times two files, and the menu bar app did not look busy.

So where did the work go?

I ran Apple's SpeechAnalyzer again on the same two .m4a files from a small CLI, and sampled localspeechrecognition.xpc. LocalCapture stayed at 0%, and the XPC sat at about 1.2 cores and 150 MB across two processes.

That is the transcribe tax, it is Apple's process, not a second copy of the recorder.

The CLI replay took 82 seconds, not 12, and the first file logged a speech-model download. Don't mix those clocks. Use 12 seconds for what I waited after the call. Use the XPC chart for who burned the CPU.

I also ran powermetrics with sudo on that replay. Apple says these watts are estimates, so don't compare your Mac with them. The sample covers the first ~60 seconds of the 82-second replay.

Before transcribe, ANE sat at 0 W and combined CPU+GPU+ANE around 3 W. During transcribe, ANE was about 1 W and peaked at 3.1 W. CPU was about 10 W and peaked at 15 W. Combined was about 11 W and peaked at 18 W. Thermal went from Nominal to Moderate for a bit; corespeechd did nothing useful in the samples.

What I could not measure

The processes coreaudiod, audiomxd, and usbaudiod are SIP-blocked, so 17.5% is the capkiku process. The system audio tap may cost more inside Core Audio, and I don't have that number.

I don't have watts for the live hour, only for the transcription replay. Apple Energy Impact on the XPC averaged about 887, which is a dimensionless score, not watts.

The encode is more than voice needs

The writer targets 192 kbps stereo at 48 kHz, and voice does not need that. The mic file came out at 151 kbps of stereo speech, so mono and a lower bitrate on my own track would cut CPU and disk, and the other track can drop too. I’m not sure yet it’s worth optimizing that far.

The good news is that the session didn’t leak memory.

The rule

If your Mac is loud on a call, look at the browser first. That’s usually the bottleneck. But if you use also an app for transcription that brings it to its knees, there’s a better solution.

A recorder like capkiku can sit at 17% of one core for an hour. It writes two files into a folder you own, then gets out of the way.

Boring is good. Boring means it gets the job done fast and efficiently. Also, as a user said to me yesterday, the design is great—so not boring!

capkiku is free, menu bar, macOS 14+, Apple Silicon. capkiku.com