This is an incomplete and quite superficial view of what is going on out there, in my opinion. I've worked on plenty of projects where the assumption was that since the round-trip to the server is going to take almost 100ms that'll dwarf anything that's going to happen on the server itself, justifying poor choices that lead to potentially adding a whopping 100ms onto that number. These numbers only get larger with a larger perceived "Nothing we can do about it" budget as well, programmers often feel justified in doing just about anything once round-trip time grows, not understanding that they're just adding to an already existing problem.

On top of that: Creating software that isn't outright wasteful in terms of performance isn't even hard, it's just a matter of not doing ridiculously dumb things. The problem I've observed in teams I've worked with is that the majority of programmers don't even know what the dumb things are, and wouldn't know how to even approach making something that's halfway fast.

Edit:

Unfortunately I think posts like these are only going to make the problem worse, because now people are going to ask for voodoo solutions to performance issues, when the answer to their problems was usually just "Maybe stop creating wasteful intermediate structures and just walk an array like a sane person" in 99% of cases. The first leg of any optimization journey in the average programmer's code will likely net tens or hundreds of times faster code, and that's actually all people were asking for.

The knowledge required to make those changes and understand them is fairly minimal, but the kinds of people who have to create spinners for webmail interfaces, have their application add 150ms on top of whatever round-trip you have for processing things counted in 5 digits, etc., have never bothered to even learn those things.

I have a new laptop with a rtx 5090. Opening any GL context takes more than half a second. There's tons of things that can be optimized and are pretty far from web.

Yes. Apple Music is the most egregious example of this. It could be ridiculously fast on your pocket supercomputer but the moment a web request gets fired off from stumbling blindly across the field-of-dung user interface, bam, you’re done. Especially if your network connection isn’t great at that time.

Things like this really pushed me to everything local systems. I’ll move actual files around if I want to do anything on the network. Or sometimes even use cables! Shock, horror!

I agree and see this as a side effect of a subtler thing. As people shall be replacable, software is designed and subtly mimics the organization's communication patterns. Features are cut up into the tiniest pieces with clear separation from the start (at least its claimed), and over time whatever change or feature seems overly complicated, won't be done or won't be done in a sane manner because its uneconomical.

You are starting to get software with ticket driven development layered around glue code for existing libraries. I see no problem with libraries, it is just the architecture and vertical understanding that leaves a lot of performance on the table, because refactoring insanity takes resources and a lot of talking, understanding and convincing to be done.

Doing this across big teams starts to have downsides. So one team doesn't have a particular use case implemented or understood it and does not want to support it and you run code to compensate for this.

Best example in a monolith case is oracle...

This is kind of a shallow assessment of "slowness". Slowness is a feeling, not a fact. Network is slow as a rule relative to other parts of the stack, but it is not usually what contributes to the feeling that your software is slow. It takes a good amount of incompetence and arrogance to cultivate that particular experience.

The UI threading model is usually not the problem.

The problem usually comes from inappropriately arranging the systems of record such that information needs to be communicated beyond the scope of one computer in order to satisfy a single logical request.

Moving information between physical processors tends to be significantly more expensive than local computation over that same information. JSON serialization is a really good example of this. You need a network with bandwidth in excess of 10 GbE to begin overtaking simdjson.

SSR or SPA doesn't really matter if the server still takes a minimum of 300ms to compose any kind of response due to how its database or other infrastructure is set up. Information theory doesn't care how clever your loading indicator is. If the information isn't available, we can't do anything meaningful. Stringing the user along with psychological tricks is a lot cheaper than hiring a skilled developer to do it the right way.

https://en.wikipedia.org/wiki/MIME

"In the Hypertext Transfer Protocol (HTTP) for the World Wide Web, servers insert a MIME header field at the beginning of any Web transmission. Clients use the content type header to select an appropriate viewer application for the type of data indicated."

A fan of "let's enable the program to do everything" philosophy I am not. This idea is embodied in the so-called "modern" web browser and a countless number of other "apps". Alas, this design, perhaps justified on "convenience" grounds (or so-called "user experience"), has been abused, e.g., for commercial purposes. One casualty of the abuse might be speed. Other sacrifices might be reliability, resource usage, "privacy", "security", etc. The most important sacrifice for me in using "do everything" software is _control_

Instead I use a number of small command line clients for making HTTP requests ("web requests").^1 I can edit the source code and compile these applications quickly with low resources

The clients are request makers, not response viewers. The historical "select an appropriate viewer application" step remains, as I prefer it

This software is not slow. I seem to avoid the dissatisfaction that I see from commenters who use software that can "do everything"

1. Generally this is one application that accepts URLs on stdin and generates HTTP on stdout and another that accepts HTTP on stdin, makes connections and sends it, typically a TCP client. But since I use a local forward proxy that has a built-in httpclient I don't necessarily need those programs to make requests, e.g.,

   x=https://danluu.com/perf-opt/
   echo "@1;expert-mode on;httpclient GET $x"|socat stdio unix:/path/socket 

To dogfood this, rent a VPS in Australia and put a test environment there. Should be about 200ms ping or a bit higher. How it runs for you is how Australian users are seeing your site, even if their last mile connection is fiber.

It's not very hard to engineer software with these two constraints at the same time:

* Must feel very responsive * Network requests can take up to 500ms end to end

This is why my most recent website does its server-side rendering on the client. I'm not even being that sarcastic. We stream a subset of the user's data (1 mb at most) in the background and have a WASM client that has the exact same server views. On SPA events, the WASM blob intercepts a lot of requests and can instantly render. Makes a laggy connection feel pretty quick.

In my experience the main driver of latency is not ping time, but how long the server takes to process the request.

It's particularly egregious to see the number of apps that will slow to a crawl even for things that works offline if the network is down or slow.

> If your software has the affordance of a waiting dialogue or loading wheel for many of its UI controls, you are building with this default blocked assumption. Even if you are building something web based, ask yourself if that's actually necessary for your software or if you could build it differently to avoid constant UI blocking.

I wish Atlassian listened to you.

UI blocking can make sense in some situations; otherwise things "happen" suddenly that are unexpected.

I'm making a simple plugin for Gimp that sends the active layer to a model with a prompt; on Macs by default the UI waits for the request to come back or timeout; on PCs it doesn't, so the modified layer appears unexpectedly. The Mac experience is better IMHO and I will replicate it in the PC version rather than the other way around.

Unfortunately, you either put all the commercially interesting bits on your own server and let your customers eat the latency, or you ship it to the edge and let piracy decimate your profits. I don't think there is any technical way out of this, and probably not any reasonable legal ways.

Can't they use ML to predict where I'm going to click, and pre-cache the predicted page whenever the predicted button doesn't mutate important state? Or skip the difficult ML and have some basic rule of thumb that pre-caches frequent button clicks, using a markov chain, and conditioned on those pages being low bandwidth to pre-load.

Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick.

Don’t know about that, pretty much everything is hosted on Cloudflare, Azure or S3 these days and all of them have at least one CDN on each continent.

This is true, but it is an entirely different problem in a different place to what the article is talking about.

The optimisations the article is talking about would help even with this problem if backends responded faster - although not as much as actually avoiding unnecessary network requests in the first place, of course.

One of my all-time favorite software quotes is, "The fastest request is no request at all."

After traveling around in places with very poor wifi/phone data speeds. I couldn't agree more with you.

I’ve been playing with this with software that needs to work with agents and also without internet at all (we’re serving construction projects that have limited access)

Obviously agent access goes away with internet failure but the state doesn’t need to… we use CRDTs and a virtual FS. There’s a toy-ish version of the harness at https://ourhearth.ai … if local first is interesting to you I’d love your feedback

There’s no reason for (most) software to just be hosted in the US anymore.

We as an industry should use AI to enable a standard of software quality that was previously uneconomical.

Shotout to PowerSync for enabling companies to go in the opposite direction and build offline-first apps. My company is a (production) customer, and we recommend it.

there is different scales at which software is slow. this os one and definitely a pain in the ass. everything being online for no good reason other than to harvest user data. which it really turns out to be every time. (for good or bad purpose).

second is on a smaller timescale. so many features and crap that is never asked for and never used is crammed into software so the systems that execute it are just juggling pretty much dead code in and stale data in their caches all days long.

Is the 300ms ping time why discord takes ~10-30 seconds to load?

Incredible that the top reply is a cop out.

Surely the biggest cause of slowness is doing more stuff.

We don't turn faster hardware into faster programs, we turn it into more program. AI isn't going to change that. We'll just get even more program because the optimisation has freed up space for that.

Unfortunately most of the time, the more program isn't for our benefit. I note that by far the heaviest program I use is my web browser. The one thing I don't get to choose what code gets thrust upon me.

[dead]