Which should tell you something. The vast majority of tech advancements are because of hardware, not software. I think that software people should feel a bit of shame at this point in time.
No one feels any shame because the reason is obvious. Normal users are constantly demanding more features and not more speed. The average person just buys a new phone when things are slow. Companies don't have infinite time so when faced with the option between adding a new feature and speeding up an old one they always pick the new feature because thats worth more.
Now imagine if the people working on the lower level stuff had the same attitude. Imagine if the codec implementations were slow because we need more features. Imagine if the graphics people never gave a damn about perf, just like the "programmers" you're talking about. Imagine if your database was the main perf hog in your system etc. etc. I'm sorry, but here's an unpopular opinion: those people are just not good engineers. The increments of software development should be abstractions, not features.
Yes. It's the Jevons' paradox enabled and amplified by the corporate web abusing JavaScript (bloat, ads, trackers, and other attention-grabbing shenanigans).
You'd be able to boot an x86 emulator in JavaScript to a Groovy prompt in just a few seconds, so probably faster than you can load any major news site except text.npr.org ;)
edit: Just poked around a bit to find best worst examples. Unsurprisingly CNN is the worst I could find after a few mins - https://tools.pingdom.com/#5d1bf596ffc00000 543(!) requests, 9mb, 6 seconds. Just stroll through the list of bullshit it sucks into the front page...what a mess.
Also holy shit I just clicked on the first website I saw on that site and I'm getting about 3fps scrolling it and my desktop is a Ryzen 9 3900x with 24 threads, 48gb ram and an rx5700xt. You don't even get the excuse of "It works on my machine" because this desktop is literally as good as it gets. I just tried a couple sites and not a single one could scroll smoothly, one of them was live applying css transforms to about 30 images as I scroll.
They're nice and smooth on my Ryzen 5 4500U/Vega 6 with 8GB of RAM. Of course the 5 seconds of artsy chaos spinner each of them has on load is still absurd. But it's fine after that. Could it be the browser? I loaded them in Firefox.
The reddit API is a legacy feature that is on the chopping block any day now. Its only real purpose now is 3rd party clients which don't show adverts or insert tracking scripts. It has a small amount of use for bots but those are mostly a negative user experience and likely to be killed soon as well.
Reddit is pushing to become facebook without your real name.
This seems very likely. Reddit admins have mentioned that they are trying to crack down on alt accounts and banned users signing up 2 seconds after being banned. A phone number requirement would solve that easily.
Ha ha, now we're back to secret incantations like when AdBlock first came out! You'd tell your friends and family, "Oh, you gotta get it!" for something whose "discoverability" is very, very low.
Would love a CPU usage analysis of new reddit vs old reddit. You can feel your laptop choke under the effort it takes to render the post + 3 comments out of 200 it shows you vs the old loading the post and entire comment tree.
It genuinely feels like being on dial-up in the old days. I frequently visit reddit using Safari on my iPad and it often takes a good 3-5 seconds for the new page to load after I tap on a link. If anything, it at least dissuades me from wasting time on the site.
Trying to open new.reddit.com on my ~4 year old phone is slow enough that I have time to get a coffee before the annoying Install Our App popup appears.
Imgur is even worse; it takes multiple seconds to load a webpage whose only purpose is to display a single jpg image.
yeah, I've navigated there several times by accident on my phone while out and about. I never got past the loading screen. at least now you can just go to old.reddit.com and don't have to request the desktop site every time
New reddit vs Old reddit would be an interesting experiment. What if reddit asked you which version you want on your first load? How many people would go for new?
This is one reason I created Trim [0]. I didn’t want to have to load 4-7 MB of stuff to read a stupid article. It often reduces an article page weight by 99% and uses no JavaScript.
Similar, different in design and execution. As far as I know, Outline processes the article in browser using JavaScript. Trim uses no JavaScript but instead does the processing server-side. The response of the form post is the article.
This is one of the main reasons why I do 90% of my web browsing in emacs-w3m, which does not support Javascript.
Avoiding Javascript not only lets me avoid all that bloat and slowdown, but also avoid Javascript-based tracking, malware, and exposing myself to Javascript vulnerabilities.
I also have the power of the entire Emacs ecosystem at my fingertips when I surf the web this way, which can be very helpful in many ways.
Unfortunately, some sites I find essential will not work without Javascript, and for them I go back to Firefox.
In Firefox, I use uMatrix and uBlock Origin to only allow through the minimal amount of stuff that'll let the web page work, and filter out ads.
I have a really old, slow laptop, so web browsing is slow for me, but not nearly as slow as it would be if I consented to swallow all the crap that the modern web tries to force down my throat.
I yearn for the good old days without Javascript or Webassembly. There was Flash back in those days, but fortunately not a single serious site I ever visited required it, so I could avoid every Flash-using site like the plague. But today the Javascript plague is unavoidable.
I started using w3m primarily a few weeks ago. It’s been awesome for actually grabbing the information I need and not getting sucked into attention sinks.
uMatrix not only allows you to block JS on a site you're visiting, but gives you fine-grained control over blocking JS from sites that site calls out to, and subdomains of that site as well.
I find uMatrix much more flexible than uBO in this regard. I don't even know if doing all this is possible in uBO, and suspect it's not, or that at least it's hidden away pretty well, while this is front and center in uMatrix's interface.
You can do some of that with uBO (see "hard" blocking mode), but my understanding is that uMatrix gives you more granular control. I need to learn more about using uMatrix to confirm, though.
Only applies "to regions in which the vast majority of peak-hour commuting is done on rapid transit systems with separate rights of way" according to your link. I think that's an important qualification.
I've always had a question about this. If more people are deciding to use the road afterwards surely it means that trips are being taken that weren't before? Wouldn't that be a good thing, economically speaking?
> Wouldn't that be a good thing, economically speaking?
Yes, because it means people can live in places they couldn't before, or could get to jobs they couldn't before. Of course, people who already used the road won't perceive these benefits; they are in the same situation as before.
That description fits Braess's paradox https://en.wikipedia.org/wiki/Braess%27s_paradox more than the Downs-Thomson paradox. The latter is more about public transport being the dominating factor in congestion whereas the former is about adding roads in itself sometimes causing traffic to get worse.
In either case it's often overstated, expanding the road network (especially intelligently) usually results in less congestion. It's just a poor investment compared to other means of transportation investment in large cities.
If "adding capacity to existing lanes" was your intended wording it absolutely can - widening a lane, simplifying lane markings, restricting turns in/out of a lane, and more can be done to increase the efficiency of a lane.
If you meant adding capacity to existing roads (by adding lanes) it certainly can drop congestion as well. Expanding roads blindly CAN also make congestion worse but that's a possible outcome not a guarantee.
The point of the original "paradox" is that if you want the least amount of road congestion by private vehicles the best investment is to grow public transport but many places dump more money into roads and lower the percentage of users using public transport because "roads are where the congestion is". Hence the paradox, increasing road spending increases road congestion (in places with existing public transport).
The point of the second paradox is there exist ways to add more paths to a network that result in less flow than the network had before regardless of other conditions like public transport being available. The paradox is NOT that adding additional capacity to a network ALWAYS or NORMALLY results in less flow. In fact most of the time it does help flow (marginally) it's just a poor investment compared to the same amount spent on public transport.
That's certainly a useful concept, but I don't think it has anything to do with internet speeds here.
The page speeds that either have or have not gotten slower are generally understood to be purely a phenomenon of larger/bloated pages -- not a result of constricted internet "pipes".
If the paradox applied to the internet, then what you'd be seeing is that if pages loaded twice as fast, people would visit twice as many pages. But that's not at all how it works.
> If the paradox applied to the internet, then what you'd be seeing is that if pages loaded twice as fast, people would visit twice as many pages.
It is in fact a similar phenomenon. The cars are the bytes that developers are stuffing into what they build. It's not people visiting twice as many pages, it's developers continuously expanding the size of what they can stuff into sites to fill the capabilities of servers, end user systems and bandwidth today.
Some of it is unnecessary byte expansion because they can get away with it. The Web was very slow when everyone was on a 56k modem as well. The network pipes were smaller, the servers were drastically weaker, the consumer systems were weaker, everything was obnoxiously slow. It sucked to wait five to ten seconds or more to load a very simple website in 1996. It sucked to watch little real media files and wait a long time to load a couple mb file.
Developers are expanding their byte footprint to fill the available limits of patience, and often going over that line, exactly as they always will.
It’s important to make a distinction between webapps and websites here. We use the web now like we used desktop in the 90’s and 00’s.
For most users, your browser is your OS. Hell even when it isn’t, most desktop apps use HTML+CSS for their UI. Hell even many user-facing “embedded” apps (like TVs) are running linux with chrome and showing a webapp as their UI.
The layout engine is just that good and convenient. And downloading fresh app source on every visit solves a lot of problems.
This part of the web is getting bloated and slow.
On the other hand are websites. These are fat as heck thanks to CDN and broadband and advances in server compute power. They load faster than ever.
Remember when downloading memes required eMule? I do.
Now I go to imgur and watch 30MB high def gifs like it’s nothing. My 13 year old self would shit his pants in awe.
Are ads and trackers bloating websites? Yes. Are most websites built like webapps even when there’s no need? Yes.
Blame tooling. Go help. What can we as a profession do to make it easier for random developers with no skill build faster better websites?
Right now we’re actively telling everyone they need to build as if they’re FAANG. Then we complain when a part time dev working for a mom&pop shop can’t wrangle all this tooling built for teams of 1000’s into a solid experience.
This might be an opportune time to mention my attempt at helping. I made barleytea.js [1] as a light framework alternative to React that needs no webpack. I also recommend much more polished, production-ready things like µce [2] and heresy [3].
Anyway I just want people to know that there are lightweight alternatives out there, and they're worth at least checking out.
I've stayed with Angular v1 for a long time[0] due to it's simpler nature (no compiler, simply JS); but since that is going EOL I'm definitely going to look into Barleytea.
Just like most things, the answer is "it depends" since it's really not that simple. This is a great article but the answer seems obvious to me.
The web today is starting to get divided into apps and sites. HN is a site for example. It is small, loads fast etc and works well for it's intended use case.
When I listen to music or podcasts in a web site, I want it to act like an app and for that to happen more stuff has to happen in the client. Thus leading to a longer load time and execution time. This is something I can live with though, since I can do stuff on the web that was impossible just a few years ago. I am also developing apps that was impossible to do on the web a few years ago.
I want to use both sites like looking up that store and order some stuff and apps like doing design or consuming music and video.
I prefer web apps that are done well rather than native apps. I don't have to download anything and they are free from the shackles of Apple, Google and Microsoft. Also, you don't have to make them bloated and big. You don't have to use a framework. You can use web components and maybe some small router library and you have the most important stuff a front end framework gives you.
Just check fastmail, their client is super fast and is a very well done SPA app. Then you can look at Reddit, which is a horrible mess. Like any app, any language you can make the experience shitty and you can make it awesome.
No, it's faster. Disable JS and - what continues to work, which is quite a bit - is snappy. It's also snappier than it was a decade ago, even 3 years ago, very clearly so.
But while people will accept JS and general online abuse, it will get worse.
I have the feeling that most of modern websites use too many cpu&gpu resources. My computer is just 5 years old and each time I visit a modern website my computer really suffers.
Please designers and engineers, I don't own the last macbook pro with maxed out specs and my internet connection is quite normal.
Start creating for the rest of us who don't have the resources or interest in upgrading the computer every couple of years!
It's not just web pages, modern software engineers just make terribly unoptimised programs. Why does a recent game on a powerful pc take longer to open that old DOS games? Not just loading a level, but even getting to the start screen takes ages. Wtf takes 20+ seconds to show a menu of New - Load - Options.... (drm probably)
I do own the latest MacBook Pro and have a mesh network with 300 Mbps downloads speeds and even I have started finding it painfully slow to load my banking website, cnn, etc. In particular layout shift has become awful and I often click on the wrong link as the page is still loading and widgets are being rearranged on the page.
Yes, demonstrably and provably. Count the number of pageload indicators (spinners, throbbers...whatever you like to call them) in your daily browsing. They are everywhere...now.
AJAX (and, I suspect, the shadown DOM model) have proliferated in recent years, and there is no site design simple enough that someone hasn't thought to put every page element behind a JS call. Don't forget to put CSS in there, too!
Frontend developers are at fault for all this. There, I said it.
It's a culture problem in the web dev world. There is an obsession with new and shiny and building something "cool". It's all about the developer experience and not the product.
That's why there's such insane churn in the tooling and ecosystem. People rewrite and redesign constantly in order to work with the new cool framework.
Insane churn? Wordpress powers over 1/3 of the web. JQuery is still doing most heavy JS lifting on most blogs/CMS-driven sites.
React has dominated "real" frontend webapp development for a solid 5 years.
These things don't make headlines or get retweeted. The web produces a lot of variety because it has the widest distribution and the lowest barriers to entry.
Not sure what you mean. You're welcome to hand-write all of your web apps from the ground up with zero dependencies and no build system. It's still the web.
This gets parroted a lot around here but the last 5 years or so there's really only been a few major players in the framework space. Maybe the "framework of the day" mentality was pretty strong in the early 2010's but things have cooled off significantly since then and you'd be hard-pressed to find most shops using more than the big 3-4 contenders.
My experience is that it's just as relevant today.
I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS.
People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.
It's a combination of arrogance, lack of skill and sheer stupidity. For an example, look at nuxtjs docs, there is an example config, that everyone seem to use, that lints on each build. Because code using 4 spaces indentation is slower than code using 2 spaces...
The last ui dev I had to work with managed to produce in about 1 year a very complicated dockerfile, that was spewing, between other things, an image for e2e testing - but no actual tests and you needed a huge makefile to actually build the thing, a soup of copy-pasted config files that resulted in a vendors.js bundle of about 100 megs - there were more config files than source code, 2 branches named <username>.wip.somedate with commits that commented out some parts of a config, just to uncomment them back in the next commit. The app itself, with ssr no less, was a logo and some text, that was using some custom components, built with some third party vue component that was rendering css in js, thus you had to wait for the entire vendors.js to download before you got anything rendered. His answer to anyone questioning his choices was "this is how modern ux development works".
After he was let go, I took over the ui and along with another coworker we managed to have a working version of the app in 9 days, with no prior knowledge of vuejs and nuxtjs. You can imagine how complicated the app is...
I find this universally true in every corner of the stack and it has more to do with experience than anything else. It’s hardly “all front enders do this always.”
Still, to my point, the tools mentioned here have existed for a very long time with very large communities and are hardly the new shiny thing. Your complaint here seems to be more around using the wrong tool for the job.
I don't disagree, but it's particularly bad on the frontend.
This particular frontend person had convinced the owner of the company that there were things you could do in SCSS that you couldn't do in CSS. I had to explain to said owner that SCSS was compiled down to CSS because the browser didn't understand SCSS. That you literally couldn't do anything in SCSS that wasn't allowed in CSS.
The owner ended up having a come to jesus moment when he tried to take all of the tools that frontend developer added and make them available in docker so that no one else had to install custom development tools. He spent several days, failed on it, and realized exactly why I was being so hardheaded about the build chain.
We never ended up getting rid of those dependencies, but I know the owner finally understood my point. Instead the team bifurcated into those who had their local environment setup to be able to successfully work on the frontend, and those who didn't.
> Frontend developers are at fault for all this. There, I said it.
Let me trade one dead horse for another: Product and marketing teams are at fault for all this. Or if you prefer, the advertising industry is at fault.
Take the payload of any typical blog or (God help you) your small-town newspaper website and count how many requests correspond to the actual content. Now ask yourself, who's paying someone to bloat this website, and why?
Eh. If one wants to play the blame game, we can be here all day. The marketing dept asking to add sharing widgets are to blame. The team lead pushing for Squarespace so they can get away hiring junior devs under them is to blame. The frontend dev using half of the React ecosystem on a static site + simple form is to blame. The designer insisting on huge eye candy images is to blame. The UX person set on adding a carousel is to blame. The project manager prioritizing feature count is to blame. Etc etc etc.
The bottom line is that nobody really has any strong incentives to advocate for performance, so it falls by the sidelines.
I don't think there's really a problem with a couple 100ms of latency for web services. However, what often happens, is that "modern" websites take many seconds to actually do simple operations which is clearly horrible design.
I literally despise new UX of gmail, Ive switched to html version simply because I dont need the bloat crap they try to push at me while checking mailbox...
Yet they keep on adding more and more crap, soon Gmail is going to load for over a minute..
> The frontend dev using half of the React ecosystem on a static site + simple form is to blame.
I once saw a website that took a full minute to load, and it was literally a page with images, text overflowing around it, and then some download links. But the way it was built... my god, the way it was built.
That company brought in a new "CTO", and his solution was to dump the entire thing in google cloud. I shit you not, this CTO initially installed an EOL version of PHP, and when errors started happening, he started submitting PR's to revert the PHP code to be compatible with the EOL version of PHP.
His explanation is that's what google cloud defaulted too, although I have a really hard time believing that.
I'm more inclined to believe he googled and blindly followed an old guide with an old ppa than I am to believe that google cloud by default installed an EOL PHP server.
I'm pretty sure he was a node guy who found himself in the PHP world.
Raise you Automotive. Store sites are the worst. The industry reason: it's all about tracking conversions and answering the question of how much did it cost me to sell this.
I didn’t touch “web dev” since php/dream-weaver/myspace era.
I started working with some web developers for a simple project recently, my mock product was built with vue.js using the standard way of “including” it: But what really threw me for a loop was that the web developers told me that that’s wrong, they are now _compiling_ (Or, semantically “packing”) JavaScript blobs to make even very simple websites.
I don’t know why we as a community have started doing that, but it feels like an anti-pattern, it makes adding new dependencies opaque and we can very quickly end up including dozens and dozens of lines of code which must all be rendered by every device that comes into contact with my site.
Often this happens because we want only a small bit of the functionality too.
> Often this happens because we want only a small bit of the functionality too.
To be fair, this 'compiling' also allows for tree shaking, which if you use a well-structured library like lodash/date-fns etc, allows you to get that small bit of functionality without paying for the whole library.
So.. There are benefits to this for complex apps - but 90% (charitably) of this kind of code is not in a complex app.
I think it's for two main reasons:
1. If you don't use complicated new technology you won't get a job doing web dev.
2. Many new JS devs don't understand JS/HTML/CSS well, they only understand a particular framework - and even then not in a sufficiently deep way.
When you come across a seemingly normal site that requires JS in order to display anything, it's pretty unlikely that anyone involved ever considered not doing it that way.
Often this is to do with making a site work across browsers. IE11 is the bane of our lives! Plus doing the transpiling allows using things like Typescript which is a godsend on a complex site.
As a recent front end dev, I fought tooth and nail not to include all kinds of tracking drek into the company's site. I lost every time because management overruled me.
At some point, it occurred to me that it's not my site and I shouldn't be taking personally that which doesn't belong to me.
this is not about tracking though. Even with an ad blocker, just about every website and blog now presents multiple spinning boxes when its loading. This is unnecessary , timewasting, environmentally unfriendly programming. And yes , 100% of the time it s devs that choose to build a site this way.
It's come to the point where i feel bad for using plain old single-request-loading html, because it doesn't look 'spinny' enough, and users may think it's uncool.
If business wants something quick and the cost of the website being slow doesn't matter... Why bother?
On the other side, I've been building websites that gets +95 on mobile on Google page speed. If no image above the fold... It gets 100. In mobile, yes. And I still have analytics, YouTube and images...
> just about every website and blog now presents multiple spinning boxes when its loading
The vast majority of "page" content is baked into prerendered HTML and CSS rendered. I'm not sure what spinners you're talking about unless you're referring to web apps with timelines/news feeds that dynamically load.
Users love sites that load the important content and are interactive ASAP. Trust me, they appreciate your boring (fast) HTML.
An old colleague of mine in the 90's used to say "Software is like a gas. It expands to fill available space."
The behaviour of desktop software developers in 1990's was a prelude to web frontend and app developers today. As the resource capacity of PC's increased through the 90's, software developers grabbed it for themselves; for the end user, the experience of using the software never got any faster.
As the storage, processing power and network speeds have increased, web frontend and app developers seem to have grabbed it for themselves as well; the end user experience has generally not gotten faster (if the user follows the instructions: use popular, Javascript-enabled browser, enable images, video).
In the 1990's, users were asked to upgrade their computers so they could run the new, larger but not experientally faster, desktop software. Today, we see the same sort of OS and device upgrades; "unsupported" versions of software that will not run on newer version of the OS. Plus we have a culture of allowing automatic, remotely-controlled installation of new software. Automatic upgrades. Telemetry. "Field testing" of new features. A sizeable amount of user choice and necessity for user consent has been successfully eliminated.
The number of outgoing TCP connections made by today's average websites, usually triggered through cascades of Javascript files, is simply staggering. It would never have been acceptable to do that with the networks and server software of the 1990's and 2000's. Users were not involved in the decision of developers to grab the newly available network resources and CPU for themselves.
I do not use a popular browser for most web use. This allows me to only make a single TCP connection to a website when I access it and can retrieve dozens or hundreds of pages over a single connection, thanks to old, standard features of the web documented in RFCs (pipelining). It is very fast and efficient. For me, the web has gotten much faster, but only because I choose the software and I decide whether and when to upgrade. It is my computer, after all. I am not really impressed by the popular browsers of today because it does not feel at all like the user is in control. Users of these programs have been reduced to guinea pigs.
Product managers add features and/or speed up development by using more resource-hungry runtimes up to the point where the users still tolerate the performance but barely so. Once the product has enough traction and switching costs, the user would rather tolerate the mild pain of slowness than the more acute pain of switching and adapting to a (so far) faster competitor.
This is very much like the idea of the optimal price point where the customer already cringes but still buys.
To be honest, we have decided that lowering the cost of building software is the best priority so we choose more and more abstracted software that requires more resources.
The javascript cascade from hell starts when you add a single ad. We wrote a test param to remove ads and the page load went from 35Mb to 1.2Mb... all of it was JS and ad tracking code.
A news site. It does precisely the same thing as news sites did a decade ago.
On my machine, it loads slowly. Then, it needs to re-load every time you scroll. It's extremely slow. Indeed, on Firefox, it doesn't load everything consistently.
If you click on an article, things get even worse because it needs to reload text when you scroll. This website is what I would call "barely usable".
Let me reiterate: This site does nothing new compared to old news websites. There is zero benefit to the user. It simply is slow.
I don't know who is to blame for this. But if even your text loads slow, you are building a bad website. I am sure, some frontend developer got paid for making this website. I am not sure they should have been.
I’ve been using w3m as my primary browser for the past few weeks. Pages load faster, but the real awesome part has been recapturing attention from image based ads I didn’t even realize I was losing.
I know most of the comments right now are an anecdotal resounding "Yes" from most folks (which I also agree anecdotally), I'd like to respond to the conclusion of the article (which is that as internet speed increased over the years, page loading times have roughly stayed constant). This makes sense in retrospect because product development tends to consider what the baseline acceptable speed/time to load is and then utilize that allowance fully and load whatever is possible (or optimize down until that point during the development process).
I only wish this wasn't the case, and that the internet speed gains over the years actually meant the browsing experince for the consumers actually improved.
Contrast this with chip development, where baseline acceptable metrics were for decades set by an exponentially decreasing curve. If only we could proclaim a Moore’s law for web development that would be self-fulfilling for years to come…
Page load times, indexed for available bandwidth, appear to follow a sort of inverse Moore's law. We could call it Gerdes's random stab in the dark.
My first home internet connection ran at 9600 bps except when it clocked itself down to rather slower. At work at the time I had a synchronous pair of modems running at less than that for an IBM System/36 site to site link. Later on oooh V.FAST - 56Kbps except it wasn't really. More like 48Kbps plus a bit on a good day and a decent marketing department.
I am now using a 1Gbps connection.
My PC on the end of the 9600 bps system was a 80486 based beast running at 25Mhz. It cost me £1600 (thanks Granddad for the unexpected bequethement that was a major factor in getting me where I am today)
I now use a 8 core + H/T Corei7 beastie running at 1.8GHz laptop - its getting on a bit now but it can still churn out packets at quite a rate and crunch my CAD efforts.
Page sizes back in the day were rather small, say 10Kb. Nowadays 10Mb is pretty common (dodgy assertion with no proof)
Web pages do different things than they used to as well.
I don't think it is quite as simple as you suggest, wrt page load speeds. What page, on what, with what and why!
Not only web is getting slower, it is actually everything. I've read a similar article but talking about input latency(from key stroke to displaying on screen), which is also steadily growing.
The reason behind might be the same: we have far more computing power than ever, so we start to abusing it by spending lots of it on visual elements which is good to have but not essential.
Part of it is that modern screens have a much bigger latency than CRTs did. Largely I don't think it really matters. My desktop and phone feel very very responsive, Its only websites that are visibly slow to me. And most of that is waiting on the server. I click a link or submit a form and I have to wait seconds for the page to load where as with a local program its instant.
I keep hearing this come up. Do you have a modern citation for this with modern monitors, say made within the last 5 years?
It seems to be a constantly repeated myth or something of no consequence. (one article I read said LCDs have 2 ms higher latency than CRTs, which I would count as of no consequence)
The 3y old 4k Samsung TV in the living room can't be pushed below 50 to 60ms of latency, even with processing minimized, and compared to an audio signal NOT routed through it (the TV's line out obviously compensates for that, but is only stereo).
Back in 2011/2012, when I got Rock Smith, I used a dslr camera to determine the latency of my LCD compared to my old CRT. Just took a snap of a ms counter racing up on both screens (mirrored). Can't recall the exact difference, but definitely much more than 2ms. I measured because I noticed it during gameplay; I'm pretty sensitive to delayed video/audio, but not 2ms sensitive - that's one beat off at 30.000bpm. You can use that technique to check for yourself with a more modern display.
I specifically asked about monitors. TVs have a huge amount of latency and post processing that’s only recently gotten better. Computer monitors, on the other hand, have long since been very fast.
I ask for evidence because I’m not the one presenting the claim and suspect it’s no longer true.
Yep, as a Dance Dance Revolution player, flat screens were pretty unusable from 2000 (at least for PS2 games) until recently because of lag even on settings that "minimize" it on upscale.
Similar issue for emulation: for the SNES games on the Wii emulator, the game was much harder because you have to adjust for noticeable lag between your presses and the response. I also saw that on the Virgin in-flight Pac-Man: with their emulator, you have lag that makes the game harder. I was able to get a lot farther on the first try by playing on a classic machine.
Yes!!!! React/Redux and other SPA client-side rendering framework I'm talking about you! Just because you can, doesn't mean you need to make a page SPA acting like a desktop application. Stop it!!!! Stop making it a fashion industry out of web development. [End of Rant]
KISS, SSR is fine for most the time for web pages!!!
One exception to the above rule of SPA framework is mithril.
However, I understand not everyone can code in LISP/Scheme way. So I don't blame it for not being more used and popular than React camp. However, they seems to have JSX support now, not sure if the performance is still the same when using JSX.
computers aren't becoming that faster though. And it s not like new affordances are being added to pages , it's mostly aesthetics and ... trendiness that is driving the crazy monstrosity that is most pages today.
Doesn't it have to do more with current software development practices? The requirement for reusable code , and the practice of coders having no loyalty and switching companies every very few years leads to the adoption of anti-optimizing standard practices. If Carmack was making doom today he would be ridiculed for not bundling his functional code and looked down upon for reinventing math functions. The idea that speed doesnt matter is just too prevalent
> And it s not like new affordances are being added to pages , it's mostly aesthetics
I agree on the point of websites getting slower, but not on that it doesn't add value. Website nowadays replace a lot of what would've been desktop applications ten years ago (see Dropbox, Slack, Google Docs, ...). It's not perfect, of course, - a lot of data now lies on PCs owned by somebody else - but skipping the installation/deinstallation part easily while also knowing that the app only has limited access to my PC is absolutely awesome.
I don’t have numbers for it but I am sure the size of the web pages have increased by many multiples over the years and only getting worse. There aren’t any simple pages anymore, every page includes a bunch of JavaScript libraries embedded, tons of ad network code, tons of performance and tracking code, lots of images replaced text. I am not even talking about web assembly, web sockets and client side rendering etc.
It's definitely slower and the easiest way to realize it is to use plugins like uBlock Origin combined with uMatrix and compare load times with them enabled, and then disabled. For me it's at least 50% faster when they're on.
275 comments
[ 71.1 ms ] story [ 810 ms ] threadnews.ycombinator.com - 7 requests, 22kb, .125 seconds - https://tools.pingdom.com/#5d1bf4a4f8400000
The hilarous thing is that if you put in https://www.reddit.com to pingdom's measurement tool, reddit returns the old site layout. https://tools.pingdom.com/#5d1bf3c4e3800000
edit: Just poked around a bit to find best worst examples. Unsurprisingly CNN is the worst I could find after a few mins - https://tools.pingdom.com/#5d1bf596ffc00000 543(!) requests, 9mb, 6 seconds. Just stroll through the list of bullshit it sucks into the front page...what a mess.
Also holy shit I just clicked on the first website I saw on that site and I'm getting about 3fps scrolling it and my desktop is a Ryzen 9 3900x with 24 threads, 48gb ram and an rx5700xt. You don't even get the excuse of "It works on my machine" because this desktop is literally as good as it gets. I just tried a couple sites and not a single one could scroll smoothly, one of them was live applying css transforms to about 30 images as I scroll.
Also, it's possible to browser Reddit through non-web-browsing applications that use the Reddit API.
Reddit is pushing to become facebook without your real name.
With extensive user profiles and now very visible profile pictures, I'm not sure that this isn't going to come as well.
https://www.leanternet.com/
[0]: https://beta.trimread.com
https://www.ecmconnection.com/doc/tower-software-trim-contex...
Avoiding Javascript not only lets me avoid all that bloat and slowdown, but also avoid Javascript-based tracking, malware, and exposing myself to Javascript vulnerabilities.
I also have the power of the entire Emacs ecosystem at my fingertips when I surf the web this way, which can be very helpful in many ways.
Unfortunately, some sites I find essential will not work without Javascript, and for them I go back to Firefox.
In Firefox, I use uMatrix and uBlock Origin to only allow through the minimal amount of stuff that'll let the web page work, and filter out ads.
I have a really old, slow laptop, so web browsing is slow for me, but not nearly as slow as it would be if I consented to swallow all the crap that the modern web tries to force down my throat.
I yearn for the good old days without Javascript or Webassembly. There was Flash back in those days, but fortunately not a single serious site I ever visited required it, so I could avoid every Flash-using site like the plague. But today the Javascript plague is unavoidable.
Off topic: if I use uMatrix should I still be using uBlock Origin as well? Or does uMatric encompass all the features of uBlock and then some?
I find uMatrix much more flexible than uBO in this regard. I don't even know if doing all this is possible in uBO, and suspect it's not, or that at least it's hidden away pretty well, while this is front and center in uMatrix's interface.
Sure. An increase in supply--or a change in its nature--can increase demand.
>Wouldn't that be a good thing, economically speaking?
Not necessarily, in my estimation.
Yes, because it means people can live in places they couldn't before, or could get to jobs they couldn't before. Of course, people who already used the road won't perceive these benefits; they are in the same situation as before.
In either case it's often overstated, expanding the road network (especially intelligently) usually results in less congestion. It's just a poor investment compared to other means of transportation investment in large cities.
If you meant adding capacity to existing roads (by adding lanes) it certainly can drop congestion as well. Expanding roads blindly CAN also make congestion worse but that's a possible outcome not a guarantee.
The point of the original "paradox" is that if you want the least amount of road congestion by private vehicles the best investment is to grow public transport but many places dump more money into roads and lower the percentage of users using public transport because "roads are where the congestion is". Hence the paradox, increasing road spending increases road congestion (in places with existing public transport).
The point of the second paradox is there exist ways to add more paths to a network that result in less flow than the network had before regardless of other conditions like public transport being available. The paradox is NOT that adding additional capacity to a network ALWAYS or NORMALLY results in less flow. In fact most of the time it does help flow (marginally) it's just a poor investment compared to the same amount spent on public transport.
The page speeds that either have or have not gotten slower are generally understood to be purely a phenomenon of larger/bloated pages -- not a result of constricted internet "pipes".
If the paradox applied to the internet, then what you'd be seeing is that if pages loaded twice as fast, people would visit twice as many pages. But that's not at all how it works.
It is in fact a similar phenomenon. The cars are the bytes that developers are stuffing into what they build. It's not people visiting twice as many pages, it's developers continuously expanding the size of what they can stuff into sites to fill the capabilities of servers, end user systems and bandwidth today.
Some of it is unnecessary byte expansion because they can get away with it. The Web was very slow when everyone was on a 56k modem as well. The network pipes were smaller, the servers were drastically weaker, the consumer systems were weaker, everything was obnoxiously slow. It sucked to wait five to ten seconds or more to load a very simple website in 1996. It sucked to watch little real media files and wait a long time to load a couple mb file.
Developers are expanding their byte footprint to fill the available limits of patience, and often going over that line, exactly as they always will.
For most users, your browser is your OS. Hell even when it isn’t, most desktop apps use HTML+CSS for their UI. Hell even many user-facing “embedded” apps (like TVs) are running linux with chrome and showing a webapp as their UI.
The layout engine is just that good and convenient. And downloading fresh app source on every visit solves a lot of problems.
This part of the web is getting bloated and slow.
On the other hand are websites. These are fat as heck thanks to CDN and broadband and advances in server compute power. They load faster than ever.
Remember when downloading memes required eMule? I do.
Now I go to imgur and watch 30MB high def gifs like it’s nothing. My 13 year old self would shit his pants in awe.
Are ads and trackers bloating websites? Yes. Are most websites built like webapps even when there’s no need? Yes.
Blame tooling. Go help. What can we as a profession do to make it easier for random developers with no skill build faster better websites?
Right now we’re actively telling everyone they need to build as if they’re FAANG. Then we complain when a part time dev working for a mom&pop shop can’t wrangle all this tooling built for teams of 1000’s into a solid experience.
TL;DR - the web has gotten WIDER since 2013. A lot.
Thought it made a good point, but was too verbose in doing so.
This might be an opportune time to mention my attempt at helping. I made barleytea.js [1] as a light framework alternative to React that needs no webpack. I also recommend much more polished, production-ready things like µce [2] and heresy [3].
Anyway I just want people to know that there are lightweight alternatives out there, and they're worth at least checking out.
[1] https://gitlab.com/andrewfulrich/barleytea [2] https://github.com/WebReflection/uce [3] https://github.com/WebReflection/heresy
I've stayed with Angular v1 for a long time[0] due to it's simpler nature (no compiler, simply JS); but since that is going EOL I'm definitely going to look into Barleytea.
[0] For private projects only, of course.
The web today is starting to get divided into apps and sites. HN is a site for example. It is small, loads fast etc and works well for it's intended use case.
When I listen to music or podcasts in a web site, I want it to act like an app and for that to happen more stuff has to happen in the client. Thus leading to a longer load time and execution time. This is something I can live with though, since I can do stuff on the web that was impossible just a few years ago. I am also developing apps that was impossible to do on the web a few years ago.
I want to use both sites like looking up that store and order some stuff and apps like doing design or consuming music and video.
I prefer web apps that are done well rather than native apps. I don't have to download anything and they are free from the shackles of Apple, Google and Microsoft. Also, you don't have to make them bloated and big. You don't have to use a framework. You can use web components and maybe some small router library and you have the most important stuff a front end framework gives you.
Just check fastmail, their client is super fast and is a very well done SPA app. Then you can look at Reddit, which is a horrible mess. Like any app, any language you can make the experience shitty and you can make it awesome.
But while people will accept JS and general online abuse, it will get worse.
I have the feeling that most of modern websites use too many cpu&gpu resources. My computer is just 5 years old and each time I visit a modern website my computer really suffers.
Please designers and engineers, I don't own the last macbook pro with maxed out specs and my internet connection is quite normal.
Start creating for the rest of us who don't have the resources or interest in upgrading the computer every couple of years!
Go to the business owners and product managers who actually drive the product and more often overrule design and engineering.
AJAX (and, I suspect, the shadown DOM model) have proliferated in recent years, and there is no site design simple enough that someone hasn't thought to put every page element behind a JS call. Don't forget to put CSS in there, too!
Frontend developers are at fault for all this. There, I said it.
That's why there's such insane churn in the tooling and ecosystem. People rewrite and redesign constantly in order to work with the new cool framework.
React has dominated "real" frontend webapp development for a solid 5 years.
These things don't make headlines or get retweeted. The web produces a lot of variety because it has the widest distribution and the lowest barriers to entry.
https://www.npmtrends.com/@angular/core-vs-react-vs-vue
I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS.
People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.
The last ui dev I had to work with managed to produce in about 1 year a very complicated dockerfile, that was spewing, between other things, an image for e2e testing - but no actual tests and you needed a huge makefile to actually build the thing, a soup of copy-pasted config files that resulted in a vendors.js bundle of about 100 megs - there were more config files than source code, 2 branches named <username>.wip.somedate with commits that commented out some parts of a config, just to uncomment them back in the next commit. The app itself, with ssr no less, was a logo and some text, that was using some custom components, built with some third party vue component that was rendering css in js, thus you had to wait for the entire vendors.js to download before you got anything rendered. His answer to anyone questioning his choices was "this is how modern ux development works".
After he was let go, I took over the ui and along with another coworker we managed to have a working version of the app in 9 days, with no prior knowledge of vuejs and nuxtjs. You can imagine how complicated the app is...
Still, to my point, the tools mentioned here have existed for a very long time with very large communities and are hardly the new shiny thing. Your complaint here seems to be more around using the wrong tool for the job.
This particular frontend person had convinced the owner of the company that there were things you could do in SCSS that you couldn't do in CSS. I had to explain to said owner that SCSS was compiled down to CSS because the browser didn't understand SCSS. That you literally couldn't do anything in SCSS that wasn't allowed in CSS.
The owner ended up having a come to jesus moment when he tried to take all of the tools that frontend developer added and make them available in docker so that no one else had to install custom development tools. He spent several days, failed on it, and realized exactly why I was being so hardheaded about the build chain.
We never ended up getting rid of those dependencies, but I know the owner finally understood my point. Instead the team bifurcated into those who had their local environment setup to be able to successfully work on the frontend, and those who didn't.
Let me trade one dead horse for another: Product and marketing teams are at fault for all this. Or if you prefer, the advertising industry is at fault.
Take the payload of any typical blog or (God help you) your small-town newspaper website and count how many requests correspond to the actual content. Now ask yourself, who's paying someone to bloat this website, and why?
The bottom line is that nobody really has any strong incentives to advocate for performance, so it falls by the sidelines.
If your school uses gsuite (which they likely will given free stuff and integration), you can't choose not to use gsuite.
Same way as dev employees are forced by companies to prioritise features over optimisation.
Yet they keep on adding more and more crap, soon Gmail is going to load for over a minute..
I once saw a website that took a full minute to load, and it was literally a page with images, text overflowing around it, and then some download links. But the way it was built... my god, the way it was built.
That company brought in a new "CTO", and his solution was to dump the entire thing in google cloud. I shit you not, this CTO initially installed an EOL version of PHP, and when errors started happening, he started submitting PR's to revert the PHP code to be compatible with the EOL version of PHP.
Dumpster Fire.
Been there, done that, have scars.
I'm more inclined to believe he googled and blindly followed an old guide with an old ppa than I am to believe that google cloud by default installed an EOL PHP server.
I'm pretty sure he was a node guy who found himself in the PHP world.
I started working with some web developers for a simple project recently, my mock product was built with vue.js using the standard way of “including” it: But what really threw me for a loop was that the web developers told me that that’s wrong, they are now _compiling_ (Or, semantically “packing”) JavaScript blobs to make even very simple websites.
I don’t know why we as a community have started doing that, but it feels like an anti-pattern, it makes adding new dependencies opaque and we can very quickly end up including dozens and dozens of lines of code which must all be rendered by every device that comes into contact with my site.
Often this happens because we want only a small bit of the functionality too.
I personally think it's a bit insane to add node.js as a dependency to a simple PHP project.
To be fair, this 'compiling' also allows for tree shaking, which if you use a well-structured library like lodash/date-fns etc, allows you to get that small bit of functionality without paying for the whole library.
I think it's for two main reasons:
1. If you don't use complicated new technology you won't get a job doing web dev.
2. Many new JS devs don't understand JS/HTML/CSS well, they only understand a particular framework - and even then not in a sufficiently deep way.
When you come across a seemingly normal site that requires JS in order to display anything, it's pretty unlikely that anyone involved ever considered not doing it that way.
As a recent front end dev, I fought tooth and nail not to include all kinds of tracking drek into the company's site. I lost every time because management overruled me.
At some point, it occurred to me that it's not my site and I shouldn't be taking personally that which doesn't belong to me.
It's come to the point where i feel bad for using plain old single-request-loading html, because it doesn't look 'spinny' enough, and users may think it's uncool.
On the other side, I've been building websites that gets +95 on mobile on Google page speed. If no image above the fold... It gets 100. In mobile, yes. And I still have analytics, YouTube and images...
So I'd say depends by what business needs.
The vast majority of "page" content is baked into prerendered HTML and CSS rendered. I'm not sure what spinners you're talking about unless you're referring to web apps with timelines/news feeds that dynamically load.
Users love sites that load the important content and are interactive ASAP. Trust me, they appreciate your boring (fast) HTML.
The behaviour of desktop software developers in 1990's was a prelude to web frontend and app developers today. As the resource capacity of PC's increased through the 90's, software developers grabbed it for themselves; for the end user, the experience of using the software never got any faster.
As the storage, processing power and network speeds have increased, web frontend and app developers seem to have grabbed it for themselves as well; the end user experience has generally not gotten faster (if the user follows the instructions: use popular, Javascript-enabled browser, enable images, video).
In the 1990's, users were asked to upgrade their computers so they could run the new, larger but not experientally faster, desktop software. Today, we see the same sort of OS and device upgrades; "unsupported" versions of software that will not run on newer version of the OS. Plus we have a culture of allowing automatic, remotely-controlled installation of new software. Automatic upgrades. Telemetry. "Field testing" of new features. A sizeable amount of user choice and necessity for user consent has been successfully eliminated.
The number of outgoing TCP connections made by today's average websites, usually triggered through cascades of Javascript files, is simply staggering. It would never have been acceptable to do that with the networks and server software of the 1990's and 2000's. Users were not involved in the decision of developers to grab the newly available network resources and CPU for themselves.
I do not use a popular browser for most web use. This allows me to only make a single TCP connection to a website when I access it and can retrieve dozens or hundreds of pages over a single connection, thanks to old, standard features of the web documented in RFCs (pipelining). It is very fast and efficient. For me, the web has gotten much faster, but only because I choose the software and I decide whether and when to upgrade. It is my computer, after all. I am not really impressed by the popular browsers of today because it does not feel at all like the user is in control. Users of these programs have been reduced to guinea pigs.
This is very much like the idea of the optimal price point where the customer already cringes but still buys.
The javascript cascade from hell starts when you add a single ad. We wrote a test param to remove ads and the page load went from 35Mb to 1.2Mb... all of it was JS and ad tracking code.
Edit: Server-side and client-side rebidding.
Is it frontend devs who are putting Turbolinks in Rails apps then?
https://www.scmp.com/
A news site. It does precisely the same thing as news sites did a decade ago. On my machine, it loads slowly. Then, it needs to re-load every time you scroll. It's extremely slow. Indeed, on Firefox, it doesn't load everything consistently. If you click on an article, things get even worse because it needs to reload text when you scroll. This website is what I would call "barely usable".
Let me reiterate: This site does nothing new compared to old news websites. There is zero benefit to the user. It simply is slow.
I don't know who is to blame for this. But if even your text loads slow, you are building a bad website. I am sure, some frontend developer got paid for making this website. I am not sure they should have been.
I only wish this wasn't the case, and that the internet speed gains over the years actually meant the browsing experince for the consumers actually improved.
My first home internet connection ran at 9600 bps except when it clocked itself down to rather slower. At work at the time I had a synchronous pair of modems running at less than that for an IBM System/36 site to site link. Later on oooh V.FAST - 56Kbps except it wasn't really. More like 48Kbps plus a bit on a good day and a decent marketing department.
I am now using a 1Gbps connection.
My PC on the end of the 9600 bps system was a 80486 based beast running at 25Mhz. It cost me £1600 (thanks Granddad for the unexpected bequethement that was a major factor in getting me where I am today)
I now use a 8 core + H/T Corei7 beastie running at 1.8GHz laptop - its getting on a bit now but it can still churn out packets at quite a rate and crunch my CAD efforts.
Page sizes back in the day were rather small, say 10Kb. Nowadays 10Mb is pretty common (dodgy assertion with no proof)
Web pages do different things than they used to as well.
I don't think it is quite as simple as you suggest, wrt page load speeds. What page, on what, with what and why!
The problem is that web sites are getting more and more bloated and doing so faster than CPU or bandwidth is increasing.
The reason behind might be the same: we have far more computing power than ever, so we start to abusing it by spending lots of it on visual elements which is good to have but not essential.
It seems to be a constantly repeated myth or something of no consequence. (one article I read said LCDs have 2 ms higher latency than CRTs, which I would count as of no consequence)
Back in 2011/2012, when I got Rock Smith, I used a dslr camera to determine the latency of my LCD compared to my old CRT. Just took a snap of a ms counter racing up on both screens (mirrored). Can't recall the exact difference, but definitely much more than 2ms. I measured because I noticed it during gameplay; I'm pretty sensitive to delayed video/audio, but not 2ms sensitive - that's one beat off at 30.000bpm. You can use that technique to check for yourself with a more modern display.
I ask for evidence because I’m not the one presenting the claim and suspect it’s no longer true.
Similar issue for emulation: for the SNES games on the Wii emulator, the game was much harder because you have to adjust for noticeable lag between your presses and the response. I also saw that on the Virgin in-flight Pac-Man: with their emulator, you have lag that makes the game harder. I was able to get a lot farther on the first try by playing on a classic machine.
KISS, SSR is fine for most the time for web pages!!!
One exception to the above rule of SPA framework is mithril.
However, I understand not everyone can code in LISP/Scheme way. So I don't blame it for not being more used and popular than React camp. However, they seems to have JSX support now, not sure if the performance is still the same when using JSX.
https://shop.polymer-project.org/
Doesn't it have to do more with current software development practices? The requirement for reusable code , and the practice of coders having no loyalty and switching companies every very few years leads to the adoption of anti-optimizing standard practices. If Carmack was making doom today he would be ridiculed for not bundling his functional code and looked down upon for reinventing math functions. The idea that speed doesnt matter is just too prevalent
I agree on the point of websites getting slower, but not on that it doesn't add value. Website nowadays replace a lot of what would've been desktop applications ten years ago (see Dropbox, Slack, Google Docs, ...). It's not perfect, of course, - a lot of data now lies on PCs owned by somebody else - but skipping the installation/deinstallation part easily while also knowing that the app only has limited access to my PC is absolutely awesome.
The conclusion in this article is that it's not getting slower though.