The article doesn’t dig into the real meaty topic - why are modern websites slow. My guess would be 3rd party advertising as the primary culprit. I worked at an ad network for years and the number of js files embedded which then loaded other js files was insane. Sometimes you’d get bounced between 10-15 systems before your ad was loaded. And even then, it usually wasn’t optimized well and was a memory hog. I still notice that some mobile websites (e.g. cnn) crash when loading 3p ads.
On the contrary, sites like google/Facebook (and apps like Instagram or Snapchat) are incredibly well optimized as they stay within their own 1st party ad tech.
As someone working on improving we vitals metrics, ad networks are 100% the biggest issue we face. Endless redirects, enormous payloads, and non optimized images. And on top of all that, endless console logs. I wish ad providers had higher standards.
Do you know why modern sites are slow? Because time isn't invested in making them faster. It isn't a technical problem, people take shortcuts that affect the speed. They will continue to do so unless the website operators decide that it is unacceptable. If some news website decided that their page needed to load in 1s on a 256Mbps+10ms connection they would achieve that, with external ads and more. However they haven't decided that it is a priority, so they keep adding more junk to achieve other goals.
Might have to cut some features but the point is the same. Companies will build sites to the level of slowness that they think is tolerable. If their user's internet connection gets better that means that they can be less efficient and add more features.
Exactly this, and it's happening everywhere in the software world.
Why bother writing binary search? Linear search is fast enough. Why bother sharing pointers? Copy all the strings. Easy. Data compression? Forget it. Deleting files is totally irrelevant, etc, etc.
Here's another way of looking at it. As long as you're below a certain threshold, users would much rather you implement 5 new features than spend that time squeezing 100ms on the load time.
Another related side-reason why it's slow is we use higher and higher levels of abstraction, exactly to increase development velocity and be able to add more features quicker. I could write a native app in pure assembly and have it be blazing app, or I can write a webapp on top of web frameworks running in Electron, but in a fraction of the time. As long as my app is usable, I'll get all the user while the other person is still trying to finish their app.
You had me until the end. I still see significant lag and mismatches on Facebook's page from simple actions like pulling up my notifications or loading a comment from one of them. For the later, I see it grind its gears while it loads the entire FB group and then scrolls down a long list to get to the comment I want to see.
(This is on a Macbook Air from 2015, but these are really simple requests.)
I agree on the Ad Networks causing massive site bloat.
However, in terms of Facebook, I'd say it was well optimized considering its complexity prior to the recent redesign. But ever since the new design, my Macbook Pro can barely type on that site anymore. My machine has a 2.5 GHz Quad-Core Intel Core i7 and 16 GB of RAM.
That's pretty sad. Responsive design is a great idea, but in terms of how it is sometimes implemented you're getting X numbers of styles to load a page.
JS whitelisting and ad blocks anecdotally confirm this.
The number of sites that will be loading images and js from three or four or more different ad/tracking and CDNs is nuts, plus the various login and media links, and I feel zero guilt for not participating in this advertising insanity.
Tightly put together pages with only a handful of JS loads are damn near instant over gigabit fiber.
Cannot fully agree. I use adblockers since their invention. Twitter and reddit need more than 5 seconds to load for me on mobile wifi. Ads have their impact but it's not the sole problem.
I think the reason why web sites are as slow as they are is because they can be. Double the speed of the Internet and all computers and soon enough the content will expand to be just as slow as before.
I was on AT&T's website the other day (https://www.att.com/) because I am a customer and I was just astonished how blatantly they're abusing redirection and just the general speed of the page. (ie: Takes 5-10 seconds to load your "myATT" profile page on 250MB up/down).
It's 2020. This should not be that hard. I've worked at a bank and know that "customer data" is top priority but at what point does the buck stop? Just because you can, doesn't mean you should.
Not a surprise. Most people writing commercial front end code have absolutely no idea how to do their jobs without 300mb of framework code. That alone, able to write to the basic standards and understand simple data structures, qualifies my higher than average salary for a front end developer without having to do any real work at work.
There is also a big "runs-on-my-machine" factor. Where the machine is the developers high-tier laptop hooked up to Gigabit LAN and Fiber WAN with <5ms ping and >100Mbit symmetric.
Luckely there are tools like Lighthouse[0] but with all the abstractions and frameworks inbetween it is often impossible to introduce the required changes without messing up the quality or complexity of the code/deployment.
An uncompressed RGB 1920x1080 bitmap is 6,220,800 bytes. When your webpage is heavier than a straight-up, uncompressed bitmap of it would be... something's gone wrong.
We're not quite there, since web pages are generally more than one screen, but we're getting close. Motivated searchers could probably find a concrete example of such a page somewhere.
What’s funny is that’s how Opera Mini achieves its great compression for 2G and 3G network use... it renders mostly server-side, with link text and position offsets/sizes, last I used it...
No, you can not add the whole c++ std lib into our code. Yes, I know it is useful. Yes, that will save you 2 hours of work. However, the code no longer even fits into the 1MB of flash we have. Yes we can ask for a new design the management would love to spend 500k on spinning a new design and getting all of the paperwork for it done, and our customers would love replacing everything they have for functionally equivalent hardware that now costs 50 dollars more each. But at least you saved 2 hours writing some code.
I understand where you're coming from, and I appreciate the constraints of embedded system design, but this is a pretty extreme scenario.
Management should seriously consider whether the 0.01c saved on that 8Mb chip is worth the design overhead from very tight constraints. There is most likely a pin-compatible 16Mb chip that would eliminate all the pain.
Yes, I know that in high volumes every fraction of a penny counts. But if you frequently find yourself engineering your way out of trivial constraints, you might be doing it wrong.
My point was it was not a new thing. 8MB would have probably been well over 250 dollars worth of new parts at that time. Plus the re-cert and if you could fit it on the existing board. These days you would not be talking with a small amount even in the init design (hopefully).
No. It’s a tragedy of hiring bias. Interviewers, when conducting mass interviews to fill an open position, tend to prefer what they perceive to be is either the strongest technical candidate or the candidate who makes them feel the least insecure.
Then the candidate is selected and goes to work where the selection bias fades into expectations of conformity onto a bell curve. The people who conform to the middle of the curve are generally the ideal employees. The people at the low end of the curve are either released or retained as padding against future layoffs. The people at the high end of the bell curve are an anomaly. Those people are far more productive but are willing to use less popular conventions to achieve superior results which tends to result in friction.
This could be part of it. The shift to mobile computers which are necessarily wireless which means a random round trip time due to physics, which means TCP back-off. That, combined with the tendency to require innumberable external JS/CDN/etc resources that require setting up new TCP connections work together to make mobile computers extra slow at loading webpages.
Bandwidth and latency aren't the same thing! High-latency networks sometimes don't ever load some websites, even if there is reasonable bandwidth. I remember one time when I was in Greenland having to VNC to a computer in the US to do something on some internal HR website that just wouldn't load with the satellite latency.
The last 5 years there has been a dramatic shift away from HTML web pages to javascript web applications on sites that have absolutely no need to be an application. They are the cause of increased load times. And of them, there's a growing proportion of URLs that simply never load at all unless you execute javascript.
This makes them large in MB but that's not the true cause of the problem. The true cause is all the external calls for loading JS from other sites and then the time to attempt to execute that and build the actual webpage.
If left unoptimized, JavaScript can delay your pages when they try to load in users’ browsers. When a browser tries to display a webpage, it has to stop and fully load any JavaScript files it encounters first.
Yes. And while I will continue to defend it in case of interactive dashboards, webapps and status screens if you are not writing on of those, you shouldn't be using javascript. If we want to fix the internet, browsers should ask the user for permission for each cookie and javascript should be disabled by default.
Yeah, it is perfectly possible to build javascript heavy websites without making them unusable until all is downloaded and processed...
I'm rebuilding a site for a client and using a bunch of dynamic imports, if you don't touch a video route, you'll not download the videojs bundle at all, I set a performance baseline for the site to be interactive and anything that makes it go over the baseline needs a good reason to be there.
I really don't think this is an optimal solution. This makes every page load slowly, instead of just the first page. Waiting to do work doesn't make the work any quicker.
Not really, most of the bundles are pretty small, in the 30/40Kb range gzipped, even smaller with brotli, the problem is when the user has to wait 5s to start using the site, waiting half a second to load the first page is ok, waiting a quarter second to open other page is also ok.
It isn't purely about speed, it is about perception, a very slow first page load is way more annoying that a couple half or quarter second loads distributed over a long interaction, after the js is cached all is nearly instantaneous, but you don't have to wait a while to start using the site in your first visit.
If you want you can also wait for the first page to download completely and them import the remaining js while the user is on the first page, but I didn't tried to see how well it works.
It depends on the use case. For something like a web storefront, this is probably true. For a web application where I spend a long time doing work, I'd rather have a bit of a wait upfront followed by snappy responses on all the other pages. Even a half-second load time can be frustrating when I'm in the middle of a task.
Most SPA frameworks work fine with the back button and bookmarks--they'll either use the URL fragment (#) or the history API. I'm sure there are lots of developers who don't bother to turn on that functionality, but that's not an inherent flaw with SPAs.
(For the record, I don't think that every app that is an SPA should be, but I do think that they have a place.)
> The last 5 years there has been a dramatic shift away from HTML web pages to javascript web applications on sites that have absolutely no need to be an application.
SPAs are a lot easier to keep secure though, so if you don't want your private data leaked then they're a much better option.
There's a very clear separation between the front end and the back end, which makes it easy to write tests that allow-list only the specific data that's supposed to be getting returned.
Any and all scripts that are loaded at any point in the SPA stay for the duration of the visit. 3rd party scripts are a big risk and not being able to unload JS scripts and associated in-mem/in-page symbols etc. is a timebomb waiting to explode.
Try to open 10 actual html websites. Now try to open 10 SPA. Tell me which feels slower. SPA slowness is not exclusively from all the third party JS and CSS loads. A lot of it is just innate to being an application instead of a document.
Assuming there are repeat visitors. Someone sent you a link to an article. You don't care which website the article is on, you just want to read it and close it without exploring whatever else the website had to offer. So you download a several-megabyte JS bundle to be able to read several kilobytes worth of text. By the time you encounter another link to that particular website, your cache of its assets would be long gone.
Not necessarily true. I've seen many SPA apps where the API calls that get made when you navigate between pages are slow too. So subsequent pages are slow also in addition to the first page.
This isn't even a hard technical constraint. With async javascript "module" loading, and stuff like the new federated webpack stuff, you can have a lot functionality loaded in on-demand.
That won't always work out or be necessary though.. For an app like Lucidchart or something, I can deal with DL'ing updates every now and then. I spend most of the time in the running app.
In theory. In practice most SPAs are slow at first load and slow when changing pages then crash when too much data is requested.
Beyond that, unless your users are a captive audience (have to use your software for their job) you should probably be optimizing for a positive first impression.
The last two years have had a dramatic shift away from SPA and toward JAMstack, which is more or less pre-rendered SPA. The result is not only faster than SPA, but faster than the 2008-2016 status quo of server-scripted Wordpress and Drupal sites.
I blew off JAMstack as another dumb catchphrase (well, it is a dumb catchphrase), but then inherited a Gatsby site this past spring. It absolutely knocked my socks off. The future is bright.
From what I can see JAMstack is just model (api) view (markup) controller (java-script) for web browsers. But it needs a new name because MVC is lame. While PSA treated the browser as a thick client with a very slow disk accessed over the network. And static HTML treats it as a thin client (like X-windows).
There hasn't been a new idea in computing since the 70s. The only thing we've done is mutate a square peg into a round one and back again. Each time patting ourselves on the back for the sheer brilliance of the move.
I've been spending close to a day trying to figure out how to respond to this statement. It's like you're saying, "From what I can see, the 2020 Volkswagen Golf is just another flightless bird, but it needs a new name because calling it a duck doesn't sound fancy."
It's not a design pattern, and the element of it that uses one (React) usually implements Flux, not MVC.
As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.
>I've been spending close to a day trying to figure out how to respond to this statement. It's like you're saying [...]
No, it's like I'm saying: Software development is fad driven and shallow. The details change but those details are unimportant and ultimately pointless. Bad metaphors are exactly the type of shallow thinking I'm talking about.
A GUI is not a car, a duck, or a fish. It is a UI. That the web is being used as an interactive GUI is a travesty. Without knowing the history of why it was invented in the first place - extremely high latency and low bandwidth of the 90s internet - you will never understand why mutating it to a full GUI is a terrible idea. And why we should have used any of the dozen well engineered technologies that are not hypertext based but work with the internet (low latency high bandwidth) we have today.
It's gotten to the point where an X server in an Amazon data center and a VNC client on a phone is more responsive than facebook, twitter and reddit on mobile.
>As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.
Yes, using TeX would be an infinite improvement over the mess we have today. Imagine having one language for everything in a site, instead of the three (five? with markdown and js frameworks) you need today.
I've recently started using a Firefox extension called uMatrix and all I can say is, install that and start using your normal web pages and you'll very quickly see exactly why web pages take so long to load. The number and size of external assets that get loaded on many websites is literally insane.
I've been using uMatrix for ages and it was baffling to me how some websites that are literally just nice looking blogs have an unreal number (i.e. 500+) of external dependencies.
I love uMatrix but it can be a serious hassle to get an embedded video to play sometimes. Sometimes I'll allow scripts from the embedding site and suddenly there are dozens or hundreds of new dependencies popping up and not my video. At this point I really have to ask myself if it is worth it. Maybe if I'm lucky its a YouTube video and I can track it down on YouTube's site, but if not it's going to be a big headache and a lot of reloads before the stupid thing plays.
I just got in the habit of turning it off, when I'm either too lazy to bother, or I'm on a site I'll probably never visit again. sites that are already setup ofc generally stay that way.
The big headache is when you have a site half-setup -- its correct for all of your usage, and then you try something new and you get a video that doesn't load, and you sit there waiting until you realize umatrix probably found something new
Same problem here (not using uMatrix but something similar being NoScript) => I'm now constantly using 2 browsers, Firefox with NoScript as a base, then temporarily switching to Chrome to access the sites which are demanding in terms of dependencies as you described.
It's easy to convince atechnical people to adopt uMatrix when you show them that they can watch shows without ads and load pages in less than a second.
It's the cascade of doom... we have an internal benchmark without ads, and it's funny to see without ads we load something like 6Mb of JS but if you load the ads, the analytics cascade of hell will load 350Mb of JS to display one picture.
6MB of JS without ads is unfortunately on the small side these days. Worked for a company that had 15MB of JS, after minification and compression (mostly giant JS libraries that we on the dev team used one small feature of).
I think this is a general problem with technology as a whole.
Remember when channel changes on TVs were instantaneous? Somehow along the way the cable/TV companies introduced latency in the channel changes and people just accepted it as the new normal.
Phones and computers were at one point very fast to respond; but now we tolerate odd latencies at some points. Apps for your phone have gotten much much bigger and more bloated. Ever noticed how long it takes to kill an app and restart it? Ever notice how much more often you have to do that, even on a 5-month old flagship phone? It's not just web pages, it's everything. The rampant consumption of resources (memory, CPU, bandwidth, whatever) has outpaced the provisioning of new resources. I think it might just be the nature of progress, but I hate it.
It seems to me that we have lower performance, exponentially higher resource consumption, and often no more functionality in a “modern” web app / Electron app compared to some desktop apps from the 90’s. And for what? To have even worse UI’s and UX’s that never conform to platform guidelines? Where’s the progress?
The big "dream" of web-based technologies was to allow designers the freedom to do whatever they want. But doing this has a lot of costs, which we are all paying today. In the early days of GUIs, a group would design the OS, and everyone would just use that design through the UI guidelines. It was, in my opinion, the apex of GUI programming, because you could create full featured apps without the need of an experienced designer, at least for the first few iterations. Now, I cannot even create a simple web app that doesn't look crap, and any kind of web product requires a designer to at least make it minimally usable. And the whole architecture became so complex because of the additional layers, that it looks more like a Baroque church than a modern building.
The desktop apps from the 90s were better because they could actually show more information on a 600 by 800 pixel screen than a modern app can do on a full HD screen, because it puts too much whitespace.
Not to mention flat design, which is without exception bad design. Buttons have borders, show them.
I remember thinking this when OS's started butting transparent blur effects on various UI layers. As someone who's worked with computer graphics, I understood that high quality blur effects are relatively expensive. Most computers these days can handle it without breaking a sweat, but It's like why are we using these resources on the desktop environment, who's job is basically to fade into the background and facilitate other tasks?
I don't think it's the nature of progress so much as it is laziness. Most developers (myself included) don't worry much about optimization until the UX performance is unacceptable.
I sometimes wonder what the world could be like if we just froze hardware for 5 years and put all of our focus on performance optimization.
I think it was to do with graphics acceleration becoming more commonplace. It was my guess that these additional effects weren’t originally intended to use desktop cpu .. tho I guess once they became the norm who knows .. although the recent trend towards “flat” UI seems to be reversing that trend ..
I invented the translucent blurred window effect. It first shipped in Mac IE 5.0 in April 2000 (the non-Carbon version only), for the autocomplete window, and later that year for the web page context menu (first in the special MacHack version).
The effect doesn't have to be expensive, and my original implementation was fast on millenium era machines.
The goal is preserve the context of the background, while keeping foreground data readable, in a way that is natural to our human visual system. If you are doing it properly you also shift the brightness values into a more limited range to diminish the contrast and keep the tonal values away from the chosen foreground text color (this is also cheap). Done properly it is visually pleasing with virtually no effect on readability.
People have coded some boneheaded imitations along the way though. They don't add the blur, or they don't adjust the brightness curve, or they make the radius much too big, or they compute some over exact Gaussian blur that is too slow.
It's the nature of blur that it doesn't have to be exact to be visually pleasing and convincing.
It's shown up in Vista and some other Windows versions since that. I though they used it fairly tastefully, but I'm not a Windows user so haven't spent much time looking at it. Apple currently has the blur radius so high they have to exaggerate the saturation to make the effect noticeable, which looks OK but I prefer a more optically realistic level of blur.
The context of the background is self-maintaining. Reducing the viz/readability of the overlay text does nobody but the art critics any favours. It was, and remains, a bad idea.
> Somehow along the way the cable/TV companies introduced latency in the channel changes and people just accepted it as the new normal.
The technical reason is that digital TV is a heavily compressed signal [1] (used to be MPEG2, perhaps they have moved on to h.264) with a GOP (group of pictures) length that is usually around 0.5-2 seconds. When you switch channels, the MPEG-2 decoder in your receiver needs to wait until a new GOP starts, because there is no meaningful way to decode a GOP that's "in progress".
[1] And the technical reason for the compression is that analog HD needs a lot more bandwidth than analog NTSC/PAL/SECAM, while raw HD transmission would need an absurd amount of bandwidth per channel (about a gigabit/s for 1080p30). So HD television pretty much requires the use of digital compression. Efficient digital video compression requires GOP structures.
Most video players can decode an "in progress" stream just fine. This obviously involves quite a few artifacts for the first 0.5–2 seconds or so, but seeing artifacts is generally preferable to seeing a totally blank screen.
True, and the decoders in receivers already have this capability, since they keep decoding even if the forward-error-correction can't save the stream any more, resulting in similar artifacts. I'm not sure why it's not done on a channel change, perhaps it's the manufacturers not wanting their TVs to routinely show glitched footage, or perhaps advertisers don't want it because it would be against Corporate Design rules to glitch-effect the logos they use on the daily.
Implicitly TV users are also prohibited from making their own technical decisions. I claim this is because the TV predates the era of open computing platforms like Unix.
> I claim this is because the TV predates the era of open computing platforms like Unix.
I claim it's because DRM, since if it wasn't for DRM wanting control of the whole reception to display path to be protected, you could just stick an open computing device in between the streaming signal and the display device, and make your own technical choices.
You still can, AFAIK, for content that doesn't require HDCP.
I remember having a TV tuner card back in the day on my old desktop and this is exactly what I did. I don't watch much TV or anything so.I haven't really checked, but are such cards available today with the encrypted digital cable that's ubiquitous everywhere? Even most broadcast is digital now and requires a decoder box between.
> the TV predates the era of open computing platforms like Unix.
Do you mean Unix-like? I'm not sure what you mean by "open" in this instance, but Unix definitely was not very open, leading to nascent platforms and movements such as GNU and Free/Libre software.
CRTs did tend to take a couple seconds to properly warm up, charge up and reach final image size (the image is directly scaled by the acceleration voltage, which is a high impedance source charging a not-so-small capacitor formed by the aquadag on the inside and outside of the picture tube).
CRTs did need a moment to stabilize the image, but they showed signs of life virtually instantly. At the least they'd make a little noise and had buttons with tactile feedback so you knew something was happening. Many screens today have capacitive touch buttons and have 5 seconds or more between a button 'press' and anything happening at all, leaving you to wonder if you even managed to successfully press the power button in the first place.
Yes! I remember movies and TV shows would have scenes where a character is called and told to turn on the TV for breaking news. They'd see it the story instantly, and that was actually realistic! (Assuming it was big enough news to be on all channels.)
Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".
> Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".
But they still have these scenes in movies
The way these scenes work now is "picks up phone - check the news!", they grab the remote, and turn the volume up on one of the many already running and tuned in wall-mounted 24/7 on TVs ... :)
Are we talking about seeking in media players, or streaming websites? If I watch a random twitch stream I just see a loading throbber, while it loads, not a artifacted version.
Our cable box has three decoders. My gf can watch one channel and record two others at the same time.
Yet does it use any of those extra decoders when not recording to proactively decode the previous and next channel, or something smart like that? No, of course not...
The incoming channel data stream is saved as-is. It will need a demultiplexer to separate out one channel from the multi-channel data stream, but it won't need to decode that stream, which is the intensive bit. Decoding happens when you play it back later.
> proactively decode the previous and next channel
Do you find yourself actually moving up and down the channels, and not through the guide to somewhere else entirely different than where you once where? My first move if I'm switching channels is to go to the guide, not to a channel one above or below my current channel.
I suppose it could run on the previous channel, but it certainly can't guess my next channel.
The first startup I worked with was an IPTV startup that would send the I-Frames for the channels on either side of the channel you were watching at the higher bandwidth tiers so you could channel flip instantly like the old days.
Toxic culture and relationships so the startup imploded, but there was some cool tech.
I'm not sure if this is the whole story. Watching DVB terrestrial TV on my television, channel changing is definitely slower than a good analog TV, but it's much faster than any satellite/cable box I've ever used. And there's a lot of variance between cable boxes. I strongly suspect some of them are doing something silly.
Right, but there's a social/business reason why this is true. There are various things that could be done technically to fix this, for example, you could have three decoders running simultaneously so you always had the adjacent channels buffered, you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.
The real reason problems like this aren't solved is that the organization does not allocate resources to fix them. The status quo has been deemed to be good enough and not leading to the loss of too many customers to the competition, so that's where it stands. This pervades all engineering -- everything just barely works, because once it barely works, for most things, it's good enough, and no more resources are deployed to make it better.
All the time, and unless the images are next to each other you don't really notice unless you're looking for it. Not because there isn't a big difference, but because you just don't really care that much unless it is called to your attention.
I've found pixel-count improvements stop mattering for me somewhere around DVD quality for a lot of content. I can tell the difference between that and 1080P, but stop caring once I'm actually watching the show/film. For the occasional really beautifully-shot film or some very detailed action movies, I guess I might care a little. 1080P versus 4K, I don't notice the difference at all unless I'm deliberately looking for it. And that's even with a 55" screen at a fairly close viewing distance.
What does make a difference? Surround sound. I'd take 5.1 or up with DVD-quality picture over 4K with stereo any day, no hesitation.
The difference between 576i50 (PAL equivalent, free version of the main private channels) and 720p50 (that's what German public service uses for "HD"; it's not actually 1080p, although they use a pretty high bitrate) is pretty stark, the difference between 576i and 1080p is even more obvious. Although TVs don't really have a neutral setting and try their best to mess every image up as much as they can.
I remember a clear improvement in the legibility of things like onscreen scoreboards in sports broadcasts. In the NTSC era I would squint at the TV trying to figure out if the score was 16 or 18 for a football game, and for a basketball game you just had to keep track of it in your head since the scoreboard wasn’t even persisted onscreen. Other things, like telling different players apart, are also easier these days (you can even make out their facial features in a wide shot!)
Hmm, those 2 seconds in between channel changes might be enough to insert a micro ad that could be preloaded in the background. That would appear instantaneously while your channel loads, it would feel a lot more responsive.
I think some boxes advertise that, but how much does it help? On an analog TV you could be switching channels at a rate of say 3-4 per second while still registering the channel logos and stopping on the right one (by going one back immediately). One receiver in either direction isn't going to keep the charade up. Some cleverness, like decoding adjacent channels, but if the user switches a channel down, have the "up" decoder jump to the 2nd channel down in anticipation of the user going another channel down etc., might help, but still. You can't feasibly emulate the channel agility (across ~800 channels on satellite) of an analog RF receiver in a digital system with a modulation that has a self-synchronisation interval of up to a few seconds.
> you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.
GOP length / I-frame interval directly relates to bitrate. Longer GOPs generally result in a lower bitrate at similar quality; in DVDs or Blu-rays I believe the GOPs can be quite long (10+ seconds) to achieve optimum quality for the given storage space.
Non-predictive video codecs are usually pretty poor quality for a reasonable bitrate (like a bunch of weird 90s / early 00s Internet video codecs), or near-losless quality but poor compression (because they're meant as an intermediate codec).
Right but your assumption is that bandwidth efficiency is the only important thing. Why don't they use 10 second intervals if they're more efficient?
My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Honestly it seems pretty obvious to me that the I-frame intervals that are typically used are the outcome of a balance between usability (having to wait until a clear picture can be viewed) and bandwidth as well as processing requirements.
Bandwidth matters because spectrum is a finite commons. Digital TV required giving up bands that were in use for other things (e.g. wireless microphone systems and some ham bands) as it is, using even more bandwidth would have required even more spectrum. Other people have stakes in the spectrum for very good reasons and often much more important reasons than "I wanna watch TV". Even for satellite TV, which uses frequencies high enough that there is lots of bandwidth is limited, because using a lot of bandwidth would require new LNBs and multiswitches for all customers.
> My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Can you name one for each category you bring up? Especially the "engineering" one would be interesting. Obviously dedicating an even huger chunk of spectrum to "I wanna watch TV" would make things easier, so that's not really interesting. And "let's just give each customer a TVoIP stream that can start immediately" is also a pretty obvious "money is no concern" (and also "we don't care about customer adoption costs") option.
I think we're really saying the same thing but from a slightly different perspective.
We agree that there a whole series of parameters that can be traded off against each other:
1. Bandwidth required
2. Number of channels
3. CODEC complexity/engineering effort/cost for encoders and decoders
4. Iframe interval
5. Number of tuners/decoders in receiving equipment
6. Resolution
7. Frame rate
8. Video quality
So the standardization people decide how to set those, and basically channel switch time gets set to the maximum value that doesn't cause people to cancel their service.
If you want to see something pretty astonishing that can happen if you set the tradeoffs differently, check this out: https://puffer.stanford.edu/player/
There are technical reasons for this I guess (as you pointed them out). But what gp is talking about is really a ubiquitous phenomenon of not trying to do anything with it.
Users want to change channels quickly? Okay, let's decompose a problem into what they really want to do, then make N "preview of i-j" channels in 720p with channel pictures in e.g. 8x5 grid and show numbers so that a user could just dial them on a remote. After finding an interesting preview, it's not an issue to push some buttons and wait a couple of seconds to get 2160p or whatever quality there is. Didn't like it? "99<n>", "ok", repeat. This solution would be a jquery of tv world, dumb, straightforward, non-automated, but it would be a thousand (fourty to be honest) times better than nothing.
When I had an hd tv set, I just checked 3-5 channel numbers that I remembered and turned tv off if there was nothing of interest, because you could easily spend half an hour by just peeking them one by one.
OTA TV (Rabbit Ears picking up Digital TV - c.f. older analog NTSC), at least here in Canada, is still using MPEG2. The stream is typically around 20 Mbps, including the audio, which is Dolby Digital 5.1 (except certain channels, such as TVO (TV Ontario), which is DD 2.0).
It's all based on ATSC. While there is an ATSC 2.0, they skipped that in Canada, there will be ATSC 3.0, which will use HEVC (H265) for 4K. But don't hold your breath on that...the TV stations aren't exactly opening their wallets to upgrade anything!
Another reason for the lag is that the modulation scheme is complex and requires considerable time to both acquire the actual demodulator lock (in fact, the symbol in typical terrestrial DTV system is surprisingly long) as well to acquire synchronization of the higher level FEC layers.
I don't buy this. We had an old cable box that had instantaneous channel-switching. The cable company made us switch to a brand new one. Same signal coming in, but the new one was infinitely slower. It wasn't some change in the signal that made things slow, it was the software and the complete lack of care for performance.
The old cable boxes were literally switches, with all channels flowing into the box all the time. Now switching is virtual and done on the server (plus all the software encoding/decoding).
Right now I would be satifsied with at least some caching of the menus, so it doesn't have to pull the data everydamntime I scroll up or down. Come on, it should be able to remember what channels I have for more than 5 minutes in a row.
It probably does cache the data, and it just takes ages to draw. Manufacturers really cheap out on settop box CPU and RAM specifications in order to make the pricing attractive to cable companies.
Yes and they still have insurance to cover the loss, anyway.
You didn't think a cable company was going to deal with it's customers fairly, did you?
Every time you interact with a customer, there is an opportunity for profit. Telecommunications companies, cable TV included, are masters at this type of behavior.
You get the cable box for the new system BEFORE they switch the old system off, or else you wouldn't have service until you got a new box. That's why you saw behavior change with the new box.
It simply isn't possible to send all the channels to customers at all times. There isn't enough bandwidth. So, the cable box at your house negotiates with the central or regional system so only a subset of channels are sent to you. There is no other way to do it in digital cable systems, and the switch to digital was made because it uses significantly less bandwidth than analog.
> The technical reason is that digital TV is a heavily compressed signal [1] (used to be MPEG2, perhaps they have moved on to h.264) with a GOP (group of pictures) length that is usually around 0.5-2 seconds.
Just because they transmit keyframes and deltas in the steady state doesn't mean they need to wait for the next keyframe when starting the stream. They could also choose to send you the current reconstructed frame as a keyframe immediately instead of waiting several seconds for the next pre-made one. The cost to them would be epsilon (one new stream client per channel to be the source of reconstructed keyframes), and the customer experience difference would be noteworthy.
No. It will work regardless. I'm talking about having a single additional client decompress the broadcast and act as a first-frame keyframe source based on the decompressed stream. In a traditional compressed stream, a reconstructed frame is already the context for the next delta after the first. Sending a frame reconstructed by someone else allows you to immediately begin using deltas, and it's a close enough approximation of the original uncompressed frame that the immediate result will be quite good even if not perfect, especially compared to waiting.
At worst it would only be as bad as a transcoded stream for the first few seconds until the subsequent true keyframe arrives. That's loads better than no stream at all.
There's additional issues with changing channels than just GOP sizes. For cable TV signals are still channelized into 6MHz channels. QAM modulation is used which gets about 40Mbps per 6MHz channel.
An MPEG transport stream is sent over that 40Mbps "channel". Inside of that transport stream are several elementary streams, each carrying either video, audio, or data/program information. A TV station will be carried by a combination of a video (MPEG-2/4) and audio stream. These streams are packetized such that a receiver won't get buffer underruns or overruns. The transport stream is further packetized. Adjacent station broadcasts aren't always carried on the same transport stream.
So when you hit the button to "change channels" the cable box may need to tune to a new radio channel, wait for transport stream packets for the station, and then buffer enough data to start playback.
The GOP size then plays a part because the decoder needs an I-frame to do anything useful with the P-frames inside the GOP. Cable providers use longer GOPs to get better quality at a given bitrate, I-frames are much larger than P-frames so the more you send the higher the bitrate you need.
Sending I-frames for other broadcasts in the same transport stream would be a waste of bandwidth. The data used for these rarely used extra I-frames takes away from bandwidth programming in the stream could use. There's also still the lag from tuning a new channel and waiting for those I-frames to show up. So you've wasted bandwidth for a very slight increase in responsiveness.
Currently I'm talking only about sending _one_ additional I-frame per station switch at the time of the switch, not always sending them or sending them for unrelated broadcasts. I just object to the idea that it's reasonable for a feed to start with seconds-worth of unusable P-frames, and it doesn't seem to be strictly necessary.
How does a DVB-T Transmitter know about a receiver switching channels? A DVB-S signal is just forwarded by a space relay fed by an uplink site fed by a number of stations. These are not interactive duplex media like the internet or by possibly some forms of cable TV.
Sorry. My context here is cable boxes, which do communicate bidirectionally and somehow take even longer than DVB receivers to change channels. If you're actually receiving everything all the time, then there are other things you can do to make channel switching not take ridiculously long.
Cable boxes do not typically have bidirectional connections. The cable head end doesn't know about channel changes. Don't think of cable TV like web streaming.
Cable systems don't often re-encode streams they receive from upstream sources. The video from upstream is already compressed so the elementary streams are remuxed into the cable system's channel plan. The cable head end doesn't receive raw video and encode it in real-time. Even local OTA stations just get remuxed rather than re-encoded.
Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end in case someone flips a channel. Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
Even IPTV isn't a bidirectional signal. It uses IP multicast and the tuners just change their multicast address to change stations. The stream is the same MPEG transport stream as the QAM signal but sent as IP packets. The head end still doesn't decode every station to send bespoke I-frames in the event someone flips the channel.
> Cable boxes do not typically have bidirectional connections
This hasn't been true in many places since the takeover of digital cable in the 2000s. Without a bidirectional data link, how do you think cable internet works? Or cable telephony? Or pay-per-view for that matter? It's all on the same line into the same box.
> Cable systems don't...
Don't isn't couldn't. When talking about solutions to problems, merely describing a problem isn't where the conversation ends.
> Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end
That's what I described. The cost of doing it is epsilon.
> Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
If you can stream Netflix while watching TV without hurting your neighbors, then you can receive one single I-frame.
Sorry. My context here is cable boxes, which do communicate bidirectionally and somehow take even longer than DVB receivers to change channels. If you're actually receiving everything all the time, then there are other things you can do to make channel switching not take ridiculously long.
And yet using puffer[0] I get instant channel switches at 1080.
There is no technical reason you can't have instant channel switches, it's just that they aren't making the right technical decisions to allow it and/or don't want to pay for it.
Depends on your network and your landline but I guess a fairly isshy network compared with a fairly common POT landline you would definitely see a difference. Packet switching (Vs circuit switching) alone should in principal introduce a latency - then there’s a lot more interconnects - and on top of that whatever hocus pocus they use to optimise their (digital) bandwidth usage. Of course modern land lines probably are more like mobile now but not unreasonable to expect circuit switches analogue POT are still widely used.
Cell phones have encoding/compression delay on the voice part, delays waiting for a transmit slot if the air interface is time division multiplexed, sometimes a jitter buffer to allow for resends/error correction, and often less than ideal routing (lots of people are using numbers from out of state, which may require the audio path to traverse that state).
Originally POTS was circuit switched analog connection between you and the other party --- only delays from the wires, and maybe amplifiers. Nowadays POTS is most likely digitally sampled at the telco side, but each sample is sent individually --- there's no delay to get a large enough buffer to send, because for multiplexed lines each individual line is sampled at the same rate and a frame has one sample from each.
The only thing cell phones have on copper land lines is portability. In all other ways they suck. I think we only tolerate this because most of us have completely forgotten how much better land lines were, or we never experienced them to begin with. The first big hit to phones came with the cordless models. No longer comfortable to hold against your ear, the earpieces got flat or even convex, and mashing it up against your head made for an unpleasant converation. But hey, we got rid of cords! And then the change to cell phones, with their tiny fraction of available bandwidth, terrible sound quality, high latency, high failure rate, etc.
The astonishing thing is that bandwidth isn't a big deal now, and we could have improved basically all aspects of mobile calls to be within spitting distance of what we used to have 30 years ago.
No wonder people don't like to talk on the phone any more.
> The only thing cell phones have on copper land lines is portability. In all other ways they suck
Isn't that a little like saying "The only thing boats have over cars is that they can go on water. In all other ways they suck"? Portability is the entire point. Even in the "good old days" most people would have accepted nearly any tradeoff for the ability to carry even the simplest global communications device with them.
Alternately, the value of low-latency experiences is not as high as we believed - or it's poorly measured.
Particularly in Enterprise software, the time to complete a workflow or view specific data matters a lot - the time to load a page is a component of that, but customers will gladly trade latency for a faster e2e experience with less manual error checking.
In consumer the big limiting factor is engagement, a low-latency experience will enhance engagement. However it's possible to hide latency in ways that weren't possible before such as infinite scrolls and early loading of assets. The engagement on the 50th social feed result has less to do with the latency to load the result, and more to do with how engaging the content is.
Meanwhile, most of those ways to hide latency have other issues, like the good old "link I need is below the infinite scroll" or "I just want to go back to a specific time, but I have to scroll through every single thing between then and now instead of just jumping 10 pages at a time". Which we would avoid if instead we tackled the actual problem.
It is the nature of progress: progress is doing more with less. That’s increased productivity.
Of course software now uses more computing resources, so that’s not doing more with less. But the computer is cheap. What’s expensive is the humans who program the computer. Their time is expensive, and getting experienced, expert humans is even more expensive.
So we now have websites that have rich features bolted together using frameworks. Same for desktop software, embedded systems, and whatever else. They’re optimized for developer time and features, not for load time because that’s not expensive, at least not in comparison.
As a user the only solution I see to this is to use old fashioned dumb products rather than cheaply developed “smart” ones. For instance I’m not going near a smart light switch, or a smart lawn sprinkler controller. Old dumb ones are cheap and easy and fast and predictable.
>But the computer is cheap. What’s expensive is the humans who program the computer.
This is a nice half-truth we tell ourselves, but that's not the full story.
There exists plenty of optimizations where the programmer-time would be smaller than the additional hardware cost. And those losses compound. But they're a little too hard to track, and cause is a little too far divorced from effect.
I did our first ever perf pass on an embedded application as we started getting resource constrained. I knocked 25% off the top in a week. Even if I had spent man-months for a 10% savings, try and tell me that's more expensive than spinning new boards.
That's not to say we're opposed to hardware changes; we do them all the time. But the cost curve is weighted towards the front so it's more attractive to spend a non-zero amount of developer time right now to investigate if this other looming spend is avoidable. That's not the case when you're looking at controlling the acceleration of an AWS bill that spreads your spend out month to month through eternity.
Who wants to spend a big chunk of money up front to figure out if you can change that spend rate trend by a tiny percentage? Even if you do, and get a perf gain, but someone else on the team ships a perf loss? Then it doesn't feel real, and you can only see what you spent. Even if you have good data about the effect of both changes (which you don't), the fact the gain was offset means the sense of effect is diminished.
And rather than investigate perf, people can always lie to themselves that the cost is all about needing to "scale." That way they convince themselves not only was there nothing they could have done, the cost is a sign that their company is hot shit.
And if perf has any impact on sales, cause and effect are even further apart. You might be able to measure the effect perf has on your sales website directly, but if that feedback loop involves a user developing an opinion over days/weeks? Forget about knowing. Oh, sure they'll complain, but there are no metrics, so we get the rationalizations we see in this thread.
> Ever noticed how long it takes to kill an app and restart it? Ever notice how much more often you have to do that, even on a 5-month old flagship phone
> Ever noticed how long it takes to kill an app and restart it? Ever notice how much more often you have to do that, even on a 5-month old flagship phone?
Is this an android problem? I don't really ever have to close apps unless the app itself gets stuck into a broken state and forcing close to restart can correct the issue.
> I think it might just be the nature of progress, but I hate it.
I suspect that the root cause is that nobody understands what's going on from the UI down to the hardware, and nobody is incentivized (or even allowed) to spend the time it would take to actually do so.
Microwaves are another example. Used to just turn a knob to the number of minutes you want, and done. Now it's five button presses. (Maybe not exactly a latency thing, but a UX one that makes it slower).
At least some microwaves will run N minutes when you press the N button once. Also you can hit the add 30 seconds button a couple of times, and it starts running instantly.
> Remember when channel changes on TVs were instantaneous?
Remember when turning a TV on was <0.5s?
My current dumb TV takes a good while to turn on. When I press the power button, it takes about 1s for the indicator light to change than another 2 or 3 to begin displaying anything.
Interesting. I meant CRTs. Maybe my memory is a bit rose tinted.
Still, I remember never having confusion about whether my CRT TVs where responding to the power on button press or not. There are plenty of times where I turn my current TV off since I think it didn't receive the first button press.
Most CRTs made an obvious _noise_ when turned on (actually, one of the curses of good high-frequency hearing was that they made an obvious noise for the whole time they were on, though I think a lot of people couldn't hear them after warmup). That helped, I suppose.
The image took some time to stabilise (and was black at first), but the things turned on instantly, with the light indicator visible without delay (and the sound of the CRT turning on).
Now, quite often I have to wait 5s to see whether the button push was registered, push again because the TV still does nothing, and then watch as the thing turned on just as I was pressing and interprets the second push as a signal to go on standby (5 more seconds with an obnoxious message about it going to sleep, and yet 5 more to wake it up). It’s like the USB-A that needs to be rotated twice every time you want to plug something.
I once had a glitch on my iphone back in iOS 9.x. The glitch made it that all transitions/animations were disabled and it was a fantastic experience to click an app and have it open instantly. Turning off animations in IOS settings doesn't make it as fast as that glitch did unfortunately.
>Remember when channel changes on TVs were instantaneous? Somehow along the way the cable/TV companies introduced latency in the channel changes and people just accepted it as the new normal
Phones used to be rotary dial but then touch tone phones with number buttons were introduced. I was reading an article about human brains and its expectations. Going from a touch tone phone to an old rotary style phone seems excruciatingly slow to our brains. Depending on the number a 1 on each it's very close in duration but a 9 or a 0 on a rotary compared to a touch tone 9 or 0 seems glacial in speed.
Even worse; in some countries, touch tone exchanges took a while to roll out, with the result that keypad phones which supported both pulse dialing and tone dialing were common. And then people never switched them over to tone dialing. There were people pulse dialing into the 21st century.
Yeah, I remember when that first started happening, and I agree it was really frustrating. The funny thing is that I no longer channel surf, so I no longer hit this. I realized the other day that I haven't watched cable TV in a long time. My TiVo is empty and has been for a long time, but I watch TV every night using streaming devices instead.
> The funny thing is that I no longer channel surf
The cynical side of my brain feels that this is exactly what TV stations and show producers wanted. If it's fast and easy to spin the dial and maybe stop on a competitor (and more importantly, watch their ads instead of yours) then you have to put our quality product and not annoy the customer with as many loud and irritating ads, which means that you don't make as much money from the content that bookends your ads.
The worst is they "fixed" it with "digital knobs" now. But due to anti-glitching logic, they are still not as responsive as you want and annoying to use. Especially volume controls.
There's nothing quite as annoying as having to use the cheapest rotary encoder, that already feels like shit, but the firmware is also polling it incredibly slowly, and is debouncing it incorrectly, and it probably bounces like hell, so not only does it feel bad to use it, but it actually doesn't work half the time and goes a step or two in the wrong direction, even if you spin it evenly into the other.
These things are like these fake volume controls reddit made up.
The rampant consumption of resources ...has outpaced the provisioning of new resources. I think it might just be the nature of progress, but I hate it.
Someone had to more or less decide to handle it that way for some reason. So I am skeptical that "it's just the nature of progress."
Remember when you could look at a book, a guide, to see what was on and when? It never took more than a minute or two. Then came the TV channel with the slowly-scrolling list of channels (early 90s). Try figuring out today which shows will be available tomorrow at a particular time... and whether you have subscribed to that channel. Good luck. I don't think it is even possible anymore.
Eh, most cable companies now have a dedicated guide menu with manual scrolling and search features rather than a scrolling channel, I'd say that's one of the few things to have improved since old days
The history of the automobile is another such example. Brief summary: it turns out the invention of the car didn't really save anyone time, it just enabled sprawl.
The purpose of technology (in the POSIWID sense) is to concentrate wealth.
Who are these "people" you're talking about? I would much rather live close to everything and walk, bike or bus. Instead I have to have a car because work is 3 miles away, doctors are 5-30 miles away, the grocery store is 5 miles away, the nearest convenience store is a mile away. And I live in the middle of one of the biggest metro areas in the country!
I'd like to have a farm in the middle of downtown too. It isn't possible. You get more choices in the same amount of time with a car, and get more space as well. Without a car you better like the doctor withing waking distance (my family considered them quacks and has heard plenty of stories about people almost dieing because obvious things were not caught in regular visits, instead the ER had to figure them out when it was almost too late). Ymmv, I like choices.
Of course cars do take up a lot of space, but even factoring that in you have more choices in a reasonable time with a car than without.
Don't read this as me approving of cars. I understand the appeal and drive, but I hate it.
It used to be software would get written, and then iterated over to optimize and refine it to make it smaller/faster. That got too expensive, so the devs just depended on CPU speeds increasing and drives getting larger.
While I can see the technical reason why channel changes take a while with digital TV, I've always wondered why switching the digital input of your TV, or just changing the resolution of the connected devices takes so long. On most TVs it's over two seconds. The signal is in most cases just a stream of standalone, uncompressed frames. Switching from HDMI1 to HDMI2 should take a few milliseconds.
Ok so HDCP might be an explanation although I wonder if it has any impact if it's not in use. Don't really know how it works tbh.
As for the rest: Resolution negotiation is optional and wouldn't matter if the device is already outputting at some resolution, also this happens on different pins, so even if the device would first query the EDID of the TV to figure out what mode it prefers, the TV could meanwhile already display whatever the device is outputting. Same with CEC, this is another protocol on different pins than where the picture data is sent. HDMI really is just DVI with some extras, at least for the older versions.
I don't know why (but would be interested), but even PC screens are usually very slow at switching (>1 second delay), and for some inexplicable reason practically all of them turn their backlight off while doing it.
I’ve always assumed that’s because TV manufacturers choose the most under-powered SoC they can get away with, don’t put half as much RAM as it needs, and let loose incompetent programmers who don’t have to use the damn thing ever. Still very frustrating.
Having used 14.4k dialup on a 486DX2-66MHz at 640 x 480 VGA, I really don't think 2020s technology is outstandingly slow.
I don't even think most phone apps are bloated, because most phone apps - and web sites - are just electronic forms decorated with a bit of eye candy.
Security and reliability worry me far more. Many sites have obvious bugs in $favourite_browser, and some just don't work at all. Some of this is down to ad blocking, but that shouldn't be a problem - and the flip side is that blocking ads, trackers, and unwanted cookies seems to do wonders for page load speeds.
I've used an 8 bit computer with a 300 baud modem. One bbs I dialed into was a 8 bit computer with a whopping 4mb of ram. It was the fastest response time of any computer I've every used. Everything was in ram, and coded in assembly with speed and low code space as the concern.
Modern computers should be much faster, but they aren't. They do more, but when you do something you notice the slow speed.
I don't think it's the nature of progress. There's no question we have the _capacity_ to engineer our way out of these problems. They aren't unsolvable. But a lot would have to change before the necessary resources are mobilized against these kind of problems instead of churning out yet more bloat, which, let's face it, is what most of us are doing with our time every day.
Your last paragraph is so true. I feel that's an issue we are facing a lot in every domain. I see people writing highly inefficient back-ends Because they believe anyways we are going to scale it horizontally, so it doesn't matter. The similar applies to frontends too I guess, people don't care to optimize apps either. They're like anyways the minimum configuration on which our apps run are getting better day by day, so why not build a resource hogger!
I personally believe we should start having "bootcamps" which talk about optimizations, and the cost of stupid designs. I'm also looking forward to compile time and run-time optimizations so that we don't even have to rely on the developers for it.
It’s the marketing team’s fault. I proposed a common, standardized solution for showing promotions on our website, but no... they wanted iframes so their designers could use a WYSIWYG editor to generate HTML for the promotions. This editor mostly generates SVGs, which are then loaded in to the iframes on my page. Most of our pages have 5-10 of these iframes.
Can someone from Flexitive.com please call up my marketing coworkers and tell them that they aren’t supposed to use that tool for actual production code?
Can someone also call up my VP and tell them they are causing huge performance issues by implementing some brief text and an image with iframes?
Can someone fire all of the project managers involved in this for pushing me towards this solution because of the looming deadline?
I think we need to start differentiating between webpage speeds and web application speeds. Namely, a webpage would work if I disable the JavaScript in my browser, but a web application would not. By this definition, web page speeds has improved a lot.
While I agree with the idea and I am not happy about slow apps, the truth is, it's focused on technical details.
People don't care about speed or beauty or anything else than the application helping them achieve their goals. If they can do more with current tech than they could with tech 10-20 years ago, they're happy.
Every statically backed research on customer behaviour I have ever seen says otherwise. The more you slow down the page or app the less customers like and use it or buy the product being sold. As someone with a homemade site for our business I can say that it is extremely easy to be faster than 95% of sites out there and it makes a huge difference, also on Google. Tiny business with homemade website in top 1-3 on Google was mindbaffling easy because everyone use too many external sources and preschool level code. Especially the so-called experts. Most are experts in bloat.
Really? My text only websites that I've written and hosted for myself are really snappy. I wouldn't know the feeling.
All I needed to do was spend a weekend scraping everything I needed so that I could self host it and avoid all the ridiculous network/cpu/ram bloat from browsing the "mainstream" web
It's a hard pill to swallow that 20 years since I started using the internet websites perform worse on vastly superior hardware, especially on smartphones.
I frequent one forum only through a self-hosted custom proxy. This proxy downloads the requested page HTML, parses the DOM, strips out scripts and other non-content, and performs extensive node operations of searching and copying and link-rewriting and insertion of my own JS and CSS, all in plain dumb unoptimized PHP.
Even with all of this extra work and indirection, loading and navigating pages through the proxy is still much faster than accessing the site directly.
Thank you. It's one of my most-mentioned law or principle, and I keep having to Google it to remind myself what it's called or so I can link it to a colleague. It's fun to be part of a discussion with other people who already know about it (and that's a fairly intelligent discussion, too; the security angle is interesting).
This is often intentional. Take a look at any OS or software with animations. Slowness for slowness sake. The macOS spaces change has such a slow animation, it's completely useless. Actually, macOS has a ton of animations to slow things down, but luckily most can be turned off. Not the spaces thing. Android animations are unbearable and slow things down majorly. Luckily they can be turned off, but only by unlocking developer mode and going in there. It's clear whoever designed these things has never heard of UX in their lives. And since these products are coming from companies like Google and Apple, which have UX teams, it leads me to think that most UX people are complete idiots. Or UX is simply not a priority at all and these companies are too stupid to assemble a UX team for their products. Hard to say which is the case.
Or, perhaps, maybe you're just not the target audience and those animations are designed as visual indicators for less experienced users?
Those animations are absolutely a product of well researched UX design, it's just design that's intended to make the UI more accessible by showing users the flow of information and how the structure of the interface changes in a visual manner, rather then design intended to address the needs of power users. The animations used in the Spaces feature on MacOS is a good example of that, where apps and desktops slide and zoom around to make it absolutely obvious that the apps you have open haven't just disappeared. That's quite important for a fairly advanced desktop manipulation feature like that.
Modern operating systems are designed for broad audiences, and that includes people who aren't as savvy with technology as we are. That means accepting some level of tradeoffs between the speed that pro users want, and UI accessibility that necessitates slowing things down somewhat. In the case of desktop OS's there's still usually ways for power users to disable that stuff and of course Terminal for those who don't really need a UI at all. And then there's a lot of different flavors of Linux that make no attempt at appealing to a less technical audience.
But just because you're not the target audience doesn't mean the UX team are "idiots" or that the companies are "stupid". The amount of novice or casual users is orders of magnitude higher then power users who care only about efficiency, and for better or worse those users always come first.
I'll believe they have UX teams when they offer an easily accessible option to turn those things off. There's zero reason why they can't target both use cases with a simple toggle to turn animations on and off. The stupidity is expanded when this exists but is not easily accessible. Those that haven't thought of that yet are indeed stupid (Apple). Some videogames have the same issue with unskippable cut scenes. Am I not the target audience there either? If not, then who is? Who wants to watch the same cut-scene a thousand times? The UX is equally horrific in both cases and in both cases, clearly no thought went into the UX whatsoever.
The spaces transition seems relatively fast for me with Accessibility > Display > Reduce Motion on. This switches it from sliding to crossfade.
Locating the window I'm looking for takes longer than the animation and I can start looking immediately during the fade. Even with the ctrl+number shortcuts, I can't get my hands back onto the home row before the animation finishes.
Hands back to home row? Mine never left. The fade is a little better, almost usable, but not quite. Certainly not something I want to see hundreds of times a day while I'm trying to get work done. Same problem with full screen apps which also use this system.
Part of the problem is analagous to traffic congestion / highway lane counts: "if you build it, they will come". More lanes get built but more cars appear to fill them. Faster connection speeds allow more stuff to be included, and the human tolerance for latency (sub 0.1s?) hasn't changed, so we accept it.
Web sites and apps are sidled with advertising content and data collection code; these things often get priority over actual site content. They use bandwidth and computing resources, in effect slowing everything down. Arguably, that's the price we pay for "free internet"?
Finally (and some others have mentioned this), the software development practices are partially to blame. The younger generation of devs were taught to throw resources at problems, that dev time is the bottleneck and not cpu or memory -- and it shows. And that's those with some formal education; many devs are self-taught, and the artifacts of their learning manifest in the code they wrote. This particularly in the JS community, which seems hellbent on reinventing the wheel instead of standing on the shoulders of giants.
In spite of an increase in mobile CPU speed, mobile phone startup time have not improved (in fact they became slower).
In spite of an increase in desktop CPU speed, time taken to open AAA games have not improved.
In spite of an increase in elevator speed, time taken to reach the median floor of an building have not improved.
My point is, "webpage" has evolved the same way as mobile phones, AAA games and buildings - it has more content and features compared to 10 years ago. And there is really no reason or need to making it faster than it is right now (2-3 seconds is a comfortable waiting time for most people).
To put things in perspective:
Time taken to do a bank transfer is now 2-3 seconds of bank website load and a few clicks (still much to improve on) instead of physically visiting a branch / ATM.
Time taken to start editing a word document is now 2-3 seconds of Google Drive load instead of hours of MS Office Word installation.
Time taken to start a video conference is now 2-3 seconds of Zoom/Teams load instead of minutes of Skype installation.
This hipster atttiude of replacing proper software with barely functional webapps really gets on my nerves.
People use and will continue using Skype and especially MS Office. It is much more functional that gSuite alternatives and moving people to castrated and slow webapps is not progress.
>My point is, "webpage" has evolved the same way as mobile phones, AAA games and buildings - it has more content and features compared to 10 years ago. And there is really no reason or need to making it faster than it is right now (2-3 seconds is a comfortable waiting time for most people).
What features? I don't know anything substantive a site can deliver to me today that it was not capable of 10 years ago. The last major advance in functionality was probably AJAX, but that doesn't inherently require huge slowdowns and was around more than 10 years ago.
The rest of your comparisons are dubious:
>Time taken to do a bank transfer is now 2-3 seconds of bank website load and a few clicks (still much to improve on) instead of physically visiting a branch / ATM.
This is the same class of argument as saying that (per Scott Adams), "yeah 40 mph may seems like a bad top speed for a sports car, but you have to compare it hopping". (Or the sports cars of 1910). Yes, bank sites are faster than going to ATM. Are they faster than bank sites 20 years ago? Not in my experience.
>Time taken to start editing a word document is now 2-3 seconds of Google Drive load instead of hours of MS Office Word installation.
Also not comparable: you pay the installation MS Word time-cost once, and then all future ones are near instant. (Also applies to your Skype installation example.)
> What features? I don't know anything substantive a site can deliver to me today that it was not capable of 10 years ago. The last major advance in functionality was probably AJAX, but that doesn't inherently require huge slowdowns and was around more than 10 years ago.
Okay, a site that was announced less than 24 hours ago. That's not what a typical site looks like that demonstrates your claim that most of these bloated sites are only bloated to provide advanced functionality that they can't otherwise. Did Buzzfeed or the typical news site just start offering video editing?
It rather has slowed down with some websites, or those websites did not exist back then, because they would not have been possible.
Just today morning, when I opened my browser profile with Atlassian tabs (Atlassian needs to be contained in its own profile), there were perhaps 7 or 8 tabs, which were loaded, because they are pinned. It took approximately 15-20s of this Core i7 7th Gen, under 100% CPU usage of all cores at the same time to render all of those tabs. Such a thing used to be unthinkable. Only in current times we put up with such state of affairs.
As a result I had Bitbucket show me a repository page, Jira showing me a task list, and a couple of wiki pages, which render something alike markdown. Wow, what an utter waste of computing time and energy for such simple outcome. In my own wiki, which covers more or less the same amount of actually used features, that stuff would have been rendered within 1-2s and with no real CPU usage at all.
Perhaps this is an outcome of pushing more and more functionality into frontend client-side JS, instead of rendering templates on the server-side. As a business customer, why would I be entitled to any computation time on their servers and a good user experience?
Another factor is a wider use of all sorts of CMS (WordPress etc) for content presentation, combined with often slower/underpowered shared hosting and script heavy themes.
On some cheap hosters it may take a second just to startup the server instance, that's before any of the outgoing requests are done!
Yep - to the executives, saving a couple of (theoretical) hours of development work is worth paying a few extra seconds per page load. Of course, the customers hate it, but the customers can't go anywhere else, because the executives everywhere else are looking for ways to trade product quality for (imaginary) time to market.
791 comments
[ 3.0 ms ] story [ 367 ms ] threadOn the contrary, sites like google/Facebook (and apps like Instagram or Snapchat) are incredibly well optimized as they stay within their own 1st party ad tech.
Having said that, FB and Google properties (like YouTube) have insane edge over the rivals by having full control over the advertising stack.
It's simply Parkinson's Law
Why bother writing binary search? Linear search is fast enough. Why bother sharing pointers? Copy all the strings. Easy. Data compression? Forget it. Deleting files is totally irrelevant, etc, etc.
Another related side-reason why it's slow is we use higher and higher levels of abstraction, exactly to increase development velocity and be able to add more features quicker. I could write a native app in pure assembly and have it be blazing app, or I can write a webapp on top of web frameworks running in Electron, but in a fraction of the time. As long as my app is usable, I'll get all the user while the other person is still trying to finish their app.
(This is on a Macbook Air from 2015, but these are really simple requests.)
However, in terms of Facebook, I'd say it was well optimized considering its complexity prior to the recent redesign. But ever since the new design, my Macbook Pro can barely type on that site anymore. My machine has a 2.5 GHz Quad-Core Intel Core i7 and 16 GB of RAM.
That's pretty sad. Responsive design is a great idea, but in terms of how it is sometimes implemented you're getting X numbers of styles to load a page.
The number of sites that will be loading images and js from three or four or more different ad/tracking and CDNs is nuts, plus the various login and media links, and I feel zero guilt for not participating in this advertising insanity.
Tightly put together pages with only a handful of JS loads are damn near instant over gigabit fiber.
It's 2020. This should not be that hard. I've worked at a bank and know that "customer data" is top priority but at what point does the buck stop? Just because you can, doesn't mean you should.
Luckely there are tools like Lighthouse[0] but with all the abstractions and frameworks inbetween it is often impossible to introduce the required changes without messing up the quality or complexity of the code/deployment.
[0] https://developers.google.com/web/tools/lighthouse
We're not quite there, since web pages are generally more than one screen, but we're getting close. Motivated searchers could probably find a concrete example of such a page somewhere.
No, you can not add the whole c++ std lib into our code. Yes, I know it is useful. Yes, that will save you 2 hours of work. However, the code no longer even fits into the 1MB of flash we have. Yes we can ask for a new design the management would love to spend 500k on spinning a new design and getting all of the paperwork for it done, and our customers would love replacing everything they have for functionally equivalent hardware that now costs 50 dollars more each. But at least you saved 2 hours writing some code.
Management should seriously consider whether the 0.01c saved on that 8Mb chip is worth the design overhead from very tight constraints. There is most likely a pin-compatible 16Mb chip that would eliminate all the pain.
Yes, I know that in high volumes every fraction of a penny counts. But if you frequently find yourself engineering your way out of trivial constraints, you might be doing it wrong.
Then the candidate is selected and goes to work where the selection bias fades into expectations of conformity onto a bell curve. The people who conform to the middle of the curve are generally the ideal employees. The people at the low end of the curve are either released or retained as padding against future layoffs. The people at the high end of the bell curve are an anomaly. Those people are far more productive but are willing to use less popular conventions to achieve superior results which tends to result in friction.
This makes them large in MB but that's not the true cause of the problem. The true cause is all the external calls for loading JS from other sites and then the time to attempt to execute that and build the actual webpage.
I'm rebuilding a site for a client and using a bunch of dynamic imports, if you don't touch a video route, you'll not download the videojs bundle at all, I set a performance baseline for the site to be interactive and anything that makes it go over the baseline needs a good reason to be there.
It isn't purely about speed, it is about perception, a very slow first page load is way more annoying that a couple half or quarter second loads distributed over a long interaction, after the js is cached all is nearly instantaneous, but you don't have to wait a while to start using the site in your first visit.
If you want you can also wait for the first page to download completely and them import the remaining js while the user is on the first page, but I didn't tried to see how well it works.
What's wrong with accessing resources in a RESTful way?
A page refresh? At this point, a page refresh is so much more bearable than a 2300ms SPA download and hang ups.
As an added bonus, you can bookmark resources. Back button works!
(For the record, I don't think that every app that is an SPA should be, but I do think that they have a place.)
SPAs are a lot easier to keep secure though, so if you don't want your private data leaked then they're a much better option.
That won't always work out or be necessary though.. For an app like Lucidchart or something, I can deal with DL'ing updates every now and then. I spend most of the time in the running app.
Beyond that, unless your users are a captive audience (have to use your software for their job) you should probably be optimizing for a positive first impression.
I blew off JAMstack as another dumb catchphrase (well, it is a dumb catchphrase), but then inherited a Gatsby site this past spring. It absolutely knocked my socks off. The future is bright.
There hasn't been a new idea in computing since the 70s. The only thing we've done is mutate a square peg into a round one and back again. Each time patting ourselves on the back for the sheer brilliance of the move.
It's not a design pattern, and the element of it that uses one (React) usually implements Flux, not MVC.
As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.
No, it's like I'm saying: Software development is fad driven and shallow. The details change but those details are unimportant and ultimately pointless. Bad metaphors are exactly the type of shallow thinking I'm talking about.
A GUI is not a car, a duck, or a fish. It is a UI. That the web is being used as an interactive GUI is a travesty. Without knowing the history of why it was invented in the first place - extremely high latency and low bandwidth of the 90s internet - you will never understand why mutating it to a full GUI is a terrible idea. And why we should have used any of the dozen well engineered technologies that are not hypertext based but work with the internet (low latency high bandwidth) we have today.
It's gotten to the point where an X server in an Amazon data center and a VNC client on a phone is more responsive than facebook, twitter and reddit on mobile.
>As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.
Yes, using TeX would be an infinite improvement over the mess we have today. Imagine having one language for everything in a site, instead of the three (five? with markdown and js frameworks) you need today.
We're all doomed.
https://www.npmjs.com/package/is-odd-or-even
The big headache is when you have a site half-setup -- its correct for all of your usage, and then you try something new and you get a video that doesn't load, and you sit there waiting until you realize umatrix probably found something new
Remember when channel changes on TVs were instantaneous? Somehow along the way the cable/TV companies introduced latency in the channel changes and people just accepted it as the new normal.
Phones and computers were at one point very fast to respond; but now we tolerate odd latencies at some points. Apps for your phone have gotten much much bigger and more bloated. Ever noticed how long it takes to kill an app and restart it? Ever notice how much more often you have to do that, even on a 5-month old flagship phone? It's not just web pages, it's everything. The rampant consumption of resources (memory, CPU, bandwidth, whatever) has outpaced the provisioning of new resources. I think it might just be the nature of progress, but I hate it.
It seems to me that we have lower performance, exponentially higher resource consumption, and often no more functionality in a “modern” web app / Electron app compared to some desktop apps from the 90’s. And for what? To have even worse UI’s and UX’s that never conform to platform guidelines? Where’s the progress?
Not to mention flat design, which is without exception bad design. Buttons have borders, show them.
I don't think it's the nature of progress so much as it is laziness. Most developers (myself included) don't worry much about optimization until the UX performance is unacceptable.
I sometimes wonder what the world could be like if we just froze hardware for 5 years and put all of our focus on performance optimization.
The effect doesn't have to be expensive, and my original implementation was fast on millenium era machines. The goal is preserve the context of the background, while keeping foreground data readable, in a way that is natural to our human visual system. If you are doing it properly you also shift the brightness values into a more limited range to diminish the contrast and keep the tonal values away from the chosen foreground text color (this is also cheap). Done properly it is visually pleasing with virtually no effect on readability.
People have coded some boneheaded imitations along the way though. They don't add the blur, or they don't adjust the brightness curve, or they make the radius much too big, or they compute some over exact Gaussian blur that is too slow.
It's the nature of blur that it doesn't have to be exact to be visually pleasing and convincing.
The technical reason is that digital TV is a heavily compressed signal [1] (used to be MPEG2, perhaps they have moved on to h.264) with a GOP (group of pictures) length that is usually around 0.5-2 seconds. When you switch channels, the MPEG-2 decoder in your receiver needs to wait until a new GOP starts, because there is no meaningful way to decode a GOP that's "in progress".
[1] And the technical reason for the compression is that analog HD needs a lot more bandwidth than analog NTSC/PAL/SECAM, while raw HD transmission would need an absurd amount of bandwidth per channel (about a gigabit/s for 1080p30). So HD television pretty much requires the use of digital compression. Efficient digital video compression requires GOP structures.
I claim it's because DRM, since if it wasn't for DRM wanting control of the whole reception to display path to be protected, you could just stick an open computing device in between the streaming signal and the display device, and make your own technical choices.
You still can, AFAIK, for content that doesn't require HDCP.
Cable: no, you'd need a CableCard, and approved device (i.e. DVR), etc.
It's because we have a trendy now-decades-long wave of product managers and designers who assume their job is to know better than the user.
Open source software is not immune.
cough systemd cough
Do you mean Unix-like? I'm not sure what you mean by "open" in this instance, but Unix definitely was not very open, leading to nascent platforms and movements such as GNU and Free/Libre software.
I recall reading about TVs with multiple tuners to resolve adjacent channels when flipping, but I don't remember if they actually made it to market.
Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".
But they still have these scenes in movies
The way these scenes work now is "picks up phone - check the news!", they grab the remote, and turn the volume up on one of the many already running and tuned in wall-mounted 24/7 on TVs ... :)
Yes, and if such a TV turns on instantly, that scene is not realistic.
(I think if the were going for realism today, they'd say "pull up reddit/Drudge/google news".)
Yet does it use any of those extra decoders when not recording to proactively decode the previous and next channel, or something smart like that? No, of course not...
The incoming channel data stream is saved as-is. It will need a demultiplexer to separate out one channel from the multi-channel data stream, but it won't need to decode that stream, which is the intensive bit. Decoding happens when you play it back later.
Mental slip then. Thanks for the correction, very interesting.
Do you find yourself actually moving up and down the channels, and not through the guide to somewhere else entirely different than where you once where? My first move if I'm switching channels is to go to the guide, not to a channel one above or below my current channel.
I suppose it could run on the previous channel, but it certainly can't guess my next channel.
Toxic culture and relationships so the startup imploded, but there was some cool tech.
The real reason problems like this aren't solved is that the organization does not allocate resources to fix them. The status quo has been deemed to be good enough and not leading to the loss of too many customers to the competition, so that's where it stands. This pervades all engineering -- everything just barely works, because once it barely works, for most things, it's good enough, and no more resources are deployed to make it better.
Many people wouldn't even be able to reliably tell the difference with common dpi's and viewing distances.
What does make a difference? Surround sound. I'd take 5.1 or up with DVD-quality picture over 4K with stereo any day, no hesitation.
> you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.
GOP length / I-frame interval directly relates to bitrate. Longer GOPs generally result in a lower bitrate at similar quality; in DVDs or Blu-rays I believe the GOPs can be quite long (10+ seconds) to achieve optimum quality for the given storage space.
Non-predictive video codecs are usually pretty poor quality for a reasonable bitrate (like a bunch of weird 90s / early 00s Internet video codecs), or near-losless quality but poor compression (because they're meant as an intermediate codec).
My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Bandwidth matters because spectrum is a finite commons. Digital TV required giving up bands that were in use for other things (e.g. wireless microphone systems and some ham bands) as it is, using even more bandwidth would have required even more spectrum. Other people have stakes in the spectrum for very good reasons and often much more important reasons than "I wanna watch TV". Even for satellite TV, which uses frequencies high enough that there is lots of bandwidth is limited, because using a lot of bandwidth would require new LNBs and multiswitches for all customers.
> My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Can you name one for each category you bring up? Especially the "engineering" one would be interesting. Obviously dedicating an even huger chunk of spectrum to "I wanna watch TV" would make things easier, so that's not really interesting. And "let's just give each customer a TVoIP stream that can start immediately" is also a pretty obvious "money is no concern" (and also "we don't care about customer adoption costs") option.
We agree that there a whole series of parameters that can be traded off against each other: 1. Bandwidth required
2. Number of channels
3. CODEC complexity/engineering effort/cost for encoders and decoders
4. Iframe interval
5. Number of tuners/decoders in receiving equipment
6. Resolution
7. Frame rate
8. Video quality
So the standardization people decide how to set those, and basically channel switch time gets set to the maximum value that doesn't cause people to cancel their service.
If you want to see something pretty astonishing that can happen if you set the tradeoffs differently, check this out: https://puffer.stanford.edu/player/
Users want to change channels quickly? Okay, let's decompose a problem into what they really want to do, then make N "preview of i-j" channels in 720p with channel pictures in e.g. 8x5 grid and show numbers so that a user could just dial them on a remote. After finding an interesting preview, it's not an issue to push some buttons and wait a couple of seconds to get 2160p or whatever quality there is. Didn't like it? "99<n>", "ok", repeat. This solution would be a jquery of tv world, dumb, straightforward, non-automated, but it would be a thousand (fourty to be honest) times better than nothing.
When I had an hd tv set, I just checked 3-5 channel numbers that I remembered and turned tv off if there was nothing of interest, because you could easily spend half an hour by just peeking them one by one.
It's all based on ATSC. While there is an ATSC 2.0, they skipped that in Canada, there will be ATSC 3.0, which will use HEVC (H265) for 4K. But don't hold your breath on that...the TV stations aren't exactly opening their wallets to upgrade anything!
Right now I would be satifsied with at least some caching of the menus, so it doesn't have to pull the data every damn time I scroll up or down. Come on, it should be able to remember what channels I have for more than 5 minutes in a row.
You didn't think a cable company was going to deal with it's customers fairly, did you?
Every time you interact with a customer, there is an opportunity for profit. Telecommunications companies, cable TV included, are masters at this type of behavior.
You get the cable box for the new system BEFORE they switch the old system off, or else you wouldn't have service until you got a new box. That's why you saw behavior change with the new box.
It simply isn't possible to send all the channels to customers at all times. There isn't enough bandwidth. So, the cable box at your house negotiates with the central or regional system so only a subset of channels are sent to you. There is no other way to do it in digital cable systems, and the switch to digital was made because it uses significantly less bandwidth than analog.
Just because they transmit keyframes and deltas in the steady state doesn't mean they need to wait for the next keyframe when starting the stream. They could also choose to send you the current reconstructed frame as a keyframe immediately instead of waiting several seconds for the next pre-made one. The cost to them would be epsilon (one new stream client per channel to be the source of reconstructed keyframes), and the customer experience difference would be noteworthy.
At worst it would only be as bad as a transcoded stream for the first few seconds until the subsequent true keyframe arrives. That's loads better than no stream at all.
An MPEG transport stream is sent over that 40Mbps "channel". Inside of that transport stream are several elementary streams, each carrying either video, audio, or data/program information. A TV station will be carried by a combination of a video (MPEG-2/4) and audio stream. These streams are packetized such that a receiver won't get buffer underruns or overruns. The transport stream is further packetized. Adjacent station broadcasts aren't always carried on the same transport stream.
So when you hit the button to "change channels" the cable box may need to tune to a new radio channel, wait for transport stream packets for the station, and then buffer enough data to start playback.
The GOP size then plays a part because the decoder needs an I-frame to do anything useful with the P-frames inside the GOP. Cable providers use longer GOPs to get better quality at a given bitrate, I-frames are much larger than P-frames so the more you send the higher the bitrate you need.
Sending I-frames for other broadcasts in the same transport stream would be a waste of bandwidth. The data used for these rarely used extra I-frames takes away from bandwidth programming in the stream could use. There's also still the lag from tuning a new channel and waiting for those I-frames to show up. So you've wasted bandwidth for a very slight increase in responsiveness.
Cable systems don't often re-encode streams they receive from upstream sources. The video from upstream is already compressed so the elementary streams are remuxed into the cable system's channel plan. The cable head end doesn't receive raw video and encode it in real-time. Even local OTA stations just get remuxed rather than re-encoded.
Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end in case someone flips a channel. Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
Even IPTV isn't a bidirectional signal. It uses IP multicast and the tuners just change their multicast address to change stations. The stream is the same MPEG transport stream as the QAM signal but sent as IP packets. The head end still doesn't decode every station to send bespoke I-frames in the event someone flips the channel.
This hasn't been true in many places since the takeover of digital cable in the 2000s. Without a bidirectional data link, how do you think cable internet works? Or cable telephony? Or pay-per-view for that matter? It's all on the same line into the same box.
> Cable systems don't...
Don't isn't couldn't. When talking about solutions to problems, merely describing a problem isn't where the conversation ends.
> Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end
That's what I described. The cost of doing it is epsilon.
> Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
If you can stream Netflix while watching TV without hurting your neighbors, then you can receive one single I-frame.
There is no technical reason you can't have instant channel switches, it's just that they aren't making the right technical decisions to allow it and/or don't want to pay for it.
[0] https://puffer.stanford.edu
Originally POTS was circuit switched analog connection between you and the other party --- only delays from the wires, and maybe amplifiers. Nowadays POTS is most likely digitally sampled at the telco side, but each sample is sent individually --- there's no delay to get a large enough buffer to send, because for multiplexed lines each individual line is sampled at the same rate and a frame has one sample from each.
Then try various things like saying “ping”. The results are quite amusing. Or put one phone on speaker.
The astonishing thing is that bandwidth isn't a big deal now, and we could have improved basically all aspects of mobile calls to be within spitting distance of what we used to have 30 years ago.
No wonder people don't like to talk on the phone any more.
Isn't that a little like saying "The only thing boats have over cars is that they can go on water. In all other ways they suck"? Portability is the entire point. Even in the "good old days" most people would have accepted nearly any tradeoff for the ability to carry even the simplest global communications device with them.
Particularly in Enterprise software, the time to complete a workflow or view specific data matters a lot - the time to load a page is a component of that, but customers will gladly trade latency for a faster e2e experience with less manual error checking.
In consumer the big limiting factor is engagement, a low-latency experience will enhance engagement. However it's possible to hide latency in ways that weren't possible before such as infinite scrolls and early loading of assets. The engagement on the 50th social feed result has less to do with the latency to load the result, and more to do with how engaging the content is.
Of course software now uses more computing resources, so that’s not doing more with less. But the computer is cheap. What’s expensive is the humans who program the computer. Their time is expensive, and getting experienced, expert humans is even more expensive.
So we now have websites that have rich features bolted together using frameworks. Same for desktop software, embedded systems, and whatever else. They’re optimized for developer time and features, not for load time because that’s not expensive, at least not in comparison.
As a user the only solution I see to this is to use old fashioned dumb products rather than cheaply developed “smart” ones. For instance I’m not going near a smart light switch, or a smart lawn sprinkler controller. Old dumb ones are cheap and easy and fast and predictable.
This is a nice half-truth we tell ourselves, but that's not the full story.
There exists plenty of optimizations where the programmer-time would be smaller than the additional hardware cost. And those losses compound. But they're a little too hard to track, and cause is a little too far divorced from effect.
I did our first ever perf pass on an embedded application as we started getting resource constrained. I knocked 25% off the top in a week. Even if I had spent man-months for a 10% savings, try and tell me that's more expensive than spinning new boards.
That's not to say we're opposed to hardware changes; we do them all the time. But the cost curve is weighted towards the front so it's more attractive to spend a non-zero amount of developer time right now to investigate if this other looming spend is avoidable. That's not the case when you're looking at controlling the acceleration of an AWS bill that spreads your spend out month to month through eternity.
Who wants to spend a big chunk of money up front to figure out if you can change that spend rate trend by a tiny percentage? Even if you do, and get a perf gain, but someone else on the team ships a perf loss? Then it doesn't feel real, and you can only see what you spent. Even if you have good data about the effect of both changes (which you don't), the fact the gain was offset means the sense of effect is diminished.
And rather than investigate perf, people can always lie to themselves that the cost is all about needing to "scale." That way they convince themselves not only was there nothing they could have done, the cost is a sign that their company is hot shit.
If you don't think that kind of perf difference is real, Look at Maciej's comparison of pinboard and anonymized-del.icio.us https://idlewords.com/talks/website_obesity.htm (ctrl-f "ACME")
And if perf has any impact on sales, cause and effect are even further apart. You might be able to measure the effect perf has on your sales website directly, but if that feedback loop involves a user developing an opinion over days/weeks? Forget about knowing. Oh, sure they'll complain, but there are no metrics, so we get the rationalizations we see in this thread.
At least car crashes are still low latency.
Is this an android problem? I don't really ever have to close apps unless the app itself gets stuck into a broken state and forcing close to restart can correct the issue.
I suspect that the root cause is that nobody understands what's going on from the UI down to the hardware, and nobody is incentivized (or even allowed) to spend the time it would take to actually do so.
I think about this every time I use the Hulu "Guide" on my Fire TV. It's extremely slow and cumbersome.
I remember using the early digital cable boxes in like 2005 which were much more responsive, and honestly, the UI was much better too.
Remember when turning a TV on was <0.5s?
My current dumb TV takes a good while to turn on. When I press the power button, it takes about 1s for the indicator light to change than another 2 or 3 to begin displaying anything.
No, actually. Most CRTs took a long time to come on. Early LCDs, maybe?
Still, I remember never having confusion about whether my CRT TVs where responding to the power on button press or not. There are plenty of times where I turn my current TV off since I think it didn't receive the first button press.
Now, quite often I have to wait 5s to see whether the button push was registered, push again because the TV still does nothing, and then watch as the thing turned on just as I was pressing and interprets the second push as a signal to go on standby (5 more seconds with an obnoxious message about it going to sleep, and yet 5 more to wake it up). It’s like the USB-A that needs to be rotated twice every time you want to plug something.
One of the worst parts of the over the air digital switch over was how much harder it was to channel surf quickly.
Phones used to be rotary dial but then touch tone phones with number buttons were introduced. I was reading an article about human brains and its expectations. Going from a touch tone phone to an old rotary style phone seems excruciatingly slow to our brains. Depending on the number a 1 on each it's very close in duration but a 9 or a 0 on a rotary compared to a touch tone 9 or 0 seems glacial in speed.
> Remember when channel changes on TVs were instantaneous?
There's nothing less satisfying than smushing down those rubbery remote control buttons for an extra 2000 to 4000 milliseconds to change the channel.
Don't get me started on entering the wrong channel numbers. That gives me PTSD.
The cynical side of my brain feels that this is exactly what TV stations and show producers wanted. If it's fast and easy to spin the dial and maybe stop on a competitor (and more importantly, watch their ads instead of yours) then you have to put our quality product and not annoy the customer with as many loud and irritating ads, which means that you don't make as much money from the content that bookends your ads.
These things are like these fake volume controls reddit made up.
Someone had to more or less decide to handle it that way for some reason. So I am skeptical that "it's just the nature of progress."
Not really. It's just not a priority.
The purpose of technology (in the POSIWID sense) is to concentrate wealth.
https://www.wnycstudios.org/podcasts/otm/segments/self-drivi...
Of course cars do take up a lot of space, but even factoring that in you have more choices in a reasonable time with a car than without.
Don't read this as me approving of cars. I understand the appeal and drive, but I hate it.
HDCP obviously being consumer-hostile, but the others are decent features to make things "just work".
As for the rest: Resolution negotiation is optional and wouldn't matter if the device is already outputting at some resolution, also this happens on different pins, so even if the device would first query the EDID of the TV to figure out what mode it prefers, the TV could meanwhile already display whatever the device is outputting. Same with CEC, this is another protocol on different pins than where the picture data is sent. HDMI really is just DVI with some extras, at least for the older versions.
I don't even think most phone apps are bloated, because most phone apps - and web sites - are just electronic forms decorated with a bit of eye candy.
Security and reliability worry me far more. Many sites have obvious bugs in $favourite_browser, and some just don't work at all. Some of this is down to ad blocking, but that shouldn't be a problem - and the flip side is that blocking ads, trackers, and unwanted cookies seems to do wonders for page load speeds.
Modern computers should be much faster, but they aren't. They do more, but when you do something you notice the slow speed.
Related: https://www.youtube.com/watch?v=kZRE7HIO3vk
I'm not expert enough to say if his technical solutions are correct, but it's a pretty good explication of the problem.
[1] https://unix.stackexchange.com/questions/223746/why-is-the-l...
No, not with technology as a whole. With software ...
I personally believe we should start having "bootcamps" which talk about optimizations, and the cost of stupid designs. I'm also looking forward to compile time and run-time optimizations so that we don't even have to rely on the developers for it.
Can someone from Flexitive.com please call up my marketing coworkers and tell them that they aren’t supposed to use that tool for actual production code?
Can someone also call up my VP and tell them they are causing huge performance issues by implementing some brief text and an image with iframes?
Can someone fire all of the project managers involved in this for pushing me towards this solution because of the looming deadline?
People don't care about speed or beauty or anything else than the application helping them achieve their goals. If they can do more with current tech than they could with tech 10-20 years ago, they're happy.
Every statically backed research on customer behaviour I have ever seen says otherwise. The more you slow down the page or app the less customers like and use it or buy the product being sold. As someone with a homemade site for our business I can say that it is extremely easy to be faster than 95% of sites out there and it makes a huge difference, also on Google. Tiny business with homemade website in top 1-3 on Google was mindbaffling easy because everyone use too many external sources and preschool level code. Especially the so-called experts. Most are experts in bloat.
If you're Google, Facebook, Oracle, etc, nobody cares. They just endure it to get what they really want.
All I needed to do was spend a weekend scraping everything I needed so that I could self host it and avoid all the ridiculous network/cpu/ram bloat from browsing the "mainstream" web
Even with all of this extra work and indirection, loading and navigating pages through the proxy is still much faster than accessing the site directly.
https://en.wikipedia.org/wiki/Wirth%27s_law
https://news.ycombinator.com/item?id=24031955
Those animations are absolutely a product of well researched UX design, it's just design that's intended to make the UI more accessible by showing users the flow of information and how the structure of the interface changes in a visual manner, rather then design intended to address the needs of power users. The animations used in the Spaces feature on MacOS is a good example of that, where apps and desktops slide and zoom around to make it absolutely obvious that the apps you have open haven't just disappeared. That's quite important for a fairly advanced desktop manipulation feature like that.
Modern operating systems are designed for broad audiences, and that includes people who aren't as savvy with technology as we are. That means accepting some level of tradeoffs between the speed that pro users want, and UI accessibility that necessitates slowing things down somewhat. In the case of desktop OS's there's still usually ways for power users to disable that stuff and of course Terminal for those who don't really need a UI at all. And then there's a lot of different flavors of Linux that make no attempt at appealing to a less technical audience.
But just because you're not the target audience doesn't mean the UX team are "idiots" or that the companies are "stupid". The amount of novice or casual users is orders of magnitude higher then power users who care only about efficiency, and for better or worse those users always come first.
Locating the window I'm looking for takes longer than the animation and I can start looking immediately during the fade. Even with the ctrl+number shortcuts, I can't get my hands back onto the home row before the animation finishes.
Web sites and apps are sidled with advertising content and data collection code; these things often get priority over actual site content. They use bandwidth and computing resources, in effect slowing everything down. Arguably, that's the price we pay for "free internet"?
Finally (and some others have mentioned this), the software development practices are partially to blame. The younger generation of devs were taught to throw resources at problems, that dev time is the bottleneck and not cpu or memory -- and it shows. And that's those with some formal education; many devs are self-taught, and the artifacts of their learning manifest in the code they wrote. This particularly in the JS community, which seems hellbent on reinventing the wheel instead of standing on the shoulders of giants.
In spite of an increase in mobile CPU speed, mobile phone startup time have not improved (in fact they became slower).
In spite of an increase in desktop CPU speed, time taken to open AAA games have not improved.
In spite of an increase in elevator speed, time taken to reach the median floor of an building have not improved.
My point is, "webpage" has evolved the same way as mobile phones, AAA games and buildings - it has more content and features compared to 10 years ago. And there is really no reason or need to making it faster than it is right now (2-3 seconds is a comfortable waiting time for most people).
To put things in perspective:
Time taken to do a bank transfer is now 2-3 seconds of bank website load and a few clicks (still much to improve on) instead of physically visiting a branch / ATM.
Time taken to start editing a word document is now 2-3 seconds of Google Drive load instead of hours of MS Office Word installation.
Time taken to start a video conference is now 2-3 seconds of Zoom/Teams load instead of minutes of Skype installation.
People use and will continue using Skype and especially MS Office. It is much more functional that gSuite alternatives and moving people to castrated and slow webapps is not progress.
I will continue to use, and improve on those "slow web apps".
What features? I don't know anything substantive a site can deliver to me today that it was not capable of 10 years ago. The last major advance in functionality was probably AJAX, but that doesn't inherently require huge slowdowns and was around more than 10 years ago.
The rest of your comparisons are dubious:
>Time taken to do a bank transfer is now 2-3 seconds of bank website load and a few clicks (still much to improve on) instead of physically visiting a branch / ATM.
This is the same class of argument as saying that (per Scott Adams), "yeah 40 mph may seems like a bad top speed for a sports car, but you have to compare it hopping". (Or the sports cars of 1910). Yes, bank sites are faster than going to ATM. Are they faster than bank sites 20 years ago? Not in my experience.
>Time taken to start editing a word document is now 2-3 seconds of Google Drive load instead of hours of MS Office Word installation.
Also not comparable: you pay the installation MS Word time-cost once, and then all future ones are near instant. (Also applies to your Skype installation example.)
And.... Hacker News just in time for the rescue:
https://news.ycombinator.com/item?id=24054382
Just today morning, when I opened my browser profile with Atlassian tabs (Atlassian needs to be contained in its own profile), there were perhaps 7 or 8 tabs, which were loaded, because they are pinned. It took approximately 15-20s of this Core i7 7th Gen, under 100% CPU usage of all cores at the same time to render all of those tabs. Such a thing used to be unthinkable. Only in current times we put up with such state of affairs.
As a result I had Bitbucket show me a repository page, Jira showing me a task list, and a couple of wiki pages, which render something alike markdown. Wow, what an utter waste of computing time and energy for such simple outcome. In my own wiki, which covers more or less the same amount of actually used features, that stuff would have been rendered within 1-2s and with no real CPU usage at all.
Perhaps this is an outcome of pushing more and more functionality into frontend client-side JS, instead of rendering templates on the server-side. As a business customer, why would I be entitled to any computation time on their servers and a good user experience?
On some cheap hosters it may take a second just to startup the server instance, that's before any of the outgoing requests are done!