DEV Community: Made Me The Dev

I launched my typing test on Product Hunt today — it has a Song mode for some reason

Made Me The Dev — Wed, 03 Jun 2026 08:46:38 +0000

I got annoyed by typing sites that don't work well on mobile, so I built my own. That was a few months ago. It's now a whole thing with 4 modes, badges, XP, and a rhythm game.

The rhythm game (Song mode) is the weird part — notes fall down 4 lanes and you press the matching key when they hit the zone. Started as a joke. Kept it because it's actually fun.

Also has a Daily Challenge where every player globally gets the same 10 sentences, computed client-side from a hash of the UTC date. No server, just math. Same prompts for everyone, every day.

Built it solo, pure HTML/CSS/JS, no frameworks. Lighthouse 100/100/100/100.

Just launched on Product Hunt today — if you want to check it out or throw an upvote:
https://www.producthunt.com/products/typevelocity?launch=typevelocity

Or play it directly:
https://typevelocity-nu.vercel.app

Honest feedback welcome too, good or bad.

I Broke My Own Typing Game and Git History Saved Me

Made Me The Dev — Sat, 30 May 2026 17:30:30 +0000

On May 13, 2026, seven images silently disappeared from TypeVelocity. Not with an error. Not with a warning. They just stopped being deployed — and the two blog posts referencing them served broken image slots to anyone who visited for 17 days straight.

I found out today, May 30. Not from monitoring. Not from an alert. Someone pointed it out while I was working on something else.

The deploy pipeline

TypeVelocity doesn't use git push to deploy. It uses a custom Node.js script that:

Minifies CSS and JS
Copies files to a results/ folder
Pushes only the files in a hardcoded FILES array to GitHub via the API
Vercel picks it up from there

The FILES list looks like this:

const FILES = [
    { local: 'results/index.html', remote: 'index.html' },
    { local: 'styles.min.css', remote: 'styles.min.css' },
    { local: 'script.min.js', remote: 'script.min.js' },
    { local: 'blogs/assets/some-image.png', remote: 'blogs/assets/some-image.png' },
    // ... 50+ more entries
];

Every file that goes live has to be in this list. It's maintained by hand. When you add a blog post or an image, you add it to the array. If you forget, the file doesn't deploy. The script doesn't warn you. It just skips it.

What happened

On May 13, I deployed the Daily Challenge update — a big feature, lots of new files. Somewhere in that deploy, seven image entries got dropped from the FILES list.

The images had been on the site since March:

4 Lighthouse before/after screenshots
3 UI comparison images

All seven were present in the April 18 deploy. Gone by May 13. The script ran fine. No errors. The images it skipped just quietly stopped being included.

The blogs referencing them — the Lighthouse 100 post and the lives and ranks update — kept loading fine. Text, styles, everything. Just empty <img> boxes where the screenshots should have been.

Nobody reported it. I didn't catch it in review. It was silently broken for 17 days.

Finding the exact commit

I needed to know when it broke. Git history has the answer.

# Check each commit between Mar 20 and May 26
for sha in 4aee7f5b c3da2958 4361a4f6 d4934aa1 9f0bef3a 027ed418 e594fa8d dc6a6e96
do
  has=$(gh api repos/mademethedev0/TypeVelocity/git/trees/${sha}?recursive=1 \
    | grep -c "typevelocity-100-on-lighthouse")
  echo "$sha: images=$has"
done

Output:

4aee7f5b: images=1  # Apr 18 — present
c3da2958: images=1  # Apr 18 — present
4361a4f6: images=0  # May 13 — GONE
d4934aa1: images=0  # May 17 — still gone
...

The images dropped in the May 13 commit. That's the Daily Challenge deploy.

Recovering from git blobs

The images were gone locally too — deleted at some point after the deploy dropped them. But git doesn't delete blobs when you push new commits. They're still there, just not referenced by any current tree.

Here's the recovery script:

const { spawn } = require('child_process');
const fs = require('fs');
const path = require('path');

const REPO = 'mademethedev0/TypeVelocity';
const SHA = '4aee7f5bed1ae9446195ff3b6843e571c6c7a36b'; // Apr 18 commit
const OUT = path.join(__dirname, 'blogs/assets');

const IMGS = [
    'typevelocity-100-on-lighthouse-desktop.png',
    'typevelocity-100-on-lighthouse-mobile.png',
    'typevelocity-before-any-optimization-on-lighthouse-desktop.png',
    'typevelocity-before-any-optimization-on-lighthouse-mobile.png',
    'typevelocity-update-new-ui-1.png',
    'typevelocity-update-new-ui-2.png',
    'typevelocity-update-new-ui-3.png',
];

function ghApi(endpoint) {
    return new Promise((resolve, reject) => {
        const proc = spawn('gh', ['api', `repos/${REPO}/${endpoint}`]);
        let out = '';
        proc.stdout.on('data', d => out += d);
        proc.on('close', code => {
            if (code !== 0) reject(new Error(`gh exit ${code}`));
            else { try { resolve(JSON.parse(out)); } catch { resolve(out); } }
        });
    });
}

async function main() {
    // Get full tree at that commit
    const tree = await ghApi(`git/trees/${SHA}?recursive=1`);
    const map = {};
    for (const node of tree.tree) {
        if (node.path.startsWith('blogs/assets/')) {
            map[path.basename(node.path)] = node.sha;
        }
    }

    for (const img of IMGS) {
        const blobSha = map[img];
        if (!blobSha) { console.log(`NOT FOUND: ${img}`); continue; }

        console.log(`Fetching ${img} (${blobSha})...`);
        const blob = await ghApi(`git/blobs/${blobSha}`);

        // Blob content is base64-encoded
        const buf = Buffer.from(blob.content.replace(/\n/g, ''), 'base64');
        fs.writeFileSync(path.join(OUT, img), buf);
        console.log(`  -> ${buf.length} bytes`);
    }
    console.log('Done.');
}

main().catch(e => { console.error(e); process.exit(1); });

Run it:

$ node recover-images.js
Fetching typevelocity-100-on-lighthouse-desktop.png (a91441b2)...
  -> 105956 bytes
Fetching typevelocity-100-on-lighthouse-mobile.png (724f2e40)...
  -> 97329 bytes
...
Done.

All seven images recovered in under 2 minutes. Redeployed. Live again.

What I'm doing about it

The real fix is automating the FILES list — scan results/ and blogs/assets/ at deploy time instead of maintaining it by hand. That's an afternoon of work I haven't done yet.

The short-term fix: I added a pre-deploy check that logs a warning for any file referenced in a blog post's src= attributes that isn't in the FILES list. Not automated, but it makes the gap visible instead of silent.

// Pre-deploy check (simplified)
const blogFiles = fs.readdirSync('blogs').filter(f => f.endsWith('.html'));
const missing = [];

for (const file of blogFiles) {
    const content = fs.readFileSync(`blogs/${file}`, 'utf8');
    const srcs = content.match(/src="([^"]+)"/g) || [];

    for (const src of srcs) {
        const path = src.match(/src="([^"]+)"/)[1];
        if (path.startsWith('assets/')) {
            const fullPath = `blogs/${path}`;
            const inList = FILES.some(f => f.remote === fullPath);
            if (!inList) missing.push(fullPath);
        }
    }
}

if (missing.length) {
    console.warn('Files referenced but not in deploy list:');
    missing.forEach(f => console.warn(`   - ${f}`));
}

The thing that actually bothers me isn't that it broke. Things break. It's that it broke quietly and stayed broken. A missing image doesn't throw an error anywhere in the pipeline. The build succeeds. The deploy succeeds. Everything looks fine until someone actually reads the blog.

That's the gap worth closing — not "prevent all breakage" but "make breakage loud."

What I should have done (and what it would cost)

Here's the prevention work I didn't do, with rough time estimates:

Fix	Prevents	Effort
Auto-scan `results/` and `blogs/assets/` at deploy time	Files missing from deploy list	2-3 hours
Validate all `src=` and `href=` references in HTML	Broken image/link references	1 hour
Add a post-deploy smoke test that checks image load status	Silent 404s on live site	1-2 hours
Log warnings for files in `results/` not in `FILES` array	Deploy list drift	30 minutes
Run Lighthouse CI on every deploy	Performance/accessibility regressions	1 hour setup

Total: 6-8 hours of prevention work to avoid 17 days of broken images and 2 hours of recovery scrambling.

The auto-scan is the big one. If the deploy script just walked results/ and blogs/assets/ and pushed everything it found, this entire incident wouldn't have happened. The manual FILES array exists because I wanted explicit control over what deploys — but that control isn't worth the maintenance burden.

The validation check is the quick win. 30 lines of code, runs in under a second, catches broken references before they go live.

The lesson

Solo projects break in ways that only get caught when someone's actually looking. I wasn't looking closely enough at those pages after the initial publish.

If you're maintaining a custom deploy pipeline:

Automate the file list — don't maintain it by hand
Validate references — check that every src= and href= points to something that exists
Make failures loud — silent skips are worse than errors

And if you ever accidentally nuke something from production: git history doesn't lie. The blobs are still there. You just have to go get them.

TypeVelocity is a typing test with lives, ranks, a rhythm game mode, and way too many features for something that started as a weekend project. It's live at typevelocity-nu.vercel.app. The images are back. The blogs work again. Go type something.

My typing game scored 41 on Lighthouse. Two days later it hit 100. Here's every fix.

Made Me The Dev — Wed, 11 Mar 2026 02:48:16 +0000

I built a typing test called TypeVelocity. Pure HTML, CSS, and JavaScript — no React, no Next.js, no framework. Just files and a build script.

I finally ran Lighthouse on it.

Mobile: 41 Performance. 83 Accessibility. 92 SEO.

Desktop was a 70 which sounds better until you realize passing is 90.

Two days of debugging later:

100/100/100/100. Both mobile and desktop.

Here's what was actually wrong and what fixed it.

CLS was 1.0 (yes, the maximum)

This single issue was responsible for most of the damage.

I load CSS asynchronously using the media="print" onload trick — the browser doesn't block rendering for the stylesheet. Critical styles are inlined in a <style> tag in the HTML head so the page looks correct on first paint.

Sounds smart. Except I forgot about the stuff that's supposed to be hidden.

I had two modal overlays, a cookie banner, an adblocker banner, and a tips popup in the DOM. All of them rely on CSS to stay invisible (opacity: 0, transform: translateY(100%), etc). That CSS lives in the async stylesheet. So between HTML parse and stylesheet load, every single one of these elements was fully visible for a split second.

Lighthouse saw them flash in and disappear. Cumulative Layout Shift: 1.0.

The fix was five lines of inline CSS:

.modal-overlay { position: fixed; inset: 0;
    opacity: 0; pointer-events: none }
.cookie-banner { position: fixed; bottom: 0;
    transform: translateY(100%) }
.adblock-banner { position: fixed; top: 0;
    transform: translateY(-100%) }

CLS dropped from 1.0 to 0.001. Performance went from 41 to 93 in one change.

If you're async-loading CSS and wondering why your CLS is terrible, check if you have any hidden elements that aren't hidden in your inline critical CSS. This was the dumbest bug I've ever shipped.

Accessibility: 83 → 100

A bunch of small things that added up:

user-scalable=no on the viewport. I had it to prevent zoom on the typing test. Turns out that's an accessibility fail — users with low vision need pinch-to-zoom. Removed it.

No <main> landmark. Screen readers use landmarks to navigate. I had a <header> and <footer> but nothing wrapping the actual page content. One tag.

Heading hierarchy. Jumped from <h1> to <h3>, skipping <h2>. Screen readers expect sequential order.

Missing aria-labels. The typing input was an invisible field overlaying the text display — no label, no role, screen readers had no idea what it was.

Contrast ratios. Cookie banner link was 2.17:1. Minimum is 4.5:1. Fixed the color.

Decorative SVGs. The logo, theme toggle icons — all missing aria-hidden="true". Screen readers were trying to announce them.

None of these were hard. I just hadn't tested with accessibility in mind.

The Google Fonts Problem

After the CLS fix, Performance was stuck at 93. FCP, LCP, and Speed Index were all around 2.6s on Lighthouse's simulated slow 4G.

I was loading JetBrains Mono and DM Sans from Google's CDN. 70KB of woff2 files, a CSS request, DNS lookups and TLS handshakes to two Google domains. Everything was async with font-display: optional — not render-blocking. But on a throttled 1.6 Mbps connection, 70KB of fonts competing for bandwidth with your actual content makes a difference.

I removed Google Fonts entirely.

--font-ui: 'DM Sans', system-ui, -apple-system, sans-serif;
--font-mono: 'JetBrains Mono', 'Fira Code', 'Consolas', monospace;

The fallback fonts were already in the stack. Without the Google Fonts <link>, the browser goes straight to system fonts. Zero external requests. The "3rd parties" section in Lighthouse disappeared completely.

Visual difference? Barely noticeable. System UI fonts are genuinely good now. Consolas vs JetBrains Mono is visible if you compare them side by side, but nobody's doing that on a typing test.

That got us from 93 to 100.

Non-composited animations (the boring one)

Lighthouse flagged 22 elements with non-composited CSS animations. Every result item in the modal had:

transition: background 0.35s ease, border-color 0.35s ease;

Two problems:

background shorthand transitions background-position sub-properties, which can't be GPU-composited. Changed to background-color everywhere.
border-color can't be composited at all. These transitions were on modal elements that are hidden 99% of the time — they only fire if you toggle dark/light mode while the results modal is open. Removed them.

This probably didn't move the score directly. But cleaning it up felt right.

Other fixes

Cookie banner as LCP. The cookie consent text was being detected as the Largest Contentful Paint because it was the biggest visible text on initial render. Deferred it with a 3.5s setTimeout. Now the actual page content is the LCP.

Footer content-visibility: auto. Tells the browser to skip rendering off-screen content until the user scrolls to it. Less work during initial paint.

contain: layout style paint on modal overlays. Tells the browser it can skip layout calculations for these elements when they're hidden.

Script defer. script.min.js loads with defer. Total Blocking Time: 0ms.

What was worth how many points

Rough breakdown based on testing each change:

Fix	Points gained	Effort
Inline hiding CSS for modals/banners	~50 on mobile	10 minutes
Remove AdSense script	~23 (Best Practices)	1 minute
Accessibility fixes (viewport, landmarks, aria, contrast)	83 → 100	1 hour
Remove Google Fonts	~7 Performance	5 minutes
background → background-color transitions	~1-2	30 minutes
Footer/modal containment hints	marginal	15 minutes

The CLS fix alone was worth more than everything else combined. If your score is low, find the big thing first. Don't start by optimizing CSS transitions when your modals are causing a full-page layout shift.

The honest part

Going from 41 to 93 took maybe three hours. Finding the CLS bug, adding inline CSS, fixing accessibility, deferring the cookie banner.

Going from 93 to 100 took the rest of two days. Auditing every CSS property in every transition. Removing custom fonts. Adding containment hints. Each optimization was worth a point, maybe two. Textbook diminishing returns.

Was it worth it? For the number, yes. For actual user experience, the jump from 41 to 93 was where all the real improvement happened. The 93-to-100 push was for my own sanity.

If you're building something and your Lighthouse score is rough — start with CLS. Check what's visible during that gap between HTML parse and CSS load. That's probably where your points went.

By the way — TypeVelocity is the typing test I built all of this for. It's free, works on your phone, no signup, no account, you just open it and type. Words mode, sentences mode, and a rhythm game mode if you want something different.

If you feel like trying it, cool. If not, that's fine too. Mostly I just wanted to share what I learned chasing that Lighthouse score because I couldn't find a single post that broke it down fix-by-fix with actual point values when I was stuck at 41.