ArneBab
@akiva @ij We do that now and then at work: Is this bearable.
I also clocked down bandwidth in the browser when I worked on my personal website (https://www.draketo.de).
Was quite surprised to find that embedding all structural images in CSS may be faster on a fast connection, but is actually slower on a slow connection, because the embedding only helps negate the TCP warmup time on fast connections, but slow connections have much less of them, so the base64-encoding overhead dominated there.
Santa Claes πΈπͺππ°π
Akiva
@clacke @ij @ArneBab Unfortunately, HTTP2 does a poor job of addressing WebSockets. We can never just have nice things because we keep screwing up the Web.
ArneBab
@clacke @ij @akiva Yes, partly :-)
(though itβs not the handshake but TCP slowstart, which is necessary to avoid oscillations in the load on intermediate routers that would cause lots of packet losses due to overload)
Santa Claes πΈπͺππ°π
Akiva
@ArneBab @clacke @ij This is a good approach for simple sanity checks on DOM and assets. You can also enable throttling at the kernel level, helping check things that are harder to gain metrics on, like sockets and streams. All those HTTP/TCP handshakes, etc. can be a killer, too.
ArneBab
@akiva @clacke @ij thatβs the next step, but itβs much more involved that this simple first step. And if all webdevs did it, weβd already have a much nicer web π
ArneBab
@clacke @ij @akiva I just decided to create a small screencast about this: https://www.youtube.com/watch?v=kbgJcwyA__Q How to test your website for slow connections in Firefox / Icecat
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.