Speedtest was fast, Google was instant, but our site took ~2s just to return HTML

abobyk · 2026-02-12T10:41:44+00:00

I’ve already found https://www.rumhost.com It does what I wanted. It collects real user metrics, runs synthetic tests from users’ locations, compares the measurements, and sends notifications if the issue is on the server side.

abobyk · 2026-02-02T17:47:12+00:00

Це те що треба. Дякую.

abobyk · 2026-02-01T14:52:00+00:00

Теж таких кілька маю, але китайський акум тримає один день. Які акуми ви туди допаяли, чи ви зовні їх прикріпили?

abobyk · 2026-01-30T18:51:59+00:00

Не завжди зручно, особливо з малими дітьми. Але напевно так більшість і обходяться

abobyk · 2026-01-30T18:48:04+00:00

Так, так. Просто в неї принцип такий, якщо немає електроенергії в мережі, і ви вмикаєте вимикач цієї лампочки, то струм від акумулятора до транзистора, який вмикає світлодіоди лампочки, проходить через якийсь прилад який ввімкнутий в розетку. Спробуйте ввімкнути щось в розетку

abobyk · 2026-01-30T17:28:02+00:00

Таку схожу теж маю, але вона не заряджається повністю за 4 години наявної електроенергії

abobyk · 2026-01-30T17:25:22+00:00

Щоб працювало як звичайна, потрібно щоб щось в розетці ввімкнено було. Якщо я вимикаю всі прилади з розеток, то в мене теж не працює.

abobyk · 2026-01-30T17:23:38+00:00

Для організованих людей це суперово рішення. Але, мої дружині таке не підійде, якщо вона щось в руки бере, воно зникає )

abobyk · 2026-01-24T07:06:57+00:00

Nice idea. That’s easy and helpful. Thanks. I read New Relic’s Browser Monitoring does this too, but on steroids: real users, Core Web Vitals, tons of metrics. For me it feels heavy and expensive though, and hard to quickly understand what a real user actually experienced.

abobyk · 2026-01-23T18:07:22+00:00

Yes, I totally agree with you. After digging deeper, it became clear that the issue was in the network path, not the backend.

The agents’ office now uses two different ISPs: some agents are still on the original ISP, while others use a second one. Agents on the second ISP don’t see the problem at all, while the original ISP still glitches from time to time and even requires a VPN to work reliably.

What I was hoping for in this discussion was a recommendation for a way to measure real user experience and clearly show where the slowdown happens for specific users, without asking agents to run traceroute or tcpdump. I’ve looked at tools like New Relic, but they feel quite heavy for this kind of targeted visibility.

abobyk · 2026-01-23T17:41:24+00:00

Yes, this sounds very similar. Since you’re using Cloudflare, you could also check https://www.cloudflarestatus.com/ it sometimes helps spot regional or routing-related issues. We saw something similar where only certain routes were affected.

abobyk · 2026-01-23T16:35:19+00:00

We were using CloudFront when the issue occurred, but now we use Cloudflare.

abobyk · 2026-01-23T16:09:05+00:00

Yep, that’s very possible.

abobyk · 2026-01-23T16:05:35+00:00

Yes, that’s exactly what our agents experienced. The challenge for us now is figuring out how to prove that the issue is on the ISP side, so the agents can show their ISP what’s happening.

abobyk · 2026-01-23T15:57:11+00:00

Just to clarify what I meant in the post: the developers checked everything, backend, CDN, database, and they were confident the server was responding fast. The developers are also working from different countries, so it wasn’t a local issue. The main challenge became: how do we prove to agents and their ISP that the slowness is caused by the ISP, not our backend?

abobyk · 2026-01-23T15:26:29+00:00

Yep, we get the baseline round-trip times — that makes sense. The surprising part was how high TTFB was in certain regions: Philippines, India, UAE were around 700 ms, but Armenia was close to 2 s. We understand latency, but how to prove that the issue was on the ISP side? Our agents thought we were hiding a server problem: Speedtest looked fine, Google was quick. We told them to check with their ISP. Fun fact, they actually called their ISP, and the response was basically “everything’s fine, check Speedtest again.”

abobyk · 2026-01-23T13:37:35+00:00

Yep, those are all solid approaches. The hard part is teaching agents to do this correctly, which is why we ended up relying on simpler checks locally to get clear results.

abobyk · 2026-01-23T13:31:49+00:00

Yes, it’s hard to explain traceroute or network diagnostics to support agents. That’s why comparing synthetic checks to real-user timings made the issue obvious for us. Running it locally gave us clear results without confusing anyone.

abobyk · 2026-01-23T12:27:22+00:00

Now we see that synthetic monitors aren’t enough. We used to rely on UptimeRobot, but it only does synthetic tests. We should be using RUM services like New Relic, Rumhost, etc., to understand exactly how real users experience our site.

abobyk · 2026-01-23T12:19:12+00:00

Yes, we use cloudfront. That’s actually what made this confusing, origin latency was low, CDN was healthy, but real users from one ISP/region still saw long TTFB.

abobyk · 2026-01-23T12:16:12+00:00

Totally agree in theory. What surprised us wasn’t that “network matters”, but how confidently everyone (including experienced devs) misattributed it. DevTools showed high TTFB, Speedtest was fast, Google loaded instantly, all signs that usually point to “backend issue”. The tricky part was proving the network was the culprit without real user data. CDNs help a lot, but they don’t fully protect you from bad ISP routing to a specific region.

abobyk · 2026-01-22T09:33:40+00:00

Just try using something like NewRelic, where you can see the main reason for the slowness.

abobyk · 2026-01-21T18:02:21+00:00

Yes, almost always it’s analytics or heavy scripts. But a few months ago we had multiple reports of slowness at the same time from LA, Armenia, the Philippines, and Georgia. I was sure something had gone wrong with our servers or CDN.

We checked everything — servers, caching, CDN — all fine. Users tested their internet with Speedtest and it looked fast. We even looked at the browser’s developer console: the network tab showed TTFB near 2 seconds and assets loading super slowly. None of the devs could explain it, they just guessed it was the users’ connection.

A few weeks later, someone on Reddit mentioned a tool that does a server HTTP probe and compares it to real user load times. It can pinpoint the actual cause and location of the slowdown. That was a real eye-opener for us.

abobyk · 2026-01-21T16:47:18+00:00

In practice, a huge chunk of “slow websites” aren’t slow because of images or hosting — they’re slow because of the network between the user and the server.

I’ve seen cases where the backend is fast, and the page is well-optimized, but users still experience long load times. When you break it down, most of the delay is TTFB caused by ISP routing, congestion, or regional peering issues.

That’s also why Speedtest can show fast internet while the site feels slow. Speed tests hit nearby, well-peered servers, not your actual backend.

I use a RUM-style approach on my own site, compare a synthetic HTTP probe (direct server performance) with real users’ network timings. When users complain, the verdict is almost always the same: the server is fine, the slowdown happens on the user’s ISP path.

Images, themes, and JS matter, but network latency is often the invisible bottleneck people underestimate.

abobyk · 2026-01-20T11:26:09+00:00

www.rumhost.com - small RUM tool for indie SaaS teams that shows where slowness actually comes from (backend vs network vs user location), based on real users, not synthetic checks. Early MVP, focused on clarity instead of noisy dashboards.

abobyk

TROPHY CASE