앱에 간단한 히트 카운터를 추가하려고 했더니 모바일에서 “간단한” 무료 API가 조용히 실패하는 이유를 알게 되었습니다.

Social proof is good when you have a new app. I wanted people to know that others were using the app. I literally asked Claude for a 90s style website counter. I used the example of the famous burger sign that says, “billions served.”

Image source: The Flintstones Wiki on Fandom
side note- this movie was so magical when I was a little kid!

Turned out to be a good little rabbit hole, so I figured it was worth writing
up on its own — not just “here’s a counter,” but what actually broke along
the way and why.

🔗 See it in action: https://theplaidscientist.github.io/dailydoodle/
💻 Code: https://github.com/theplaidscientist/dailydoodle

Attempt 1: a free, no-signup counter API

Daily Doodle
is a static site on GitHub Pages — no backend, no server I control. So the
first move was a free public counter service
(countapi.mileshilliard.com) — no
account, no API key, just a GET request that increments a number tied to a
key I made up:

fetch(`https://countapi.mileshilliard.com/api/v1/hit/${COUNTER_KEY}`)
  .then(r => r.json())
  .then(data => { counterEl.textContent = data.value; });

Enter fullscreen mode Exit fullscreen mode

Worked immediately on desktop. Yay! It’s working! This is gonna be so cool.

Then it quietly stopped working on mobile

I switched to my phone before sending the link to my friend and realized it was still at triple —. No matter what I did, I couldn’t get the counter to update..

The counter would just… not move on mobile. No error the user would ever
see, because I’d deliberately built it to fail silently (dashes on screen
instead of a broken-looking blank) rather than break the actual app if the
counter service ever had a bad day.

First fix I tried: fire the request two ways at once — the normal fetch()
call, plus a fallback using an <img> tag pointed at the same endpoint,
since some ad blockers treat image requests differently than fetch/XHR calls:

const pixel = new Image();
pixel.src = `https://countapi.mileshilliard.com/api/v1/hit/${COUNTER_KEY}?_=${Date.now()}`;

Enter fullscreen mode Exit fullscreen mode

Didn’t help. Which was actually useful information — if both request types
fail identically, that’s not a request-type problem, that’s the whole
domain being blocked at the network level (an ad blocker, a mobile
carrier’s filtering, a DNS-level blocklist like NextDNS/AdGuard). Generic
counter/analytics-sounding domains get swept up in filter lists a lot more
than people realize.

Attempt 2: Firebase instead

The fix wasn’t cleverer code — it was picking a backend domain that’s
essentially never blocklisted, because too much of the internet depends on
it. Firebase fit: firebaseio.com is Google infrastructure that a huge
number of mainstream apps rely on, so blocklists generally leave it alone.

Setup, for anyone who wants to do this on their own static site:

1. Create a free project at Firebase Console (no credit card needed for the free Spark plan)
2. Add a Realtime Database, start it in test mode (public read/write — fine for something as low-stakes as a number)
3. Use Firebase’s REST API directly, no SDK, no auth needed in test mode:

// Read the current count
fetch(`${DB_URL}/counters/dailyDoodle.json`)
  .then(r => r.json())
  .then(value => { counterEl.textContent = value || 0; });

// Increment it atomically (safe even if two people spin at once)
fetch(`${DB_URL}/counters/dailyDoodle.json`, {
  method: 'PUT',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ '.sv': { 'increment': 1 } })
})
  .then(r => r.json())
  .then(value => { counterEl.textContent = value; });

Enter fullscreen mode Exit fullscreen mode

That .sv: { increment: 1 } bit is Firebase’s server-side increment — the
math happens on their server, not in the browser, so there’s no race
condition if two people hit spin at the same moment.

The honest tradeoff

Test mode means the database is publicly writable by anyone who finds the
URL — genuinely fine for a number nobody can really abuse in a meaningful
way, but worth knowing if you’re reusing this pattern for anything with
actual sensitive data.

Sources / further reading

• countapi.mileshilliard.com — the free counter service I started with
• Firebase Realtime Database REST API docs
• Firebase Console

Have you had this problem? Did you solve it similarly or differently?