Google Seeks to Pacify Consumers with Faster Mobile Pages
bloomberg.com
bloomberg.com
Those optimizations are worth looking over even if you don't plan on adopting AMP.
I do think that rather than requiring direct use of AMP for specialized search placement, it should really measure site performance and only ensure your site meets the same benchmark, no matter what you do to optimize.
Google may not be a perfect ally of the open web, but I like this approach much more than what I've seen from Facebook.
I'd prefer to just improve the browsers instead of putting the burden on Web authors.
>I'd prefer to just improve the browsers instead of putting the burden on Web authors.
A cynical answer is that Google released this because web authors haven't done a good enough job making fast pages.
Sure, I agree that many of the optimizations suggested are good practice.
(Note, though, that serving 2000px wide images to iPhones is fixable in the browser, with downscale on decode.) :)
> A cynical answer is that Google released this because web authors haven't done a good enough job making fast pages.
It's not cynical—that's the exact motivation of AMP. My point is that it cuts both ways: we need to keep improving the browser, as there are still massive opportunities for performance improvements.
From a rendering perspective, yes. From a "make this page load faster", no, because the network download time is 10x-100x larger than the processing time.
This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there's stuff you have to avoid, or branching paths you have to handle to get good performance. If you use SQL databases, not all databases can handle all queries optimally.
I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there's no slow paths.
The practical reality is, there's always a subset of specs known to be fast and well supported and developers just need to know what that is.
In the case of GPU acceleration, the specs are not broken. There is no fundamental reason why animations on arbitrary properties cannot be GPU accelerated and some can be. Ask anyone who's worked with Scaleform whether rapidly changing vector graphics (which is all these animations are) has to be slow on mobile.
For style recalculation, maybe, maybe not; it's not clear to me that browsers are worse than native app frameworks here, except that we're missing Typed CSSOM, which is important spec work.
> This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there's stuff you have to avoid, or branching paths you have to handle to get good performance.
And game engine authors are fed up with it, which has led to Metal, DX12, and Vulkan. It's not a good way to treat developers; we should try to give them APIs in which, as much as possible, everything is fast. I think the Web APIs can be that, if implemented optimally.
> I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there's no slow paths.
I'm not saying that we have to pretend everything in HTML and CSS can be made equally fast. My point is that, in many areas, browsers have done a bad job of even trying to optimize broadly. Take animations, for example: the only thing browsers optimize is two properties out of hundreds, transform and opacity. This is exceptionally problematic, given that there's no technical reason why this has to be the case. I just gave a talk about this a few days ago :)
Animating other CSS properties such as font-size require us to rasterize new content on every frame of animation. That is the inherent reason for why it's slow. Again we can use the GPU for rasterization but we're still going to do it every frame instead of caching the result in a texture that's then composited over and over again.
[1]: https://www.chromium.org/developers/design-documents/chromiu...
Optimally implemented, I believe there should be no difference between "rasterization" and "compositing". You're painting the same number of pixels, paying the same fragment shading and rop cost, either way. Caching fully rendered Web content in textures assuming that the cost of rasterizing that content is high isn't working very well, and I think it's not worth it.
[1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textu...
I agree that the browser should be more like a game engine, and less like an X11 buffered window system, in terms of just rasterizing faster enough to render 60fps. But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls.
Hinting really isn't important on mobile or HiDPI. In fact, no version of OS X or iOS does it. (I don't know about Android, but I wouldn't be surprised if it doesn't on HiDPI screens.)
What's more interesting is antialiasing quality, especially subpixel AA. That's something I think needs more investigation. But I'm cautiously optimistic; there's been some really exciting work in GPU AA and vector graphics lately :)
> Wouldn't a more realistic example be of a UI that contains mainly different font weights and sizes, to better gauge the effects of all of the pipeline state changes.
Don't change state then. :)
State changes really shouldn't be necessary. If you set things up properly, you should be able to render arbitrarily many glyphs with one draw call, bound only by your texture atlas size.
> But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls.
They typically don't. The key is to render critical resources like that to a texture atlas and to batch like resources together as you do so. (For example, batch all box shadow pieces together into one draw call, batch all rounded corners into another, etc.) This effectively places a small fixed upper bound on the number of draw calls you issue. Then you can rerender the page for each animation frame with a very small number of draw calls (frequently just one) and a simple blitting shader. If you get your draw call/state change overhead down, essentially nothing on the Web comes close to taxing a modern GPU; GPUs are incredibly fast at rendering batches.
My talk goes into more details, if you're curious: https://air.mozilla.org/bay-area-rust-meetup-february-2016/
What's the status of Servo BTW? I mean in terms of HTML/CSS spec completeness.
Edit: just saw the demo in the video, awesome job!
If and when browsers change (including those used by a lot of people that only update once a year) AMP can just change its guidelines. These are things people have to do today anyway to get fast sites. AMP just packages up in an easy to consume package.
According to official comment, the ranking algorithm will prioritize page speed, and AMP is a good way to achieve that.
BloombergBusiness uses some questionable sentence structure in order to imply the opposite, but that's on them:
AMP isn’t “a signal we use in ranking” pages, Besbris said.
He declined to comment about whether AMP pages would rank
higher, though he said some of the signals Google uses for
search include whether a page is mobile friendly and how
rapidly it loads -- two problems that AMP seeks to tackle.
Does this mean that only inline styling is supported? <div style="..."> Or just that styling should be included on the page in a <style> tag.
Should people like me start using AMP anyway to stay relevant in Google search rankings?
Showing only results that use AMP would be a very coarse cudgel to enforce page speed. It is entirely within Google's ability to simply directly measure page speed, and to my eyes the more sensible course of action given the capability.
Hope you are using chunked transfers so it will render sooner, pre-gzipped streams end up not being chunked in nginx.
Google has already said AMP is not used as a ranking signal (but mobile friendliness is).
Imagine some web developer at Huge Mega News Corp (HMNC), he comes to his manager about the fact they have 5 analytics suites running and when the ads load they bounce the screen around. His manager reviews it and determines its not important because 1. People are still coming to the site 2. It isn't stopping people from coming to the site. Now the dev at HMNC can come to his manager and say hey what you want doesn't conform to AMP, we can't do that.
I have heard multiple times, AMP will not increase your ranking. Load times don't inherently increase your ranking over other content. But if your site has similar merits to another site, then load times among other things will effect who is ranked higher.
Making one DNS request is faster than making several, including ones for domains related to advertising.
There are the speed gains that Google can offer and then there are ones that are under the user's control, which Google will never offer, unless they change their business model.
Not requesting ads makes my user experience faster.
Experiment: Disable Javascript for Google searches and what happens? Do the ads still load?
Please correct me if I'm wrong, but if a publisher switches to AMP, then all of their ad serving data (and by extension impression data for all of their visitors that Google is able to identify) becomes Google's data essentially. Whereas before, if a publisher wasn't running DFP, AdSense, or GA, then Google was essentially blind to their ad data.
So does this or does this not give Google that level of visibility into the ad layer of a site? If so, that is a MAJOR strategic competitive data advantage once lots of sites switch over, which they will be encouraged to do due to higher mobile ranking as a result of getting their site's sped up.
And for anything not run through DFP and not on Google inventory, this would now give them visibility into those ads, potentially bid data from the headers, potentially audience data for anything passed in plaintext (surprisingly common), etc. Or am I missing something in terms of the data they would see?
Google said [...] it will put websites built with its Accelerated Mobile Pages [...] in the Top Stories section of a search results page
VERSUS
AMP isn’t “a signal we use in ranking” pages, Besbris said. He declined to comment about whether AMP pages would rank higher
I don't know the data on CTR for these featured pages but I think it's probably significant.
Ad blocking.
> The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>.
So you are handing over the security of your site and your user's privacy to Google.