4 ms·

I test all my web dev on the other side of a 4G modem connected to an MVNO. It forces you to be considerate of both bandwidth and latency as it's about 5-20Mbp

I test all my web dev on the other side of a 4G modem connected to an MVNO. It forces you to be considerate of both bandwidth and latency as it's about 5-20Mbps in the city with 120ms average latency. It's not at all impossible to design fast and responsive sites and single page applications under these constraints, you just have to be aware of them, and actively target it during the full course of development.

slt2021 2y ago
good for you, you are doing your job very well. part of the reason why modern software is so crappy, is because developers often have thee most powerful machines (MacBook pro like) and don't even realize how resource hungry and crrappy their software at lower end devices
- Escapado 2y ago
  Another part of the reason is that in every company I have ever worked for some SEO dude insists we need to add literally 10 different tracking scripts and insists they need to load first and consume megabytes of data. At my last gig the landing page was 190kb of HTML, CSS and JS from us, 800kb of images and literally 8mb in vendor scripts we were mandated to load as early as possible. Of course we fought it, of course nobody cared.
  - justmarc 2y ago
    Try an e-banking website which literally loads over 25MB of crap just to show the login page. This is by far the worst offender I've seen. Madness.
- huijzer 2y ago
  Yes MacBook pro with a glass fibre connection with a ping below 10 ms to the server. I’m usually on an old copper line (16 ms ping to Amsterdam) in the Netherlands (130 ms to San Francisco). Some sites are just consistently slow. Especially GitHub or cloud dashboards. My theory is that the round trip to the database slows things down.
  - FridgeSeal 2y ago
    GitHub and everything Atlassian deserve to be thrown in the pit-of-shame and laughed at for perpetuity. Jira is so agonisingly slow it’s a wonder anyone actually pays for it. Are the devs who work on it held against their will or something? It’s ludicrous. GitHub gets worse every day, with the worst sin being their cutesy little homegrown loading bar, which is literally never faster than simple reloading the page.
  - oefrha 2y ago
    These days people on HN love to advocate sockety frontend solutions like Phoenix LiveView, where every stateful interaction causes a roundtrip, including ones that don’t require any new data (or all required data can be sent in a batch at the beginning / milestones). It’s like they forgot the network exists and is uneven and think everything’s happening in-process. To ward off potential criticism: I know you can mix client-side updates with server-side updates in LiveView and co. I’ve tried. Maintaining client-side changes on a managed DOM, sort of like maintaining a long-lived topic branch that diverges from master, sucks.
eru 2y ago
In the Google office we had (perhaps they still have) a deliberately crappy wifi you can connect to with your device, to experience extra latency and latency spikes and random low bandwidth. All in the same of this kind of testing.
martyvis 2y ago
Many years ago I was called into troubleshoot the rollout of a new web based customer management application that was replacing a terminal green screen one. I was flummoxed finding all the developers had only ever tested their app running from workstations on 100Mbps switches where the target offices for this application were connected by 128kbps ISDN lines. I was able demonstrate how each 12kB of their application was going to take 1 second. (It was amazing to see their HTML still full of comments, long variable names, etc). I don't even think they had discovered gzip compression. This was after many millions of dollars had already been spent on the development project.

slt2021 2y ago

good for you, you are doing your job very well. part of the reason why modern software is so crappy, is because developers often have thee most powerful machines (MacBook pro like) and don't even realize how resource hungry and crrappy their software at lower end devices

Escapado 2y ago
Another part of the reason is that in every company I have ever worked for some SEO dude insists we need to add literally 10 different tracking scripts and insists they need to load first and consume megabytes of data. At my last gig the landing page was 190kb of HTML, CSS and JS from us, 800kb of images and literally 8mb in vendor scripts we were mandated to load as early as possible. Of course we fought it, of course nobody cared.
- justmarc 2y ago
  Try an e-banking website which literally loads over 25MB of crap just to show the login page. This is by far the worst offender I've seen. Madness.
huijzer 2y ago
Yes MacBook pro with a glass fibre connection with a ping below 10 ms to the server. I’m usually on an old copper line (16 ms ping to Amsterdam) in the Netherlands (130 ms to San Francisco). Some sites are just consistently slow. Especially GitHub or cloud dashboards. My theory is that the round trip to the database slows things down.
- FridgeSeal 2y ago
  GitHub and everything Atlassian deserve to be thrown in the pit-of-shame and laughed at for perpetuity. Jira is so agonisingly slow it’s a wonder anyone actually pays for it. Are the devs who work on it held against their will or something? It’s ludicrous. GitHub gets worse every day, with the worst sin being their cutesy little homegrown loading bar, which is literally never faster than simple reloading the page.
- oefrha 2y ago
  These days people on HN love to advocate sockety frontend solutions like Phoenix LiveView, where every stateful interaction causes a roundtrip, including ones that don’t require any new data (or all required data can be sent in a batch at the beginning / milestones). It’s like they forgot the network exists and is uneven and think everything’s happening in-process. To ward off potential criticism: I know you can mix client-side updates with server-side updates in LiveView and co. I’ve tried. Maintaining client-side changes on a managed DOM, sort of like maintaining a long-lived topic branch that diverges from master, sucks.

eru 2y ago

In the Google office we had (perhaps they still have) a deliberately crappy wifi you can connect to with your device, to experience extra latency and latency spikes and random low bandwidth. All in the same of this kind of testing.

martyvis 2y ago

Many years ago I was called into troubleshoot the rollout of a new web based customer management application that was replacing a terminal green screen one. I was flummoxed finding all the developers had only ever tested their app running from workstations on 100Mbps switches where the target offices for this application were connected by 128kbps ISDN lines. I was able demonstrate how each 12kB of their application was going to take 1 second. (It was amazing to see their HTML still full of comments, long variable names, etc). I don't even think they had discovered gzip compression. This was after many millions of dollars had already been spent on the development project.