I tried to add a simple hit counter to my app and ended up learning why "simple" free APIs quietly fail on mobile

A developer building Daily Doodle, a static GitHub Pages app, found that a free public hit-counter API (countapi.mileshilliard.com) worked on desktop but silently failed on mobile because the domain was blocked at the network level by ad blockers, carrier filtering, or DNS blocklists. After a fetch-plus-image-pixel fallback also failed, the developer switched to Firebase Realtime Database, using its server-side atomic increment ('.sv': {'increment': 1}) to avoid race conditions, since firebaseio.com is rarely blocklisted.

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 https://fandom.com 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/ https://theplaidscientist.github.io/dailydoodle/ 💻 Code: https://github.com/theplaidscientist/dailydoodle https://github.com/theplaidscientist/dailydoodle Daily Doodle https://dev.to/plaidscientist/i-vibe-coded-my-first-app-ever 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 https://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; } ; Worked immediately on desktop. Yay It's working This is gonna be so cool. 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: js const pixel = new Image ; pixel.src = https://countapi.mileshilliard.com/api/v1/hit/${COUNTER KEY}? =${Date.now } ; 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. 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: // 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; } ; 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. 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. Have you had this problem? Did you solve it similarly or differently?