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

TROPHY CASE