Slashdot Mirror
MIT Creates Algorithm That Speeds Up Page Load Time By 34% (softpedia.com)
An anonymous reader writes: MIT researchers have created an algorithm that analyzes web pages and creates dependency graphs for all network resources that need to be loaded (CSS, JS, images, etc.). The algorithm, called Polaris, will be presented this week at the USENIX Symposium on Networked Systems Design and Implementation conference, and is said to be able to cut down page load times by 34%, on average. The larger and more resources a web page contains, the better the algorithm's efficiency gets -- which should be useful on today's JavaScript-heavy sites.
I got first post!
Now, the next logical step is to have this algorithm analyze the actual scripts and figure out a way to convince the various malwares that they've been loaded satisfactorily even though they haven't. That way you could avoid downloading almost 99% of modern web pages.
It would be better if, rather than needing algorithms to speed page loading, we did away with the bloated javascript entirely.
I have something kinda like that its called No Script.
would still be cooler if there was no 'dependency graph' of dynamically loaded resources behind my every HTTP request.
CLI paste? paste.pr0.tips!
They would all load a lot freaking faster if they would stop designing them with multiple, stupid, scrolling, 20 megapixel background images and dozens of megabytes of irritating javascript "special effects". Just saying.
>> Algorithm That Speeds Up Page Load Time By 34%
It's called AdBlocker
Use a static HTML generator to eliminate the overhead of a CMS.
34% more ads.
disable javascript.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
I've not seen the algorithm but I already know its approach to be wrong.
As the resume indicates: "[...] which should be useful on today's JavaScript-heavy sites. [...]"
And that's the mistake: relying on JS at all.
Vulcanising and HTTP2 Push are the way to go.
Allthough I do wonder if this method then still has a chance of improving a sites performance.
Personally I'd say well and automatically curated HTTP2 Push and automated minifying and compression are probably the best method overall.
I do doubt that this method could improve much more if that were in place.
But I could be wrong.
Does anyone have experience with http-push and perhaps some insights to offer?
Please comment below. Thanks.
We suffer more in our imagination than in reality. - Seneca
Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
You forget -- those ads would be 34% faster, too ... so you could get 51% more ads in the same time it took to serve the original bloated page.
Build it, and they will come^Hplain.
Not having 14 scripts be needed to post a comment, not having 8 other scripts clogging the pipes for one advertisement, 6 scripts for tracking you, and multiple other scripts for whatever reason.
Nor having a giant, moving graphic as the base part of your page which can't be turned off, menus which bounce up or down when you hover your mouse over them, or needing to have the latest and greatest browser so you don't miss out on the latest and greatest "features" of a site.
But no, finding an algorithm to speed web page loading is what we should concentrate on.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
The web is grinding to a halt. Even with Adblock and Noscript, Modern CSS alone is a massive hog of CPU time and pages are taking longer and longer and longer to load almost every day now. Turn on javascript and the sheer amount of calculation now required to display a page which has, at most, 10KB of text is astounding.
I'm starting to see more fully flatscreen designed pages which consist of little more than 200KB of images and -- as I have discovered to my horror -- megabytes worth of gif "video", all bundled with in well over 100KB of javascript calls which bring every modern browser to their knees.
We are now only discovering the terrible price of web standardisation and brower stability. Webdesigners now have complete freedom to do anything they want, and we can't stop them. I reckon we've got three years before web designers unleash some kind of Mutally Atrocious Design shift whereby our browser all implode and everyone leaves for once off apps. The world wide web can't take much more of this.
This is confusing. Just call them Stanford researchers. MIT is just a nickname.
fuck CSS, fuck JS/ASP/AJAX, and fuck web images via HTTPS.
I went and actually read TFA. It seems all they've done is create a bastardized version of a less efficient SPDY/HTTP2 protocol fetching system. Essentially, they're trying to solve a problem that is already solved, but the existing solution is already faster, more efficient, and more well thought out in general.
Here is a good example: https://http2.akamai.com/demo
Identify the advertisements client side and don't load them. Speeds up loading and rendering pages a lot.
For code bloat
I guess the browser-side performance isn't so much what they're talking about (rather, reducing network round-trips), but still, I have always wondered why we're still sending xml and js, plain or gzipped, rather than sending compact binary formats.
EXI is a W3C standard; it's more compact than gzipped xml and it's more than a dozen times faster to parse.
Rather than coding in JS all the time, lots of people are using javascript as an intermediate representation or bytecode. This is tremendously inefficient.
Though the WebAssembly effort sounds like people are finally realizing they need to address the problem, it sure seems like they're approaching it from a rather odd angle. asm.js and pnacl don't necessarily seem like where one should start if one has the freedom to design a new IR.
Followed shortly by 35% more advertising :(
Sweet, now I can bog down my sites with more eye candy, and the users won't notice a slowdown.
I'm not sure what this is supposed to show me. The http2/push version took like 9 times longer in a capable browser.
Ugh! how does stuff like this get green lighted?
Yes, in some cases it's possible to improve the user experience by getting things to start rendering sooner by being smart about the order in which things arrive at the browser. But that has nothing to do with making the farking page LOAD FASTER.
Plus, the claim:
>As previous studies have shown, the problem of slow loading pages is not always users with small bandwidth, but the time needed to set up the connections for each network request, the file's size, and delays on the network itself.
is equally silly. That's about as meaningful as saying:
As previous studies have show, buying the world's fastest automobile doesn't always decrease your commute time to work.
Go to static ads, and make the ads load AFTER the page loads. If you don't use ad blockers, and watch the bottom of the page, in the info line, you'll see part of the page load, then ad.this or ad.that and on and on, until the ads all load a lot of the time, before the web page you want to view comes up. If they went to STATIC ads, I bet most people would stop using blockers. The loading of ads, especially the annoying video ads that start playing automatically, forces most to use some sort of blocking, as a way to stop it.
In an effort to regain love of your brand, can we please link directly to the relevant news site and paper (when not paywalled), and not some third-party site that has no value-add?
- http://news.mit.edu/2016/system-loads-web%20pages-34-percent-faster-0309
- http://web.mit.edu/ravinet/www/polaris_nsdi16.pdf
The dependency graph for weather.com alone in the actual paper would lead to a much richer discussion upfront in the comment sections.
EDIT: captcha - euphoria
The W3C itself already was a problem, so anything produced by them isn't going to stand out as a solution. That the WebAssembly bunch is just as much a problem, only differently so, doesn't change that.
I have another way to speed up page load times- just install an ad blocker. Seeing a 50% speedup after doing that is not uncommon.
Just cruising through this digital world at 33 1/3 rpm...
So they have basically re-discovered the old browser plug-in Naviscope (Win95 time period), which allowed you to kill individual data streams coming from web sites.
Comment removed based on user account deletion
Browsers don't have enough trouble properly dealing with all the JavaScript that web sites shove down out Internet connection now. How nice that you've found a way for web sites lard up their pages with even more of the stuff.
CUR ALLOC 20195.....5804M
I used to experiment with page loading for progressive download as well as dependency graphs while at Opera as a developer in the late 90s.
The web wasn't so open back then, but it wasn't difficult to make things like provider side proxies which would reencode images to support faster transfers. Most people store images and data in general in formats which are optimal for editing. Photoshop for example makes absolutely awful PNG and GIF images. Videos are almost always encode without tuned hinting. Etc...
On almost every website I encounter, people are placing more and more massive .min.js files for things like angular and bootstrap at the end of their pages. They behave like the browser is fast enough that doing things like parsing data should be instantaneous.
There are hundreds of ways you can optimize even relatively simple pages to stream and parse faster. We simply don't.
Then you have things like Opera Mini which approach the problem by just rendering server side and streaming the results. This is actually a great idea except it's just throwing massive CPU resources at the problem to solve it.
All I can say from my own experience as a web developer is that I'd much rather have a human readable format (JSON) than a binary format. It is invaluable when debugging problems.
Their next project should be an algorithm which converts pages with "scripting junk" to plain nice HTML which can be readable by any browser.
Not (apparently) having learned anything from the switch to digital tv broadcasting (where the higher bandwidth was not used for better quality, but was co opted to shovel more channels of low quality shit) this "34% faster" algorithm will simply result in web coders programming at least 34% more crap ads and scripts into web pages.
-Styopa
Since I live in America outside of a major city, I am a member of the 80% of the American population who cannot get broadband Internet. Also, thanks to cronyistic laws that prohibit my local government providing a service that the corporate oligarchy refuses to offer, I am limited to whatever scraps the incumbent political donor is willing to throw my way.
Google has been working on a new compression scheme where the dictionary is fixed and stored in the browser. It makes sense since a lot of HTML and Javascript is highly repetitive and would likely be selected for inclusion in the dictionary by gzip anyway. You can even optimize Javascript to be more compressible under this scheme.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
For binary XML, as well as for the various fledgling binary json or binary yaml formats, the binary representation can be quickly converted to a plaintext one that has basically only minor formatting differences from the original. (I was about to say "to a human-readable one that..." but that's a stretch for a lot of XML.)
An AST / IR / bytecode is decompilable; e.g. from what I understand LLVM can do a good job of translating its IR back to C. Obviously a lot more information that could help with human comprehensibility is lost in that process than in the cases above. But decompiled IR can be as readable as minified JS source code is.
Of course, even without using any of these, what's sent over the wire is usually not human readable anyways, it's just that the tools to translate these other formats back to plaintext are higher-level than gzip is.
Tokenized languages are awesome! All the speed of a binary interpreter and all the round-trip editing of a direct textual representation of the human-friendly version using an amazingly 'original' command named LIST. Only latency issue I noticed with some is that for larger programs, it takes longer and longer to add each line of code to the binary form in RAM. Yeah, my 6502 memory limitations are showing. XD So glad that ARM is a popular CPU family nowadays!
Web was supposed to be a TEXT CHANNEL. For binaries, FTP. If you compress and zip, etc., you are no longer in the web. There may be a significative difference if it is no longer The Web.