I created a simple test in HTML/JS, that loads a URL via AJAX. The server's reply is a hardcoded JSON string that is 10MB in size. The test loads the same URL in sequence, 100 times, for a total of 1000MB. On my phone, the test takes about 150 seconds, which means I can download at a rate of 6.67MB/sec. The round-trip time for each AJAX request is about 1000-1500 ms. However, when I use the Ookla internet speed test app, it reports 0.3mbps, or 0.0374MB/sec.

Am I thinking about this in the wrong way? The client is accessing a server-side script, so AFAIK it can't be cached (and the round-trip time makes me think it *is* transferring the entire JSON response every single time).

If your phone is connected to the same network as your "server" via for example wifi it will never use your internet connection (and thus speeds at 50-100Mbps is pretty normal).

It could also be a cache issue, even if it is a serverside script the browser can choose to use a cached copy of the data once it has recieved the headers.

To prevent browsers from caching your script generated data you can send these headers in the HTTP response:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Another option is to simply add something like '?v='+(new Date().getTime()) to your URL.

Thanks for your reply. I had turned off the phone's wifi when doing the tests (unless the iPhone overrides this when a known connection is available). I'll try the datetime variable in the URL, however, I would think the round-trip time (as measured in javascript) would be much lower if the browser cached the requests.

Thanks for your reply. I had turned off the phone's wifi when doing the tests (unless the iPhone overrides this when a known connection is available). I'll try the datetime variable in the URL, however, I would think the round-trip time (as measured in javascript) would be much lower if the browser cached the requests.

Thanks for your reply. I had turned off the phone's wifi when doing the tests (unless the iPhone overrides this when a known connection is available). I'll try the datetime variable in the URL, however, I would think the round-trip time (as measured in javascript) would be much lower if the browser cached the requests.

possibly, 3g/4g can have fairly insane latency and packet loss though.

possibly, 3g/4g can have fairly insane latency and packet loss though.

Agreed, so that's what I think I'm seeing... 1 to 1.5 seconds of round-trip latency on every request. If the browser is using a cached copy, I would expect to see much lower latency (0ms pretty much).

possibly, 3g/4g can have fairly insane latency and packet loss though.

Agreed, so that's what I think I'm seeing... 1 to 1.5 seconds of round-trip latency on every request. If the browser is using a cached copy, I would expect to see much lower latency (0ms pretty much).

The browser should send a request to the server and download the headers before deciding to use a cached copy though, (Allthough 1-1.5s is a very long time for that, even a shaky 3g connection should get that done in <500ms and you would probably get even worse results with the speed test app if your connection was that bad).

it could also be that your webserver is compressing the data. (Most modern browsers and webservers support http compression so if your json string has alot of repetition your server could be sending significantly less data)

Mobile phone networking is quite non-traditional. There are likely a number of mostly-transparent proxies, gateways, repeaters, and tunnels involved, compared to a normal hook-up straight to the internet. You'd have to do a lot more experimentation to get the specific shape of your connection under different circumstances.

Another option is to simply add something like '?v='+(new Date().getTime()) to your URL.

While that may get by a browser cache, the default behavior of most CDN accelerators is to ignore query parameters for the purposes of caching entities. This is because of how the cacheability of entities is written in the HTTP spec -- it doesn't take query parameters into account. There are proposals to change this in later versions of HTTP, and some CDNs allow you to include query parameters in the cacheability key, but it's by no means universal, and your user may be accessing the internet through some or proxy that hasn't been updated and maybe never will.

Proper cache headers is the best way of controlling cacheability of HTTP.