Google's Effort To Speed Up the Mobile Web (ampproject.org) 95
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.
I hate mobile web pages (Score:5, Insightful)
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.
Re: (Score:2)
Yes, this is just trying to serve the existing ads and tracking crap faster.
Ad/Tracking Blocking really is the only way forward.
Re: (Score:2)
Yes, this is just trying to serve the existing ads and tracking crap faster.
Ad/Tracking Blocking really is the only way forward.
Yep. I just installed an ad-blocker on my wife's ipad, and *boom* everything is so much faster. It's like night and day, and we're never gonna run without one again.
You hear me, ad companies? WE'RE NEVER GOING TO BROWSE WITHOUT AN AD-BLOCKER AGAIN.
You forced us into this, so screw you, we'll have the last laugh.
Re: (Score:2, Interesting)
Yep, with JS off, mobile web is really slick. Slashdot redirects to that page complaining I have javscript disabled saying to use the desktop site really fast. Go Mobile web! And you press the desktop site link, and the next internal link you hit puts you back at the stupid page saying to use the desktop version... If you are going to both auto-detect my mobile user agent and my lack of JS support please don't auto redirect to a useless page every time I click any internal link.
I think I should just make my
Re: I hate mobile web pages (Score:1)
The weird part about Slashdot mobile is how much better it looks if you're not logged in. Also the absence of any form of captcha when you're posting a comment as A..C.
The combination of those things is probably why there are more a.c. Posts now than in the past. It's just not worth logging in to comment and then having to completely shut the browser down to log out.
Re: Sorry. Not gonna work (Score:5, Insightful)
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.
Google seems to be avoiding the real problem (Score:5, Interesting)
The performance problem isn't with mobile web, it's with *Android* web. Apple devices are approaching desktop-level performance on js-heavy pages while android devices are getting worse and worse. A considerable contributor to this problem is the trend for android devices to show more cores in them, not faster ones. JS is still single-core after all.
Interesting comparisons here: https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889
Disclaimer: I am an andoid fanboy.
Re:Google seems to be avoiding the real problem (Score:4, Insightful)
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.
Re: (Score:2)
Probably a good excuse to dump the web as it's just shocking how many JS trackers are getting at your stats with every page visit. Though heading to the App store to serve web content means providers just get more "detailed" stats about their users. So Kobayashi Maru there right.
Re: (Score:2)
Thanks for the link. I'd mark your comment up as informative if I could. :)
Still, comparing to iOS devices is like saying "there's no performance problem for games on laptops; my Alienware laptop runs them well." Android devices are a lot more varied than iOS ones, and it'd be nice to have web pages work well on a sub-$100 device and not just flagships. I don't know how well old iOS devices cope with pages either. Last I heard a comment from an iPhone 4 user it was that the phone was very sluggish. So just
Re: (Score:2)
It's not just comparing a state of the art iPhone 6s to an old Android phone. The top of the line Galaxy S6 performs worse than the 2011 iPhone 5 when running JavaScript.
https://meta.discourse.org/t/t... [discourse.org]
Re: (Score:2)
I can say Crosswalk is really the step up that's needed for both iOS and Android and wIth ECMA being enforced with more and more browsers over time. The problem is just that its 40 meg to download.
I can see this AMP project as good pretext for quick and instant functionality, though from downloading the examples and reading a bit about it. It really needs a lot more work before it would become useful to me or any of the projects i'm presently on.
People bitching about mobile websites are in for a real shock
Re: (Score:1)
No, it will suck. No showing the phone to someone else. No using it while walking/traveling (or maybe that's a feature). No adjusting the phone so the sun isn't reflecting in your face. No one with shaky hands. There will be a bug where the shake events are still processed while your phone is locked and in your pocket.
3D mice have existed for decades. They still haven't caught on. You can connect them to your phone. No one uses them.
You know advertisers will jump on the features first. Instead of c
Re: (Score:1)
That is 6 year old data.
Re: (Score:1)
they don't want you to 'not use JS' they want you to use the particular AMP-js
I mean seriously on "https://www.ampproject.org/how-it-works/" (and amp page btw) ... BUT shows nothing but a blank page unless you allow javascript from cdn.ampproject.org
- they say explicitly "For a headline, some text and an image you do not need JS"
- that page fits that description
for something explicitly aimed at static pages failing progressive enhancement completely is utterly ridiculous
Quite frankly I expect better technic
Re: (Score:1)
Except that you can now view that page as it no longer has it: meaning either it is, in fact, not valid AMP, or that this tag is not needed and exists only to defeat those who don't/won't their JS.
I suspect the latter: if you go to a page marked up with the latter and use web dev tools to set the opacity to 1 everyth
Bend over (Score:2)
Its WML time!
Re: Bend over (Score:1)
WML was apparently inspired by HyperCard. So, hyperlinks and hypertext and tons of hype... The reinvention rolls around again.
Best case scenario; marketing and tracking scripts get a solid broadside across the Web with this. Except Google's tracking, of course...
Won't fly with companies (Score:5, Insightful)
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.
Re: (Score:1)
I'm sure they'll support google advertising
Re: (Score:3)
This'll be great for individuals, but companies won't accept it.
Then again, they won't accept your solutions either.
The web has a serious problem. The web is broken.
The present day over-commercialization of the web, with tracking and intrusive ads, and making search engines approach worthlessness; and as ad-blockers and script blockers are breaking out of the province of nerds, and onto regular folks machines, is showing the "target's" growing rebellion.
And even though Joe Sixpack might not understand the tracking, he does understand that his webpages are taking a l
Re: (Score:1)
Hi. Experienced web developer here. You're mostly right, but about 7years out of date (you sound like a Drupal guy :)). Your first point handles 80% of performance issues, that is true. You second point... it is true that using images for placeholders makes for poor performance and problematic portability across devices, but nobody does that any more. It kind of went out with tables and rounded corners/raised button effects, although those are trivial to do in CSS3, which is pretty much universal now.
You
Re: (Score:2)
No, in point #2 I'm not talking about placeholders. I'm talking about eg. using an image for a header so you can put the site's name in it's brand-specific font as opposed to simple setting the background color and using text for the name. Or using images to create a separator between headline and content so you can have one that looks exactly like what you use on your TV shows or in print.
As for the third point, it only breaks things if you set the size to something other than the image size (which your se
Re: (Score:2)
3. Stop using dynamic layouts that load the entire page and then make changes to it that alter it to it's final layout.
Yes, yes, and YES. I hate pages that resize themselves 3 or 4 times before stabilizing. And some of them continue to resize in a jittery fashion as you scroll or as more remote content (mostly ads) get loaded.
Their are sites I no longer visit because of this behavior and I suspect the owners and developers have no clue as to why people shun their pages.
Too many ads, too much dynamic bullshit, too much load-while-scrolling, too much crap. The web is now a festering pile of ads, with a little content thrown i
Re: (Score:2)
The first problem is that ad networks won't accept the limitation, so any site that shows advertising will have to eschew AMP.
Not true: they're very clear in all their documents that having good support for advertising is essential. Remember, it's Google who's doing this! They're basically an advertising company, so they're not going to do anything that hurts that. Here's what they say about how ads work:
We've taken first steps to make ads in AMP HTML better, but we aren't done yet. AMP HTML doesn't allow JavaScript so ads cannot be directly embedded - instead they live in sandboxed iframes with no access to the primary document. Relying on iframes solves some of the worst performance pitfalls with ads, in particular with respect to document.write. We also prioritize ads lower during loading than other content and optimize load timing to avoid jank. Ads in AMP files can still be heavyweight, so there is still a lot of work to do for us.
And here's another essential element of it:
This brings us to the final topic that makes AMP HTML unique: all resource loading is controlled by the AMP library and, more importantly, resources must declare their sizing up-front. Document authors have to state resource sizes explicitly. This doesn't mean that resources can't be responsive - they can be, but their aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action. An ad at the top of the page can't suddenly say: "I want to be 200 pixels high instead of 50." This dramatically reduces jank and prevents users from losing their place in the document. All custom elements are subject to this restriction. Placement on the screen can be reserved while their implementations download asynchronously. This gets us lazy loading with zero visual jank.
So ads might still take a while to load, but they're trying to make sure that doesn't prevent the rest of the page from loading and becoming usable as quickly as possible.
ads are the problem (Score:5, Insightful)
Ads are what slow down the mobile web. Eliminate them and it runs blazingly fast.
Reckon you can do that, Google?
Re: (Score:2)
Reckon you can do that, Google?
Of course they can't. Look at their FAQ [ampproject.org].
How will advertising work on Accelerated Mobile Pages?
A goal of the Accelerated Mobile Pages Project is to ensure effective ad monetization on the mobile web while embracing a user-centric approach. With that context, the objective is to provide support for a comprehensive range of ad formats, ad networks and technologies in Accelerated Mobile Pages. As part of that, those involved with the project are also engaged in crafting Sustainable Ad Practices to insure [sic] that ads in AMP files are fast, safe, compelling and effective for users.
Re: (Score:2)
A goal of the Accelerated Mobile Pages Project is to ensure effective ad monetization on the mobile web while embracing a user-centric approach.
TRANSLATION: "Forget content and usability, the IMPORTANT thing is to be able to cram the page full of ads."
"embracing a user-centric approach"
FFS, just kill me now.
Re: (Score:2)
Not since AdAway. Of course you need to be root, but who in their right mind doesn't root his/her Android phone first thing after unpacking?
Re: (Score:2)
What's wrong, Mr. Marketing Droid? Mad I'm blocking even inside apps ads?
Why would I help Google with 'open source'? (Score:3)
This is part of a general trend that I call 'open season', basically big companies persuading naive people to do their work for nothing, under the banner 'open source'.
Re:Why would I help Google with 'open source'? (Score:4, Informative)
Just yesterday I measured data use of Germany's biggest gossip news site (bild.de) on my smartphone (Android 5.1 with stock browser), cached and uncached (browser cache cleared, browser restarted) with and without ad blocking (using AdFree host list). The phone was on Wifi / DSL.
Here's the result:
uncached load (first visit) with ads: 2.4MB data, 26s (!) until the display goes from white to some content
uncached load (first visit) without ads: 1.7MB data, 11s until the display goes from white to some content
cached load (second visit) with ads: 272KB data, 2s
cached load (second visit) without ads: 45KB data, 2s
Re: (Score:2)
Here's the result: uncached load (first visit) with ads: 2.4MB data, 26s (!) until the display goes from white to some content uncached load (first visit) without ads: 1.7MB data, 11s until the display goes from white to some content cached load (second visit) with ads: 272KB data, 2s cached load (second visit) without ads: 45KB data, 2s
A friend had a similar experience - He opened a webpage both ways, and to see a roughly 500 word page, without blocking he received 40 MBytes of all the other presents they give us.
Re: (Score:2)
This is part of a general trend that I call 'open season', basically big companies persuading naive people to do their work for nothing, under the banner 'open source
While the trend you highlight is disturbing, the alternative is worse: back-room deals between the same "big companies" to stuff this software into your phones and web-apps without your knowledge or say-so.
Related article (Score:3, Informative)
NY Times had an article about the cost of mobile ads, the article also had some interesting data about load-times and how much data was javascript, videos, images, embeds etc.
http://www.nytimes.com/interac... [nytimes.com]
Posting as its related to the efforts described above
Re: (Score:2)
This article is a good start. There are two things were it could improve.
1) They measured the site's total data size, but not the load time. Load time was estimated = size/bandwidth, ignoring latency, parsing time and data dependencies. Actual load time should be (much?) higher.
2) Strangely, they did not account for http compression, so they cannot have measured actual traffic size. This implies they did only measure uncached loads. Most people visit a news sitte more than once, so cached loads would be mor
free cache ! (Score:2)
so basically its a set of specs that allow google to cache your webpage and allow you to track it
WHY OH WHY not simply use the standards outlined here : http://www.w3.org/Mobile/
and then produce a validator so that sites can be cached by oh I dont know the network operator or anyone including google after all are they not closer to the endpoint ?
seems very pointless and a reaction to facebook allowing publishers to push articles in their network...
regards
John Jones
Re: (Score:2)
You can't cache live, "personalized" content.
More and more of the web is becoming a constant stream of shit with ads and tracking tacked on. You can't cache this.
The solution is to block the ads and trackers. Users WANT the constant stream of shit. The remaining static content is a drop in the bucket, and any decent browser already caches it, nothing special to do on the server/network side.
Just make your website not suck (Score:2)
Google should focus on speeding up android first! (Score:1)
Jeff Atwood wrote this great article https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889 [discourse.org] that shows how far Android has fallen behind.
Wrong direction (Score:2)
2. We need a different approach for mobile displays, not a different approach to pages. Computer screens are landscape while "mobile stuff" is portrait in most cases
3.We need to close the gap between PC browsers and mobile ones. In either way. As of now the gap is wide large.
I must be a genius (Score:1)
I figured all of this out in 1998. No jokes.
You load more crap, the page loads slower. You make it more complicated, it loads slower. Your web developer is an incompetent script kiddie, the page loads slower.
adds? (Score:1)
Original Design (Score:1)
Whatever happened to the original design of the web were web developers only had to describe the content and then the browsers would render it the best way for the device? I liked that. Every step away from that is a step in the wrong direction.
Re: (Score:2)
Whatever happened to the original design of the web were web developers only had to describe the content and then the browsers would render it the best way for the device? I liked that. Every step away from that is a step in the wrong direction.
LOL it was replaced by "responsive design".
The web has outgrown HTML 15 years ago (Score:5, Insightful)
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 [polymer-project.org] 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 [yugop.com] 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.
Re:The web has outgrown HTML 15 years ago (Score:4, Insightful)
> The problem is HTML. HTML is for documents, not the living
> application-like multimedia canvases we've all been using since 2000.
That's half the problem. The other half is people wrapping damn articles in "application-like multimedia canvases". [lmorchard.com]
Why is 75 kB of HTML wrapped up in a 9.5 MB page? That's literally over 100x larger than it needs to be. Hey Google, I think I just discovered a way to speed up mobile browsing 100x. Will AMP do that? If not, call me.
Re: (Score:1)
Agreed with you until you say "Flash was pointing in the right direction"... maybe for "flashy" things but for static content its a mess, overall flash was a big mistake and adoption increased just because "Designers" like the WYSIWYG approach and "scene" based animations plus was already integrated in their "professional" tools.
Disclaimer: I'm also a senior developer with heavy experience on web development not focused on web-design as Parent OP.
Re: (Score:2)
Font integration? - Only since a few years back and only with awkward CSS that doesn't compile fonts and brings along licencing issues.
Relyable Layout behaviour? - Only with hacks and tricks and JS stunts. And not even then do we have the power of a usefull layout engine. ... OK, we've got justify, which no one else offers. ... I remember clearly Flash and the assh*les at Adobe screwing us over with in a fraudulent sale of a fake non-feature in Flash CS 5. In this small detail HTML actually is better than e
Re:The web has outgrown HTML 15 years ago (Score:5, Insightful)
I had a look at your 16-year-old example. Frankly, I'd have quit after the "Now Loading" and "Click to Start" and never got as far as skipping the pointless "intro" as well if I hadn't felt obliged to go the extra step in the interests of exploring your argument.
I just want the information, particularly on a mobile device. I don't care about the "design". I don't care about "immersive". I don't want to waste my time with pointy and clicky things that shoot around the screen for no apparent reason. That's what *you* want. And that's just as bad as what all those ad-merchants want - it's just crap that gets in my way and wastes my time.
Has anyone considered that... (Score:2)
Use Ghostery Browser (Score:2)
Use the Ghostery browser, problem solved.
For those who don't know, Ghostery cannot be offered separately, because Android Apps are not allowed to screw with each other's data. So Ghostery brought out a browser than includes the blocking. The web is a lot saner this way.
Regarding TFA: I am not at all fond of the idea of yet another web standard
"author-written JavaScript" (Score:2)
As opposed to the other kind of Javascript.
Simple fix: stop loading 10 MB of ads per page (Score:2)
You want a faster web? Stop loading every page with 5 to 10 MB of ads and trackers.
A typical page now has 50 ~ 75K of text (content) and 9.5 MB of ads and other horseshit like auto-play video, trackers, remote metrics, etc etc etc.
Seriously, cut that shit out.
Better Idea: stop the madness (Score:2)
It shouldn't be surprising to anyone why performance on the web sucks ass. Each site needs to knowingly or unwittingly enlist dozens of global stalking/analytics providers so that no matter where any user goes multiple companies are watching their every move across the web. Apparently it is too difficult to bother running a stats package on your own access logs anymore. I say unwittingly because many of these firms have cross agreements with other stalking companies when you reference their crap referenc
Benefits the non-mobile web as well (Score:2)
I strongly suspect that the majority -- maybe the vast majority -- of the data that is being retrieved by my web browser is not related to viewable content at all but is devoted to snazzy menu functions and, well, crap that I might not even choose to view. It like having the entire set of encyclopedias delivered to your door when you want to look up one simple thing. (Yeah... I remember encyclopedias.)
I would welcome eliminating the glitz and dancing bologna that litters most web pages today.
AMP is not the solution (Score:2)
I've seen it with software development and with web development. People get fast computers and fast network connections and they forget that other people don't have those. They forget that not everyone is in their country and has that infrastructure. If you want your pages to load faster on the mobile web then do the following (it will also work on regular sites) and it can save on your bandwidth costs too
1. Clean up your HTML - Many content generators add in a lot of extra space that easily double or tr
Compact HTML anyone (Score:2)
That has been attempted several times. One attempt is compact HTML
http://www.w3.org/TR/1998/NOTE... [w3.org]
No more ad blocking. (Score:2)
I'm late to this party, but I'm surprised I haven't any point out the affect on ad blocking.
If the page is pre-rendered on the server, with there be any clues for the browser to guess what are ads?