Slashdot Mirror
Google's Effort To Speed Up the Mobile Web (ampproject.org)
An anonymous reader writes: Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages — which aims to speed up the delivery of web content to mobile devices. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ has a few more details.
They shrink down the content, but keep the ad network bullshit huge in comparison.
Mobile web without that rubbish is almost instant even on a struggling 3G connection. Hell, even regular web pages with junkware scripts blocked are quick-as.
You're looking in the wrong place, google.
This'll be great for individuals, but companies won't accept it. The first problem is that ad networks won't accept the limitation, so any site that shows advertising will have to eschew AMP. The second problem is that companies use Javascript frameworks so heavily in their Web design that they won't be able to just drop it and go back to static HTML/CSS for their sites. If they were willing to, after all, Google wouldn't've seen such a need AMP in the first place.
I think the same results can be achieved by three things:>
1. Strip advertising down. Ads are the biggest things I find slowing mobile Web pages down as the ads do so many things to keep content from being accessed until the ad's been seen and dealt with and fetch so much stuff from so many remote servers. Minimize the number of ads and make them as simple as possible.
2. Stop using images for layout and convert to using CSS instead. Yes you lose the ability to do fancy brand-specific artwork on headers and separators and such, but you know what? Most users don't care about those things.
3. Stop using dynamic layouts that load the entire page and then make changes to it that alter it to it's final layout. Just lay things straight out so the browser can render stuff as it's loaded. Specify sizes for images, drop the "Tap to read the rest" buttons that hide the bulk of the content (but still require it to be loaded before the page can render), that sort of stuff.
Easy way to do this: one of your test machines runs Windows XP on hardware with a 500MHz CPU, 256MB of RAM, an unaccelerated graphics card with 2MB of video memory and a 56K modem (or 115200bps serial link) for network connectivity. If your site performs decently on that, it'll be good on any mobile device.
Ads are what slow down the mobile web. Eliminate them and it runs blazingly fast.
Reckon you can do that, Google?
The problem IS mobile web. They actually try to cram more tracking JS crap on pages, with auto-playing video [at least they still generally serve flash to desktop, so blocking Flash works to kill those ads]. It's ridiculous.
Sleep your way to a whiter smile...date a dentist!
Chrome developer tools already give suggestions for improvements. Experienced developers know how to learn and thus improve their sites. I don't see wide adoption here unless built into major content management systems.
The problem is HTML. HTML is for documents, not the living application-like multimedia canvases we've all been using since 2000.
Flash was pointing in the right direction, but it was proprietary and Adobe screwed it up.
Simply setting up a usefull canvas layout is pure torture in HTML, with tons of libraries, JS and CSS hacks, just to get the thing sort of running.
Ginormous hacks such as Googles Polymer try to pry some sort of sanity from this plattform with a huge effort and enable modern age development, but the simple fact is, HTML is at least 15 years behind what Flash or similar approaches had to offer.
And don't even get me started on building a usefull web-application with useful clientside logic without a bizar convoluted mess of tie-ins and callbacks.
Example: This multimedia website in Flash is 16 years old. That is sixteen years . ... It's from freakin' 1999!!. It's parely possible to make such a thing with todays HTML, without becoming an all-out programming and browser expert and spending a forbidding amout of time getting it right.
HTML, CSS and client side logic - wether with JS or something else - need a massive redesign for modern day multimedia and multi-screen requirements. When that happens, performance will be sane again. I expect web components and web assembly to get us back on track a little, but that's gonna take at least another five years.
Bottom line:
The web is a mess, and frickin' HTML and the ignorant smelly boring nerds that still push it as a cure-all are to blame.
Disclaimer: I'm a senior web-developer with focus on FOSS technologies.
We suffer more in our imagination than in reality. - Seneca