5 ms·

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any gi

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.

wizzwizz4 2y ago
The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.
- IgorPartola 2y ago
  But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.
  - wizzwizz4 2y ago
    Your static and dynamic assets should be served from different domains anyway, to reduce the overhead of authentication headers / improve cache coherency. https://sstatic.net/ https://sstatic.net/ quotes a good explanation, apparently mirrored https://checkmyws.github.io/yslow-rules/ https://checkmyws.github.io/yslow-rules/. (The original Yahoo Best Practices for Speeding Up Your Web Site article has been taken down.)
    - mananaysiempre 2y ago
      Why does saving on cookies outweigh having to go through an additional TCP slow start?
      - wizzwizz4 2y ago
        Consider HTTP semantics. If there are cookies in the request, and those cookies change, it has to be re-requested every time. If there are no cookies, the request can remain semantically compatible, so the browser's internal caching proxy can just return the cached version. There are other advantages: the article elaborates.
        mananaysiempre 2y ago
        Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well. Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me. [1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary https://www.rfc-editor.org/rfc/rfc9110.html#name-vary [2] https://datatracker.ietf.org/doc/html/rfc6265#section-3 https://datatracker.ietf.org/doc/html/rfc6265#section-3
        wizzwizz4 2y ago
        Oh, would that anyone heeded the official HTTP semantics. (Web browsers barely let you make requests other than GET and POST! It's ridiculous.) On a fast internet connection, the answer doesn't matter because the internet connection is fast. On a slow internet connection, cacheable requests are better.
motorest 2y ago
> I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. That's a software architecture problem, not a transport layer problem.
- lukeschlather 2y ago
  Making the transport layer faster makes some architectures more performant. If you can simply swap out the transport layer that's a way easier optimization than rearchitecting an app that is correct but slow.
croes 2y ago
So with HTTP/3 it’s just 9.9 sec
kiwijamo 2y ago
Is HTTP the issue here though? Most of the time it seems to be more to do with the server taking ages to respond to queries. E.g. Facebook is equally poor on mobile as it is on my fibre-connected desktop (which I assume is using HTTP/3 as well) so I have my doubts that swapping HTTP versions will make a difference on mobile. I did find it amusing how the author of the linked article says the megacorps are obsessed with improving performance (including the use of HTTP/3 to apparently help improve performance). In my experience the worst performing apps are those from the megacorps! I use Microsoft apps regularly at work and the performance is woeful even on a fibre connection using a HTTP/3 capable browser and/or their very own apps on their very own OS.

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.

wizzwizz4 2y ago

The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.

IgorPartola 2y ago
But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.
- wizzwizz4 2y ago
  Your static and dynamic assets should be served from different domains anyway, to reduce the overhead of authentication headers / improve cache coherency. https://sstatic.net/ https://sstatic.net/ quotes a good explanation, apparently mirrored https://checkmyws.github.io/yslow-rules/ https://checkmyws.github.io/yslow-rules/. (The original Yahoo Best Practices for Speeding Up Your Web Site article has been taken down.)
  - mananaysiempre 2y ago
    Why does saving on cookies outweigh having to go through an additional TCP slow start?
    - wizzwizz4 2y ago
      Consider HTTP semantics. If there are cookies in the request, and those cookies change, it has to be re-requested every time. If there are no cookies, the request can remain semantically compatible, so the browser's internal caching proxy can just return the cached version. There are other advantages: the article elaborates.
      - mananaysiempre 2y ago
        Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well. Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me. [1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary https://www.rfc-editor.org/rfc/rfc9110.html#name-vary [2] https://datatracker.ietf.org/doc/html/rfc6265#section-3 https://datatracker.ietf.org/doc/html/rfc6265#section-3
        wizzwizz4 2y ago
        Oh, would that anyone heeded the official HTTP semantics. (Web browsers barely let you make requests other than GET and POST! It's ridiculous.) On a fast internet connection, the answer doesn't matter because the internet connection is fast. On a slow internet connection, cacheable requests are better.

motorest 2y ago

> I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. That's a software architecture problem, not a transport layer problem.

lukeschlather 2y ago
Making the transport layer faster makes some architectures more performant. If you can simply swap out the transport layer that's a way easier optimization than rearchitecting an app that is correct but slow.

croes 2y ago

So with HTTP/3 it’s just 9.9 sec

kiwijamo 2y ago

Is HTTP the issue here though? Most of the time it seems to be more to do with the server taking ages to respond to queries. E.g. Facebook is equally poor on mobile as it is on my fibre-connected desktop (which I assume is using HTTP/3 as well) so I have my doubts that swapping HTTP versions will make a difference on mobile. I did find it amusing how the author of the linked article says the megacorps are obsessed with improving performance (including the use of HTTP/3 to apparently help improve performance). In my experience the worst performing apps are those from the megacorps! I use Microsoft apps regularly at work and the performance is woeful even on a fibre connection using a HTTP/3 capable browser and/or their very own apps on their very own OS.