Shameless 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.
Google Seeks to Pacify Consumers with Faster Mobile Pages
21–30 of 50 posts
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#22I've already gone to great lengths to optimize my mobile site. I am fully confident that AMP cannot possibly make my site any faster. Every page on my site loads via a single HTTP request that transfers 10k of gzipped JS and HTML all at once. Loading an additional script with an extra request for another JS file is completely against my mobile design principles. Should people like me start using AMP anyway to stay re…
AMP does more than just minimize network requests or JS loading size, it structures the page so that browsers can render it faster as well. (that is, controlling for network download and JS parse time)
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#23There'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…
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 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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#24Earlier quoted context omitted.
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…
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 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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#25Earlier quoted context omitted.
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…
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 (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 :)
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#26I still think this is a pointless nonsense. Anybody who is going to bother implementing AMP will be equally capable of implementing well-optimised standards-compliant web pages, with the bonus of not having to use this silly restricted format.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#27There'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…
Google has repeatedly said that they will not give preferential treatment for AMP pages. Almost every publication [1] and comment I've seen gets this wrong.
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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#28I've already gone to great lengths to optimize my mobile site. I am fully confident that AMP cannot possibly make my site any faster. Every page on my site loads via a single HTTP request that transfers 10k of gzipped JS and HTML all at once. Loading an additional script with an extra request for another JS file is completely against my mobile design principles. Should people like me start using AMP anyway to stay re…
:) AMP isn't for you then. Honestly your site is probably better than AMP could ever be just inherent in the fact your site doesn't need a library enforcing rules, but thats not the point of AMP. AMP is for forcing news sites to do similar things to what I assume you have already done.
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.
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#29There are two articles about AMP on the front page right now, this one and https://news.ycombinator.com/item?id=11167428. Which is better?
Re: Google Seeks to Pacify Consumers with Faster Mobile Pages
#30Not kicking me to a full screen ad for their gmail app every time I log in to gmail would be a nice start.
[deleted]