Assume terrible internet and then anyone with good internet is pleasantly surprised how not terrible your websites are.
Youre also opening up to more potential customers in rural areas or areas with poor reception, where internet may exist but may not be consistent or low latency
I had a frequent 1:30-hour train commute every couple of days to my previous role, and during that time, I learned how horrific our product was to use on a spotty connection.
Made me think more about poor & unstable connections when building out new features or updating existing things in the product. Easily parsable loading states, better user-facing alerts about requests timing out, moving calculations/compute client-side where it made sense, etc.
Just get on the road with a 3/4/5G connection on a mobile phone if you want to understand why we still need to design for "iffy" Internet. So many applications have a habit of hanging when the connection isn't formally closed but you're going through a spotty patch. Connections to cell towers with full bars and backhaul issues are surprisingly common. It's a real problem when you're dealing with streaming media (radio can be in the low kbps) or even WebSockets.
iffy internet and iffy devices, as what works with a good signal, can go haywire with a few settings not quite right.
I run exlclusivly from mobile internet, two phones, one is serving as the primary data conection for both and recently figured out that the way the wifi was configured was contributing to the signal dropping, but only in rural areas with a weak cell signal on busy towers, it took some experimenting to get things to work reliably.
But there are still a lot of places where the signal comes and goes, so useing a phone as a local only device is normal, or as a degraded device with perhaps just voice and text...perhaps not.
Notably, two products that work really great in bad internet are WhatsApp and the openAI API (ie. I can ask GPT4 some question, then have the internet cut out for a couple of minutes, and when a few more packets get delivered I have my answer there!)
My parents live just 40 miles outside Minneapolis and use a very unreliable T-Mobile hotspot because the DSL available to them still tops out at a couple megabit. Their internet drops constantly and for completely unknown reasons.
I've been trying to convince them to try Starlink, but they're unwilling to pay for the $500+ equipment costs.
I have one of those too. The connection dropping out is the real crux of the matter I think. If it's merely slow you can just wait longer, but an intermittent connection requires qualitatively different design.
Many people have already said designing for iffy internet helps everyone: this is true for slimming your payload, but not necessarily designing around dropped connections. On a plane or train, you might alternate between no internet and good internet, so you can just retry anything that failed when the connection is back, but a rural connection can be always spotty. And I think the calculus for devs isn't clearly positive when you have to design qualitatively new error handling pathways that many people will never use.
For example, cloning a git repo is non-resumable. Cloning a larger repo can be almost impossible since the probability the connection doesn't drop in the middle falls to zero. The sparse checkout feature has helped a lot here. Cargo also used to be very hard to use on rural internet until sparse registries.
I also live about 40 miles outside Minneapolis (SW). They should check if fiber is available. A few years ago the state apportioned a chunk of money to roll fiber out to rural communities and it's well underway at this time. I finally got hooked up a few months ago. We're in an unincorporated township, but it looks like the towns & villages got connected first.
One of my neighbors is apparently using Starlink since I see a Starlink router show up in my Wi-Fi scan.
Tbf, it’s $500 in equipment + $50-100 in recurring costs, which I’m sure is much higher than what they’re paying now. If they don’t feel they need internet they probably don’t want to pay significantly more for it.
> Terrestrial because—well, have you ever tried to use a satellite connection for anything real? Latency is awful, and the systems tend to go down in bad weather.
This isn’t true anymore. Starlink changed the whole game. It’s fast and low latency now, and almost everyone on any service that isn’t Starlink has switched en masse to Starlink because previous satellite internet services were so bad.
Yeah, I had to double-check the date when I read that. Cost aside, everything I've heard about Starlink puts them "on par" with cable. (IE, not exactly equivalent, but certainly in the same league.)
You're right most of the time. I have had a 99% "unnoticeable" experience with Starlink in rural Canada. I definitely still experienced rain fade during heavy rain storms and occasional clear-sky blips for 30s-2min or so. Vastly superior to anything else I've used for Internet access in remote areas for sure, but not perfect. I have also experienced longer-term (30 min or so) service degradations where the connection stayed up but the bandwidth dropped to ~10Mbit/1Mbit.
Most of the time no one would notice. For some applications it's definitely something that needs to get designed in.
That's very similar to my experience with Comcast in downtown Palo Alto in 2010. A 99% "unnoticeable" experience, and then a multi-day outage caused by a massive storm.
I still occasionally get blips on Comcast, mostly late at night when I'm one of the few who notices.
Yes. I select everything to work disconnected for long periods of time. I suspect we are in a temporary time of good connectivity. What we really have to look forward to is balkanisation, privacy threats from governments, geopolitical uncertainty and crazy people running our communications infra.
Seems sensible to take a small convenience hit now to mitigate those risks.
A good point. The author does briefly address the point of mobile internet but I think it deserves a lot more real estate in any analysis like this. A few more points worth adding:
- Depending on your product or use case, somewhere between a majority and a vast majority of your users will be using your product from a mobile device. Throughput and latency can be extremely high, but also highly variable over time. You might be able to squeeze 30Mbps and 200ms pings for one request and then face 2Mbps and 4000ms pings seconds later.
- WiFi generally sucks for most people. The fact that they have a 100Mbps/20Mbps terrestrial link doesn't mean squat if they're eking out 3Mbps with eye-watering packet loss because they're in their attic office. The vast majority of your users are using wireless links (WiFi or cell) and are not in any way hardlined to the internet.
I don't use an iPhone, but my wife does. She says that it will remove apps from the device that you haven't used in a while, and then automatically re-download when you try to run them. On our WiFi at home, that's fine, but if we are out and about it can take up to an hour to download a single app.
> but it would be even nicer if you could pin some apps to prevent their offloading even if you haven't used them in ages.
That change would make _viable_ for me at all, right now it's next to useless.
Currently iOS will offload apps that provide widgets (like Widgetsmith) even when I have multiple Widgetsmith widgets on my 1st and 2nd homescreens, I just never open the app (I don't need to, the widgets are all I use). One day the widgets will just be black and clicking on them does nothing. I have to search for Widgetsmith and then make the phone re-download it. So annoying.
Also annoying is you can get push notifications from offloaded apps. Tapping on the notification does _nothing_ no alert, no re-download, just nothing. Again, you have to connect the dots and redownload it yourself.
This "feature" is very badly implemented. If they just allowed me to pin things and added some better UX (and logic for the widget issue) it would be much better.
Yeah. We have a 112 app in Finland, for making emergency calls and relaying your location. Maybe it's been made at least partially unnecessary by phone network features, but anyway. It's one app I absolutely never ever use except when someday I'll be in an emergency and will want to use it and then it'll be offloaded.
I've also noticed that the marginal cost of larger storage on an iPhone is significantly higher than on Android (e.g. my phone was $220 with 256GB of storage; it's $100 per 128GB to upgrade the iPhone 16 storage), making people much more likely to be low on storage.
Last I checked the marginal cost of storage for Google, Samsung, and Apple phones sits around $600/TB. More for lower amounts, less for higher amounts.
I don't look much into phones that don't promise a reasonable support life, but if I go look at motorola all these midrange phones don't even have size options. At least some of them accept microsd.
Some low hanging fruit for reducing app package sizes that tends to be neglected is just going through your dependencies and dropping the ones you don’t need and replacing those with unreasonable file size.
I forget which it was but years ago there was a common customer service library that a lot of apps include that on its own added like 25MB to your app package size. That’s insane, I’ve built and shipped full apps that aren’t that large. Adding that library would’ve over doubled size for questionable utility.
It doesn’t take dropping too many dependencies like that to reduce package size significantly.
A big focus is (rightly) on rural areas, but mobile internet packet loss can also a big issue in cities or places where there are a lot of users. It's very frustrating to be technically online, but effectively offline. An example: Using Spotify on a subway works terribly until you go into Airplane mode, and then it suddenly works correctly with your offline music.
When Apple did their disastrous Apple Music transition, I was in the habit of daily recreation that involved driving in areas without mobile access.
All of a sudden one day, I was cut off from all my music, by the creators of the iPod!
I switched away from Apple Music and will never return. 15 years of extensive usage of iTunes, and now I will never trust Apple with my music needs again. I'm sure they don't care, or consider the move a good tradeoff for their user base, but it's the most user hostile thing I've ever experienced in two decades on Apple platforms.
The OP already had the music downloaded to his device. When apple switched to the streaming service they deleted all that… you still technically owned the music, but now it had to be streamed. I also don’t recall if they started with an offline feature.
Well my library was essentially destroyed by their actions. Albums that I own and ripped my damn self now have holes in them — all the wildly popular tracks on many of my albums are gone. The metadata still shows the track but it won’t play. The artwork I carefully curated was overwritten with unrelated junk albums, often $0.99 compilations that you might’ve found in a bargain bin 20 years ago. Even the data I created myself Apple felt zero issue with overwriting it themselves.
Mine just magically worked the whole time. In fact just last week I noticed I still had CD scratch artefacts in one of my tunes on Apple Music which I must have ripped 20-25 years ago (and went and redownloaded it from Apple instead).
The magic was that you had to have iTunes Match or manually sync. Years later, few people remember or are still shaking their fist and babbling over U2.
Apple didn’t communicate that well and many folks lost stuff, particularly if they are picky about recordings.
All of the CD collection stuff has degraded everywhere as the databases of tracks have been passed around to various overlords.
As someone who didn't have an iPhone during that switch (haven't since 2014), what happened to music that isn't in Apple Music? Streaming services are famously incomplete databases.
Otherwise, you sync with iTunes/Music.app or manage outside of Apple like we did from 2000 till whenever match came out.
My wife had an extensive collection of recordings that aren’t available on Apple Music and never will be, and they’ve flawlessly synced since Match came out like 20 years ago.
I think the complaints about album are 100% legit. But a lot of the lost data/miscategorized albums are likely more related to old farts like me forgetting that many of my “CD rips” may have fallen off the Napster truck 30 years ago.
Apple when it comes to purchased music has been pretty awesome to its customers. (Apple Music… meh) Buying songs has been a sideshow for what… a decade? Unlike many providers, it’s all still there humming away. Every person involved is long retired, it’s still alive.
It did have that at launch, but the transition was very confusing. There was (is?) an "iTunes Match" thing to replicate your personal mp3s in the cloud rather than uploading them. It was a real mess.
There was a random smattering of songs from my library on my device, but not according to anything I regularly listened to.
I couldn't be bothered to spend time manually selecting stuff to download back then. It was offensive to even ask that spend 30 minutes manually correcting a completely unnecessary mistake on their part. And this was during a really really bad time in interface, with the flat ui idiocy all the rage, and when people were abandoning all UI standards that gave any affordances at all.
If I'm going to go and correct Apple's mistake, I may as well switch to another vendor and do it. Which is what I did. I'm now on Spotify to this day, even though it has many of the problems as Appple Music. At least Spotify had fewer bugs at the time, and they hadn't deleted music off my device.
Good riddance and I'll never go back to Apple Music.
At least when I last tried the android version of the Apple Music app, when you're technically but not reliably connected to the Internet (captive portal, crappy signal quality, etc), operations like play/next track/previous track would hang for 60 seconds before the UI responded
There's a whole cottage industry of Android powered digital music players. They usually skimp on things like screen quality and compute power, but add things like microSD slots, physical transport controls, and high quality DAC & amp hardware. It's gotten very competitive in recent years.
I sometimes look at these and daydream about owning one, then I slap myself and just put music on my phone. My hearing is just not that great these days, I doubt I could hear the difference.
Where would one get these MP3 files? Not everything is on Bandcamp and torrenting everything feels like a part time job, but maybe I just have too much music I like.
I still remember spending days inside during summers as a kid, downloading, cataloging and tagging MP3 files while others were probably experiencing life haha.
But I do long for the days where I could just press 'play' and I would hear music, without waiting for Spotify's Electron crap to finish loading its 'optimistic UI', declining 10 cookie popups and agreeing to upload the soul of my unborn kids to Daniel Ek's private cloud.
> Where would one get these MP3 files? Not everything is on Bandcamp
A lot of music is still available for sale, if not through Bandcamp then through stores like Qobuz[1]. Sometimes I have to look around for a bit to find a store that sells what I'm looking for, but I can usually find it on Bandcamp or there. Occasionally it's not for sale, in which case I don't feel bad about torrenting or downloading from YouTube, but that's rare.
A USB CD reader costs $20-30 and will probably also read and write DVDs.
Software using libparanoia and lame or ffmpeg is free. The very first time you use it, you might spend 30 minutes figuring things out. It generally takes 3-8 minutes to rip and encode a full CD these days.
The market for CDs and used CDs is quite open. $10-15 for an album is quite common. For those not aware, an album is usually 8-20 songs, so roughly the same $0.99 price as for individual tracks -- but without DRM, and with physical backup.
An awful lot of artists have their own shops; frequently, if you buy the CD from there, you also get a digital copy in WAV, FLAC or MP3 immediately.
I make my music library available as a read-only NFS export in my house network, and remotely via various bits of software to members of my family.
The big digital music stores are DRM-free these days (iTunes and Amazon both are). There's also Qobuz if you want to avoid the tech giants (though most of your money ends up going to record labels, so does it really matter?).
I'm on fiber at home and my ISP did a backend update which is dropping packets specifically on IPv6 for some reason. Most sites are unusable and other software isn't handling it very well (e.g. android) with frequent "no internet" popups.
Speaking of Airplanes, I also frequently have issues with apps and websites when using in-flight wifi due to the high latency and packet loss. Incidentally, Spotify is one of said apps, which often means I need to manually set it to offline mode to get it to work.
Very good point. We had several power outages lasting a few hours lately. (One was just last night.) Every time this happens, my phone's mobile data is totally unusable because the whole neighborhood switches over from scrolling facebook (et all) on their wifi to scrolling facebook on mobile.
I can (and do) find things around the house that don't depend on a screen, but it's annoying to know that I don't really have much of a backup way to access the internet if the power is out for an extended period of time. (Short of plunking down for an inverter generator or UPS I suppose.)
If your ISP is available during a power outage (as they should be) a UPS that only powers a WiFi router could be quite small/cheap.
Or you could use a Raspberry Pi or similar and a USB WiFi adapter (make sure it supports AP mode) and a battery bank, for an "emergency" battery-operated WiFi router that you'd only use during power outages.
EDIT: Unless your ISP's CPE (modem/whatever) runs on 5 volts, you'd need more than just a USB power bank to keep things going. Maybe a cheap amazon boost converter could get you the extra voltage option.
FWIW the routers I have owned over the last few years have been 12V @ 1A.
I run my router + my RPi server off-grid with ~1kWh of usable (lead-acid) battery capacity.
So with those and my laptop's battery, I sailed into our last couple of minor daytime power cuts without even noticing. Sounds of commotion from neighbours alerted me that something was up!
Cable internet (HFC) might not work in power outages (depending on the network design) because often the optical nodes and amplifiers out in the streets are often not battery backed.
Cellular, FTTH and DSL do usually have battery backup though so should continue to work with a UPS.
It's deeply ironic how awfully designed the NYT games app is for offline use given many people use it on the subway. Some puzzles will cache, others won't. They only cache after you manually open them.
Also subways, and people with cheap data plans that get throttled after 1GB. Google maps regularly says "no results found" because the connection times out.
I’ve found Google Maps to be one of the worst offenders, often getting in a pickle when my phone is switching between 4G and 5G. What’s frustrating is that the state it gets in is irrecoverable: the only thing that works then is force-quitting, then reopening the app.
100% this, I am almost always on 5G or LTE but in some areas in my city it seems like not even a webpage will load on either. In this case, using any apps is useless and google/kagi search feels like it takes too long to find something basic.
This a million times. Spotify on the subway is infinitely frustrating until you go into airplane mode.
Ideally, apps shouldn't detect if you have internet and then act differently. They should pull up your cached/offline data immediately and then update/sync as attempted connections return results.
The model where you have offline data but you can't even see your playlists because it wants to update them first because it thinks you have internet is maddening.
Oh, one of the learned behaviors to compensate for stupid tech, along with e.g. obsessively copying a long comment lest the page decides to reload tO sHoW nEw cOnTenT while I'm typing.
(FB Lite "app" - as well as mobile FB site - are notorious offenders there)
I think around 2015, when "mobile-first" became super popular, in the rush to market people just forgot that a network is a network, and you have to actually handle broken connections. Which is ironic because mobile networks are where you really need to plan for all the usual network edge cases, unlike wired networks where the edge cases are far less common.
Spotify deals with degraded connections absolutely horrendously (on iOs anyway).
If I have a podcast already downloaded, but I am on an iffy connection, Spotify will block me from getting to that podcast view while it tries to load the podcast view from the web instead of using downloaded data.
I frequently put my phone in airplane mode to force spotify into offline mode to get content to play.
Yes, for the same reason we should design for low end HW: it makes everyone’s experience better. I wish websites and apps treated phoning home as a last resort.
Yes. Assume your users have a poor or metered connection. I don't want unnecessary things (like images) to load because it takes time, eats at my data quota and to be frank, I don't want people looking over my shoulder at media on my phone (especially when I have no idea what it is going to be). This is especially true for social media (and the reason I prefer HN over bluesky, reddit, etc.).
This gets down to a fundamental problem that crops up everywhere: How much is x willing to exponentially sacrifice to satisfy the long tail of y?
It's grounds for endless debate because it's inherently a fuzzy answer, and everyone has their own limits. However the outcome naturally becomes an amalgamation of everyone's response. So perhaps a post like this leads to a few more slim websites.
How much is x willing to exponentially sacrifice to satisfy the long tail of y?
Part of the problem is the acceptance of the term "long tail" as normal. It is not. It is a method of marginalizing people.
These are not numbers, these are people. Just because someone is on an older phone or a slower connection does not make them any less of a human being than someone on a new phone with the latest, fastest connection.
You either serve, or you don't. If your business model requires you to ignore 20% of potential customers because they're not on the latest tech, then your business model is broken and you shouldn't be in business.
The whole reason companies are allowed to incorporate is to give them certain legal and financial benefits in exchange for providing benefits (economic and other) to society. If your company can't hold up its end of the bargain, then please do go out of business.
There's obviously some trade-off here: should your business support fax machines? Work on a Nokia brick? These are clearly impractical. But slow internet connection speeds are a thing that everyone deals with, and therefore it makes sense for your software to be able to handle them.
> You either serve, or you don't. If your business model requires you to ignore 20% of potential customers because they're not on the latest tech, then your business model is broken and you shouldn't be in business.
Or, at least the business needs to recognize that their ending support for Y is literally cutting off potential customers, and affirmatively decide that's good for their business. Ask your company's sales team if they'd be willing to answer 10% of their inbound sales calls with "fuck off, customer" and hang up. I don't think any of them would! But these very same companies think nothing of ending support for 'old' phones or supporting only Chrome browser, or programming for a single OS platform, which is effectively doing the same thing: Telling potential customers to fuck off.
The vagueries of your post highlights the very problem I am addressing. What is an "older phone"? What is a "slower connection"? The bottom 20%? But the post at hand is talking about the bottom 3%, so where is the actual line? When you are in the hot chair, your hand in play, all those things need to be well defined lines.
If I squeeze you to be more precise, it becomes uncomfortable and untenable, as no matter what you are either marginalizing people or marginalizing yourself, your company, or everyone else. It's something where it is extremely easy to have moral high ground when you have zero stake yourself, but anyone who understands the nuance of the problem can see right through it.
This is an insane moral system that 99.9999% of the world does not share.
Approximately zero people are protesting because Gucci doesn't made a budget line of handbags that those below the poverty line can afford, or because car companies don't make cars that can be driven by quadriplegics, or because Google isn't making a version of Google Docs that operates through the post office mail for people without internet.
Every service, whether from the government or from a company, has some implicit requirements attached to it. Any sane person can see that. Statements like "Part of the problem is the acceptance of the term "long tail" as normal. It is not. It is a method of marginalizing people." indicate a level of detachment from reality, and the fact that you have to use emotionally manipulative phrases like "does not make them any less of a human being" to make your statements even seem halfway plausible conclusively prove this line of argument is on the level of randomly-generated nonsense in terms of logical coherence.
This is about high speed internet accessibility under normal circumstances. It seems like good analysis as far as it goes, but the bigger reason to design for iffy internet has to do with being able to rely on technology even after something bad happens to the internet.
Precisely! Like the person leaves their house. How is that not the obvious focal point. It's like they found great data on in the house internet and thought they'd skip the part that sadly many mobile app developers skip: most people don't stay at home and it's when they leave that unexpected outages crop up
Article skips consideration for shared wifi such as cafes where, IME, a lot of students do their work. Consumer wifi routers might have a cap of ~24 clients, and kind of rotate which clients they're serving, so not only is your 100Mbit link carved up, but you periodically get kicked off and have to renew your connection. I cringe when I see people trying to use slack or office365 in this environment.
A few years ago I was at a cafe in a venue that had a large conference/gathering, and their router was handing out 24 hour DHCP leases and ran out of IP addresses. It was a fairly technical group so me and a couple other people set up a table with RFC 2322-style pieces of paper with IP/gateway info ("please return when finished") and it worked surprisingly well!
> What if that person is on a slow link? If you've never had bad internet access, maybe think of this as plane wifi
Loads of people are on "a slow link" or iffy internet that would otherwise have a fast internet. Like... plane wifi! Or driving through less populated areas (or the UK outside of london) and have spotty phone reception.
This reminds me of a project I worked on for a grad school data science course here in Canada. We tried to map this "digital divide" using public data.
Turns out, it's really tough to do accurately. The main reason is that the public datasets are a mess. For example, the internet availability data is in neat hexagons, while the census demographic data is in weird, irregular shapes that don't line up. Trying to merge them is a nightmare and you lose a ton of detail.
So our main takeaway, rather than just being a pretty map, was that our public data is too broken to even see the problem clearly.
Really interesting perspective, thanks for sharing.
I think in so many fields the datasets are by far the highest impact thing someone can work on, even if it seems a bit mundane and boring. Basically every field I've worked in struggles for need of reliable, well maintained and open access data, and when they do get it, it usually sets off a massive amount of related work (Seen this happen in genetics, ML of course once we got ImageNet and also started getting social media text instead of just old newspaper corpuses).
That would definitely be advice I'd give to many people searching for a project in a field -- high quality data is the bedrock infrastructure for basically all projects in academic and corporate research, so if you provide the data, you will have a major impact, pretty much guaranteed.
Oddly fitting (or perhaps that's double irony) that your "mapping the digital divide" project was derailed by the literal digital mapping division boundaries.
I'm in the USA with nominally a 1.25 Gb/s down, 50 Mb/s connection from my cable ISP. And you'd think that it would be fast, low latency, and reliable. Well that would be true except my ISP is Xfinity (Comcast). At least 4 times per week, I experience frequent packet loss that works with older web servers but makes most newer TCP based technology just fail. And the connection will randomly fail for 10 minutes to 2 days at a time and sure they give me a credit for it.
So anyways, I bring this up with my local government in Chicago and they recommend that I switch to AT&T Fiber because it's listed as available at my address in the FCC's database. Well, I would love to do that except that
1. The FCC's database was wrong and rejected my corrections multiple times before AT&T finally ran fiber to my building this year (only 7 years after they claimed that it was available in the database despite refusing to connect to the building whenever we tried).
2. Now that it is in the building, their Fiber ISP service can't figure out that my address exists and has existing copper telephone lines run to it by AT&T themselves so their system cannot sell me the service. I've been arguing with them for 3 months on this and have even sent them pictures of their own demarc and the existing copper lines to my unit.
3. Even if they fixed the 1st issue, they coded my address as being on a different street than its mailing address and can't figure out how to sell me a consumer internet plan with this mismatch. They could sell me a business internet plan at 5x the price though.
And that's just my personal issues. And I haven't even touched on how not every cell phone is equally reliable, how the switch to 5G has made many cell phones less reliable compared to 3G and 4G networks, how some people live next to live event venues where they can have great mobile connections 70% of the time but the other 30% of the time it becomes borderline unusable, etc.
I have AT&T fiber 1Gb/s symmetric in the bay area. It is much better than the XFinity coax/cable from before. I still have random slow down and packet loss though. I suspect the shared fiber is oversubscribed one too many times.
It's an edge case, but I noticed that the first two sections focus on people's Internet access at home. But what about when on the move? Public Wi-Fi and hotspots both kinda suck. On those, there are some websites that work perfectly fine, and some that just... aren't usable at all.
The first computer I ever used had a 56k modem, but I can empathise with greybeard stories about watching text appear one character at a time from 300 baud modems because of the task-tracking software my employer uses. I load it up in a browser tab in the morning, and watch as the various tasks appear one at a time. It's an impediment to productivity.
The rule I've come up with is one user action, one request, one response. By 'one response', I mean one HTTP response containing DOM data; if that response triggers further requests for CSS, images, fonts, or whatever, that's fine, but all the modifications to the DOM need to be in that first request.
That's a good one, I recently witnessed a bulleted list being loaded one item/ajax request at a time... that was then awaited so that all of them had to load sequentially.
At one of my previous jobs, we designed a whole API to be slightly more contrived but requiring only one round-trip for all key data, to address the iffy internet connectivity most of our users had. The frontend also did a lot of background loading to hide the latency when scrolling.
It's really eye-opening to set up something like toxiproxy, configure bandwidth limitations, latency variability, and packet loss in it, and run your app, or your site, or your API endpoints over it. You notice all kinds of UI freezing, lack of placeholders, gratuitously large images, lack of / inadequate configuration of retries, etc.
Years ago API’s and apps that used them were expected to do some work offline and on slow networks. Then, suddenly, everyone was expected to have stable Internet to do anything. The reason, I think, is the few apps that expected to be always online seemed better to users and easier to architect. So most architectures went that way.
The reason is developers are worse. A decade or two ago, developers were nerds who loved tinkering with computers. Today tech is big money so everyone wants in. Most devs don't care, it's just a paycheck. Until someone starts setting expectations and holding people responsible for their trash code, we'll continue to see code monkeys write broken codebases. Not to mention where is the mentorship? I've worked as a mechanic, I've worked in construction, I've worked in a store. In all the above, I was mentored. Not for very long in the store but still, the other two have 2 year apprenticeship programs.
The i got a degree and a dev job, apprenticeship? Nah dude here's a big legacy app for you, have fun. Mentorship? Okay I technically had a mentor. We had a lunch every couple months, talked about stuff a bit but nothing much. And I mean this is going to sound a bit pompous but I'm above average. I had mostly A's in university, I finished every single project alone and then helped others. I was a TA. I corrected the professors when they made mistakes. I wrote a lot of code in my free time. I can't imagine what it must be like for one of my peers who honestly didn't know Jack shit and still graduated somehow.
I'm working on an app right now, took over after two other guys worked on it for about a year. This app isn't even in prod yet and it's already legacy code. Complete mess, everything takes like 5 seconds to load, the frontend does a crapload of processing because the data is stored and transferred in entirely the wrong structure so basically they just send all the data and sort it out on the frontend.
I honestly think the fastest way to get this app working properly is to scrap the whole thing and start from scratch but we have a deadline in a couple months so I guess I'll see how it goes.
> Then, suddenly, everyone was expected to have stable Internet to do anything.
I had reasonable - not mega - internet in Australia at the time. But the first 5 years of Steam sucked hard. Get home from work, go to play [game of choice] only to find it will take hours to update.
This reminded me of a feature request I dealt with at an employer, while working on backoffice software for a support team. The software loaded a list of all current customers on the main index page - this was fine in the early days, but as the company grew, it ended up taking nearly a whole minute before the page was responsive. This sucked.
So I was tasked with fixing the issue. Instead of loading the whole list, I established a paginated endpoint and a search endpoint. The page now loaded in less than a second, and searches of customer data loaded in a couple seconds. The users hated it.
Their previous way of handling the work was to just keep the index of all customers open in a browser tab all day, Ctrl+F the page for an instant result and open the link to the customer details in a new tab as needed. My upgrades made the index page load faster, but effectively made the users wait seconds every single time for a response that used to be instant at the cost of a one time per day long wait.
There's a few different lessons to take from this about intent and design, user feedback, etc. but the one that really applies here is that sometimes it's just more friendly to let the user have all the data they need and allow them to interact with it "offline".
There's no reason you can't have the cake and eat it too. If google can index the entire web and have search results and AI results for you in an instant, then you can give users instant customer search for a mid sized corp. A search bar that actually worked fast would have done the same as their Ctrl f workflow.
Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.
I would not consider Google search, nor its AI overview an example of a good system.
It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.
I didn't say it was good, I said it was fast. Those two things are often correlated though, the app described above certainly doesn't fit my definition of good.
Computers can do unfathomable amounts of computation in the blink of an eye. If your app takes seconds or longer to do stuff it's probably because it's ass. Nearly all common operations should be measured in nano or milliseconds. If they're slow it's probably the dev's fault.
As your career goes on, you will likely eventually work on large production systems that are not idealized greenfield deployments - at this time, you will have to come to terms with the constraints of Network and I/O bounds, and your dreams of nano and milliseconds will be shattered.
In particular, I welcome you to experience the lovely word of corporate VPNs, whose maintainers and developers seem to have latency expectations that have not changed in 30 years.
I'm currently working on one of those wonderful greenfield projects where the monkeys who put it together made these mistakes I describe and everything is slow. Website isn't even in production yet and everything takes 5+ seconds to load for no reason. Because they just store the data the way they got it which is shit, instead of shaping it into something sensible that allows efficient queries.
And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do.
I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing.
Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.
I'm not claiming to eliminate network transfer times. Sending a web request takes some time. But it doesn't take seconds, it takes anywhere from a few to a few hundred milliseconds, given that the request size is relatively small. If you're sending megabytes or gigabytes then obviously it takes longer.
So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc.
Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc.
We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work.
Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds.
I hope this gives you a better idea of what I'm saying.
I don't really know how else to lead you to understand that when you query a data source you do not have control over, through a network you do not have control over, you cannot make the interface work faster than the response from that data source. No matter how good your programming skills are, your endpoint cannot return data faster than it retrieves it.
I completely understand that. You just haven't mentioned it until now.
You could also look for inefficiencies in the search. Maybe the query is inefficient, maybe you can make use of database functionality such as full-text search and/or indexes etc.
If you don't have access to make those changes to the db, you can cache the data in your backend memory, your own DB, Redis or whatever you prefer, so your app can be nice and snappy regardless of how ass your dependency is.
VKontakte has a very clever but at the same time cursed solution to this — the `execute` API method. It takes JS-like code that runs server-side. You can make up to 25 API calls and transform the data any way you please before returning it to yourself, all for the cost of one network request. Working with every other API after that feels like a massive regression.
You also get a surprisingly large amount of pushback for refactorings like this, because a lot of professional developers have been taught to value code quality and API purity over such frivolities as actual user experience.
240 comments
[ 0.24 ms ] story [ 235 ms ] threadYoure also opening up to more potential customers in rural areas or areas with poor reception, where internet may exist but may not be consistent or low latency
Next que...<loading>
Made me think more about poor & unstable connections when building out new features or updating existing things in the product. Easily parsable loading states, better user-facing alerts about requests timing out, moving calculations/compute client-side where it made sense, etc.
Funny that American civil service is used by militaries on both sides. At least it was used in some role during the war, bot sure about now.
I've been trying to convince them to try Starlink, but they're unwilling to pay for the $500+ equipment costs.
Many people have already said designing for iffy internet helps everyone: this is true for slimming your payload, but not necessarily designing around dropped connections. On a plane or train, you might alternate between no internet and good internet, so you can just retry anything that failed when the connection is back, but a rural connection can be always spotty. And I think the calculus for devs isn't clearly positive when you have to design qualitatively new error handling pathways that many people will never use.
For example, cloning a git repo is non-resumable. Cloning a larger repo can be almost impossible since the probability the connection doesn't drop in the middle falls to zero. The sparse checkout feature has helped a lot here. Cargo also used to be very hard to use on rural internet until sparse registries.
One of my neighbors is apparently using Starlink since I see a Starlink router show up in my Wi-Fi scan.
Intelligent local echo. Did you type that char? How many times? Are you sure? Now you never have to guess..
UDP based means avoiding Path MTU problems.
Connection "roaming" and auto connect, etc.
Really, really cool. I wish mosh was everywhere :/
This isn’t true anymore. Starlink changed the whole game. It’s fast and low latency now, and almost everyone on any service that isn’t Starlink has switched en masse to Starlink because previous satellite internet services were so bad.
Most of the time no one would notice. For some applications it's definitely something that needs to get designed in.
I still occasionally get blips on Comcast, mostly late at night when I'm one of the few who notices.
Seems sensible to take a small convenience hit now to mitigate those risks.
- Depending on your product or use case, somewhere between a majority and a vast majority of your users will be using your product from a mobile device. Throughput and latency can be extremely high, but also highly variable over time. You might be able to squeeze 30Mbps and 200ms pings for one request and then face 2Mbps and 4000ms pings seconds later.
- WiFi generally sucks for most people. The fact that they have a 100Mbps/20Mbps terrestrial link doesn't mean squat if they're eking out 3Mbps with eye-watering packet loss because they're in their attic office. The vast majority of your users are using wireless links (WiFi or cell) and are not in any way hardlined to the internet.
It's a nice feature, but it would be even nicer if you could pin some apps to prevent their offloading even if you haven't used them in ages.
That change would make _viable_ for me at all, right now it's next to useless.
Currently iOS will offload apps that provide widgets (like Widgetsmith) even when I have multiple Widgetsmith widgets on my 1st and 2nd homescreens, I just never open the app (I don't need to, the widgets are all I use). One day the widgets will just be black and clicking on them does nothing. I have to search for Widgetsmith and then make the phone re-download it. So annoying.
Also annoying is you can get push notifications from offloaded apps. Tapping on the notification does _nothing_ no alert, no re-download, just nothing. Again, you have to connect the dots and redownload it yourself.
This "feature" is very badly implemented. If they just allowed me to pin things and added some better UX (and logic for the widget issue) it would be much better.
0: https://support.apple.com/guide/iphone/manage-storage-on-iph...
I don't look much into phones that don't promise a reasonable support life, but if I go look at motorola all these midrange phones don't even have size options. At least some of them accept microsd.
I forget which it was but years ago there was a common customer service library that a lot of apps include that on its own added like 25MB to your app package size. That’s insane, I’ve built and shipped full apps that aren’t that large. Adding that library would’ve over doubled size for questionable utility.
It doesn’t take dropping too many dependencies like that to reduce package size significantly.
All of a sudden one day, I was cut off from all my music, by the creators of the iPod!
I switched away from Apple Music and will never return. 15 years of extensive usage of iTunes, and now I will never trust Apple with my music needs again. I'm sure they don't care, or consider the move a good tradeoff for their user base, but it's the most user hostile thing I've ever experienced in two decades on Apple platforms.
Oh and all my lossless got shit on.
Fuck me I guess??
Apple didn’t communicate that well and many folks lost stuff, particularly if they are picky about recordings.
All of the CD collection stuff has degraded everywhere as the databases of tracks have been passed around to various overlords.
Otherwise, you sync with iTunes/Music.app or manage outside of Apple like we did from 2000 till whenever match came out.
My wife had an extensive collection of recordings that aren’t available on Apple Music and never will be, and they’ve flawlessly synced since Match came out like 20 years ago.
I think the complaints about album are 100% legit. But a lot of the lost data/miscategorized albums are likely more related to old farts like me forgetting that many of my “CD rips” may have fallen off the Napster truck 30 years ago.
Apple when it comes to purchased music has been pretty awesome to its customers. (Apple Music… meh) Buying songs has been a sideshow for what… a decade? Unlike many providers, it’s all still there humming away. Every person involved is long retired, it’s still alive.
I couldn't be bothered to spend time manually selecting stuff to download back then. It was offensive to even ask that spend 30 minutes manually correcting a completely unnecessary mistake on their part. And this was during a really really bad time in interface, with the flat ui idiocy all the rage, and when people were abandoning all UI standards that gave any affordances at all.
If I'm going to go and correct Apple's mistake, I may as well switch to another vendor and do it. Which is what I did. I'm now on Spotify to this day, even though it has many of the problems as Appple Music. At least Spotify had fewer bugs at the time, and they hadn't deleted music off my device.
Good riddance and I'll never go back to Apple Music.
Add music on macOS, and on your phone. Then sync.
RESULT: one overwrites the other, regardless of any settings.
You no longer have the audio you formerly owned.
It has nothing installed but VLC.
Life is too short to deal with the ridiculous interoperability of (simple music files) and (any modern computing platform).
> Life is too short to deal with (the ridiculous interoperability of simple music files) and (any modern computing platform).
I still remember spending days inside during summers as a kid, downloading, cataloging and tagging MP3 files while others were probably experiencing life haha.
But I do long for the days where I could just press 'play' and I would hear music, without waiting for Spotify's Electron crap to finish loading its 'optimistic UI', declining 10 cookie popups and agreeing to upload the soul of my unborn kids to Daniel Ek's private cloud.
A lot of music is still available for sale, if not through Bandcamp then through stores like Qobuz[1]. Sometimes I have to look around for a bit to find a store that sells what I'm looking for, but I can usually find it on Bandcamp or there. Occasionally it's not for sale, in which case I don't feel bad about torrenting or downloading from YouTube, but that's rare.
[1]: https://www.qobuz.com/shop
Software using libparanoia and lame or ffmpeg is free. The very first time you use it, you might spend 30 minutes figuring things out. It generally takes 3-8 minutes to rip and encode a full CD these days.
The market for CDs and used CDs is quite open. $10-15 for an album is quite common. For those not aware, an album is usually 8-20 songs, so roughly the same $0.99 price as for individual tracks -- but without DRM, and with physical backup.
An awful lot of artists have their own shops; frequently, if you buy the CD from there, you also get a digital copy in WAV, FLAC or MP3 immediately.
I make my music library available as a read-only NFS export in my house network, and remotely via various bits of software to members of my family.
iCloud: $1000 in Apple's pocket
I can (and do) find things around the house that don't depend on a screen, but it's annoying to know that I don't really have much of a backup way to access the internet if the power is out for an extended period of time. (Short of plunking down for an inverter generator or UPS I suppose.)
Or you could use a Raspberry Pi or similar and a USB WiFi adapter (make sure it supports AP mode) and a battery bank, for an "emergency" battery-operated WiFi router that you'd only use during power outages.
EDIT: Unless your ISP's CPE (modem/whatever) runs on 5 volts, you'd need more than just a USB power bank to keep things going. Maybe a cheap amazon boost converter could get you the extra voltage option.
I run my router + my RPi server off-grid with ~1kWh of usable (lead-acid) battery capacity.
So with those and my laptop's battery, I sailed into our last couple of minor daytime power cuts without even noticing. Sounds of commotion from neighbours alerted me that something was up!
Cellular, FTTH and DSL do usually have battery backup though so should continue to work with a UPS.
Ideally, apps shouldn't detect if you have internet and then act differently. They should pull up your cached/offline data immediately and then update/sync as attempted connections return results.
The model where you have offline data but you can't even see your playlists because it wants to update them first because it thinks you have internet is maddening.
Back button in my browser for a static page redownloads it and the accompanying however many MB of framework...
Now I open links in new tabs always.
(FB Lite "app" - as well as mobile FB site - are notorious offenders there)
If I have a podcast already downloaded, but I am on an iffy connection, Spotify will block me from getting to that podcast view while it tries to load the podcast view from the web instead of using downloaded data.
I frequently put my phone in airplane mode to force spotify into offline mode to get content to play.
It's grounds for endless debate because it's inherently a fuzzy answer, and everyone has their own limits. However the outcome naturally becomes an amalgamation of everyone's response. So perhaps a post like this leads to a few more slim websites.
Part of the problem is the acceptance of the term "long tail" as normal. It is not. It is a method of marginalizing people.
These are not numbers, these are people. Just because someone is on an older phone or a slower connection does not make them any less of a human being than someone on a new phone with the latest, fastest connection.
You either serve, or you don't. If your business model requires you to ignore 20% of potential customers because they're not on the latest tech, then your business model is broken and you shouldn't be in business.
The whole reason companies are allowed to incorporate is to give them certain legal and financial benefits in exchange for providing benefits (economic and other) to society. If your company can't hold up its end of the bargain, then please do go out of business.
Or, at least the business needs to recognize that their ending support for Y is literally cutting off potential customers, and affirmatively decide that's good for their business. Ask your company's sales team if they'd be willing to answer 10% of their inbound sales calls with "fuck off, customer" and hang up. I don't think any of them would! But these very same companies think nothing of ending support for 'old' phones or supporting only Chrome browser, or programming for a single OS platform, which is effectively doing the same thing: Telling potential customers to fuck off.
If I squeeze you to be more precise, it becomes uncomfortable and untenable, as no matter what you are either marginalizing people or marginalizing yourself, your company, or everyone else. It's something where it is extremely easy to have moral high ground when you have zero stake yourself, but anyone who understands the nuance of the problem can see right through it.
Approximately zero people are protesting because Gucci doesn't made a budget line of handbags that those below the poverty line can afford, or because car companies don't make cars that can be driven by quadriplegics, or because Google isn't making a version of Google Docs that operates through the post office mail for people without internet.
Every service, whether from the government or from a company, has some implicit requirements attached to it. Any sane person can see that. Statements like "Part of the problem is the acceptance of the term "long tail" as normal. It is not. It is a method of marginalizing people." indicate a level of detachment from reality, and the fact that you have to use emotionally manipulative phrases like "does not make them any less of a human being" to make your statements even seem halfway plausible conclusively prove this line of argument is on the level of randomly-generated nonsense in terms of logical coherence.
Grateful for the blog w/ nice data tho TY
Loads of people are on "a slow link" or iffy internet that would otherwise have a fast internet. Like... plane wifi! Or driving through less populated areas (or the UK outside of london) and have spotty phone reception.
Turns out, it's really tough to do accurately. The main reason is that the public datasets are a mess. For example, the internet availability data is in neat hexagons, while the census demographic data is in weird, irregular shapes that don't line up. Trying to merge them is a nightmare and you lose a ton of detail.
So our main takeaway, rather than just being a pretty map, was that our public data is too broken to even see the problem clearly.
I wrote up our experience here if anyone's curious: https://zeinh.ca/projects/mapping-digital-divide/
I think in so many fields the datasets are by far the highest impact thing someone can work on, even if it seems a bit mundane and boring. Basically every field I've worked in struggles for need of reliable, well maintained and open access data, and when they do get it, it usually sets off a massive amount of related work (Seen this happen in genetics, ML of course once we got ImageNet and also started getting social media text instead of just old newspaper corpuses).
That would definitely be advice I'd give to many people searching for a project in a field -- high quality data is the bedrock infrastructure for basically all projects in academic and corporate research, so if you provide the data, you will have a major impact, pretty much guaranteed.
https://medium.com/spin-vt/impact-of-unlicensed-fixed-wirele...
So anyways, I bring this up with my local government in Chicago and they recommend that I switch to AT&T Fiber because it's listed as available at my address in the FCC's database. Well, I would love to do that except that
1. The FCC's database was wrong and rejected my corrections multiple times before AT&T finally ran fiber to my building this year (only 7 years after they claimed that it was available in the database despite refusing to connect to the building whenever we tried).
2. Now that it is in the building, their Fiber ISP service can't figure out that my address exists and has existing copper telephone lines run to it by AT&T themselves so their system cannot sell me the service. I've been arguing with them for 3 months on this and have even sent them pictures of their own demarc and the existing copper lines to my unit.
3. Even if they fixed the 1st issue, they coded my address as being on a different street than its mailing address and can't figure out how to sell me a consumer internet plan with this mismatch. They could sell me a business internet plan at 5x the price though.
And that's just my personal issues. And I haven't even touched on how not every cell phone is equally reliable, how the switch to 5G has made many cell phones less reliable compared to 3G and 4G networks, how some people live next to live event venues where they can have great mobile connections 70% of the time but the other 30% of the time it becomes borderline unusable, etc.
The rule I've come up with is one user action, one request, one response. By 'one response', I mean one HTTP response containing DOM data; if that response triggers further requests for CSS, images, fonts, or whatever, that's fine, but all the modifications to the DOM need to be in that first request.
An amazing thing.
It's really eye-opening to set up something like toxiproxy, configure bandwidth limitations, latency variability, and packet loss in it, and run your app, or your site, or your API endpoints over it. You notice all kinds of UI freezing, lack of placeholders, gratuitously large images, lack of / inadequate configuration of retries, etc.
The i got a degree and a dev job, apprenticeship? Nah dude here's a big legacy app for you, have fun. Mentorship? Okay I technically had a mentor. We had a lunch every couple months, talked about stuff a bit but nothing much. And I mean this is going to sound a bit pompous but I'm above average. I had mostly A's in university, I finished every single project alone and then helped others. I was a TA. I corrected the professors when they made mistakes. I wrote a lot of code in my free time. I can't imagine what it must be like for one of my peers who honestly didn't know Jack shit and still graduated somehow.
I'm working on an app right now, took over after two other guys worked on it for about a year. This app isn't even in prod yet and it's already legacy code. Complete mess, everything takes like 5 seconds to load, the frontend does a crapload of processing because the data is stored and transferred in entirely the wrong structure so basically they just send all the data and sort it out on the frontend.
I honestly think the fastest way to get this app working properly is to scrap the whole thing and start from scratch but we have a deadline in a couple months so I guess I'll see how it goes.
I had reasonable - not mega - internet in Australia at the time. But the first 5 years of Steam sucked hard. Get home from work, go to play [game of choice] only to find it will take hours to update.
So I was tasked with fixing the issue. Instead of loading the whole list, I established a paginated endpoint and a search endpoint. The page now loaded in less than a second, and searches of customer data loaded in a couple seconds. The users hated it.
Their previous way of handling the work was to just keep the index of all customers open in a browser tab all day, Ctrl+F the page for an instant result and open the link to the customer details in a new tab as needed. My upgrades made the index page load faster, but effectively made the users wait seconds every single time for a response that used to be instant at the cost of a one time per day long wait.
There's a few different lessons to take from this about intent and design, user feedback, etc. but the one that really applies here is that sometimes it's just more friendly to let the user have all the data they need and allow them to interact with it "offline".
Of course if the system is a total mess then it might have been a lot of work, but what you describe is really more of a skill issue than a technical limitation.
It is an effective product, in so far as it generates revenue, but it is not an example I would use to describe a system that provides a good and useful experience to its end users - which was and generally is my goal when designing software.
Computers can do unfathomable amounts of computation in the blink of an eye. If your app takes seconds or longer to do stuff it's probably because it's ass. Nearly all common operations should be measured in nano or milliseconds. If they're slow it's probably the dev's fault.
In particular, I welcome you to experience the lovely word of corporate VPNs, whose maintainers and developers seem to have latency expectations that have not changed in 30 years.
And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do.
I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing.
Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.
So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc.
Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc.
We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work.
Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds.
I hope this gives you a better idea of what I'm saying.
You could also look for inefficiencies in the search. Maybe the query is inefficient, maybe you can make use of database functionality such as full-text search and/or indexes etc. If you don't have access to make those changes to the db, you can cache the data in your backend memory, your own DB, Redis or whatever you prefer, so your app can be nice and snappy regardless of how ass your dependency is.