There are two articles about AMP on the front page right now, this one and https://news.ycombinator.com/item?id=11167428 . Which is better?
They both cover different aspects of AMP and there doesn't seem to be much overlap so I think both are ok.
Google Seeks to Pacify Consumers with Faster Mobile Pages
31–40 of 50 posts
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#32Earlier quoted context omitted.
I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't care. 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…
> I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't care. 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 (wh…
I think you have a different idea of what gpu acceleration means here. When we say that animating transform and opacity is fast, it means that we can animate it without rasterizing content over and over again i.e. only use composition. This is independent of how rasterization takes place. Rasterization itself can be gpu accelerated, Chrome has started doing this on mobile[1].
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...
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#33Shameless plug, but if you care about web performance, my startup, https://rasterize.io provides easy frontend performance monitoring. It tells you how fast users load your site, broken down by desktop vs. mobile, and geography. You can view most of the chrome devtools waterfall information, for every (modern) visitor.
What's the page load overhead in adding this for each user?
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#34Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#35There's a lot of Google negativity here (perhaps not without reason), but when you view the AMP spec and what it tries to solve for, it feels like a smart move to help broaden the adoption of sensible but poorly understood optimizations: https://www.ampproject.org/docs/get_started/technical_overvi... Those optimizations are worth looking over even if you don't plan on adopting AMP. I do think that rather than requiri…
Some of those guidelines (avoid style recalculation and use only "GPU-accelerated" animations) are specific to Chrome (and to other browsers of today). Style recalculation is needlessly slow today due to the lack of parallelism and typed CSSOM. And there's no such thing as a "GPU-accelerated" animation, either in the spec or technically: all animations can be run on the GPU with minimal state changes. It's just that…
You know, I think it would be great if web browsers fixed things. AMP is fixing a very real problem that users have today.
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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#36Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#37I haven't seen much on the ad data side of this.
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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#38I haven't seen much on the ad data side of this. 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 t…
Okay but what publisher isn't using DFP, AdSense, or GA. Have you seen the media sites being targeted here? Take any one and watch the dozen or more 3rd party domains it hits. Their data goes everywhere already, including to Google.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#39Shameless plug, but if you care about web performance, my startup, https://rasterize.io provides easy frontend performance monitoring. It tells you how fast users load your site, broken down by desktop vs. mobile, and geography. You can view most of the chrome devtools waterfall information, for every (modern) visitor.
What's the page load overhead in adding this for each user?
It's an 8kB async-loaded JS script, and then it posts a small (1kB) amount of data back to my servers. Overhead should be tiny, and it's async so it won't block page rendering.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#40Earlier quoted context omitted.
Sure, I'd love browser improvements too, but at the end of the day, you can't automatically optimize everything from the browser. The browser can't magically fix a 1MB JS file in , or serving 2000px wide images to iPhones. >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 p…
> Sure, I'd love browser improvements too, but at the end of the day, you can't automatically optimize everything from the browser. The browser can't magically fix a 1MB JS file in , or serving 2000px wide images to iPhones. 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 cy…
> (Note, though, that serving 2000px wide images to iPhones is fixable in the browser, with downscale on decode.) :)
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.