Facebook’s got Instant Articles and Apple’s got Apple News, and now Google has something called Accelerated Mobile Pages, or AMP, together with a whole bunch of partners.
AMP HTML is a new way to make web pages that are optimized to load instantly on users’ mobile devices. It is designed to support smart caching, predictable performance, and modern, beautiful mobile content. Since AMP HTML is built on existing web technologies, and not a template based system, publishers continue to host their own content, innovate on their user experiences, and flexibly integrate their advertising and business models – all within a technical architecture optimized for speed and performance.
The big difference between AMP and other initiatives: AMP is open source and available on Github, and anybody can use the code as they see fit.
Or you can use this:
http://adguard.com/en/welcome.html
Not only does it cause pages to load much faster than they normally would have, it also saves you a ton of data on mobile. (A friend of mine recently started using it – saved 1gb of bandwidth in two weeks. Yes, that’s right… I said 1 *GIGABYTE*.
Edited 2015-10-07 20:30 UTC
Ads…
The question is, how could it work since the ads’ data are still pushed down to you, but are filtered out only on your device (laptop, mobile) ? It should be blocked on the server side to be any efficient.
Most of the bulk of an ad is supplementary resources like JavaScript files, images, and the like.
The ad blocker manipulates the HTML before those extra HTTP requests are made.
Makes sense…
“AMP HTML is a way to build web pages for static content that render with reliable, fast performance.”
So it’s going backwards the way forward?
This is sort of like web components (ala polymer) for dummies…
Its too simplistic right now for any advanced usage, but I get what they are going after. It is probably a good fit for blog sites, news sites, etc. – sites that need SEO, do advertising, and are mostly static (or CMS driven) and don’t really need any heavy “application” logic, just some basic window dressing. This gets you that while not letting you shoot yourself in the foot on mobile too bad when you don’t really know what your doing.
Nothing groundbreaking or even really new here, but it isn’t pointless either. Making all external resources demand loaded based on the viewport is a smart idea, I’ve seen lots of roll-your-own code to do this but not so broadly reusable like this is. The layout hints are a nice touch too, nothing you couldn’t already do with CSS but it is nice to see someone normalize it and make it easy to understand like this. Forcing static sizing on everything up front, something everyone doing mobile should be doing anyway, is a good idea – that is often easy to miss. Validator built right into the runtime? Awesome.
I could see this maybe catching on, but it is never going to light the developer world on fire – it looks more applicable to layout people and designers. Up side is if you get this dumped on you and already understand client-side web development you will know what is going on here in like 5 minutes – there is nothing to learn really. Might become more interesting if they take some of the training wells off later…
Edited 2015-10-08 00:28 UTC
to be honest:
after years of getting enhanced-web-experience-shit rubbed into my face, I miss the days of HTML 3.2…
smashit,
I miss HTML 3270…but I’m possibly mixing concepts
Seriously it feels like we’re riding a pendulum that keeps bouncing between server based and client based interaction models. Latency and network dependency are inherently better with client based interaction. However server based interaction is the preferred business model for many providers today.
PS. Anybody remember ripterm?
https://en.wikipedia.org/wiki/Remote_Imaging_Protocol
Forwards. It’s just a subset of existing web techs to make them suitable for a particular device class. Once they get fast enough, AMP can be dropped.
It’s called pragmatism.
So the root loads faster, then comes the megabyte of javascript, images, ads, and the rest that burn data, cpu, and memory.
Javascript is not allowed! Ads are loaded in separate iframes (with no access to the document) and are prioritized lower than all other content. Images support the media attribute and if properly done – will only load images that are sized for your device.
It doesn’t allow custom javascript, just the js that comes with AMP itself (to implement the bundled Web Components).
Read between the lines… It’s designed to get the ads to your mobile devise as quick as possible (My guess is at the expense of content) so that you can get credit for a “view” even if the content is slow and the user gets impatient and moves on…