I'm building a web application for a small office, to run their daily business. The employees will be logged in and working in the system thorugh the whole day.

My client is located in Israel, and I'm shopping for a hosting cloud provider for him to host the application that I'll build

My options is a server in the US, in Europe, and a local one - in Israel. A local provider is far more expensive.

I need to estimsate how much will the location of the server influence the reponsiveness of the system. And need to do it before I actually order the hosting, install the application and can measure it directly.

Is it a problem at all? Is the latency for a server located over the Atlantic generally felt by users and uncomfortable? How about from one side of Europe to another? (3000 Kilometers by air, from Germany to Israel)

Are there common numbers (like: average ping time between these two countries, or geographical regions, is such and such)

Dani AI

Generated

Short version: location matters because physical distance drives latency, and latency dominates perceived responsiveness for interactive, multi-request apps. The most reliable step is what suggested — measure from the actual office network and from representative ISP paths rather than trusting broad averages. ’s use case (staff logged in all day, many interactive actions) makes RTT and round-trip counts the primary concern, not just raw bandwidth. (studylib.net)

Practical, test-first workflow you can do before committing to a host:

  1. Inventory the common user flows and count sequential round trips (use the browser Network waterfall).
  2. From the office run simple diagnostics: ping and traceroute to candidate IPs to inspect path and variability.
  3. Measure connection/TTFB with curl; example:
    curl -o /dev/null -s -w 'namelookup:%{time_namelookup} connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n' https://your-candidate-host/
  4. If possible spin a cheap trial VM in each candidate region (Israel, EU, US) and exercise real user flows during working hours; or run distributed probes/synthetic tests (RIPE Atlas or similar) to sample from Israeli vantage points. Those concrete numbers will tell you whether the extra local cost is justified. (linux.com)

How to get similar responsiveness without an expensive local box: serve static assets from a CDN, enable HTTP/2 or HTTP/3 (QUIC) and TLS 1.3 to reduce handshake and head‑of‑line costs, colocate app and DB, reuse connections and batch requests. Also check the provider’s peering and SLA — poor peering can erase geographic advantage. Note: 0‑RTT (TLS) and some aggressive optimizations have security or cache-consistency tradeoffs, so review those before enabling. (cloudflare.com)

Quick checklist to decide: measure RTT + TTFB + waterfall for representative flows; run a short trial in each region; confirm CDN + HTTP/3 + TLS 1.3 support; evaluate peering/SLA and support costs. For many small-office apps a European region + CDN is the pragmatic compromise; for the absolute snappiest interactive feel the local region wins, but only if cost and operations justify it.

I don't have exact numbers to
Isreal but you can try speedtest.net/pingtest.net and see if you can find a server there for reference numbers. Ping from West coast to East Coast of US is ~100ms, from East Coast to Europe is another ~100ms. I have a friend who lives in Kuwait and usually gets 150-200ms ping to Europe, 250-300ms ping to west coast of US.

In terms of comfort none of these numbers should be exceeding half a second which means a two-way trip should generally be at worst 0.75-0.85 seconds, under good conditions probably 0.4-0.5s, possibly less from EU. Add to that whatever processing time your server has. Imo a server on East Coast of US or in Europe would be fine.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.