Live data from Hacker News

A new approach to web performance

ampproject.org

31–40 of 177 posts

Re: A new approach to web performance

#31

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it. Sometimes a strong incentive is needed to change things.

I think the sad part is that it isn't common practice and a standard has to be made.

Re: A new approach to web performance

#32

Earlier quoted context omitted.

Because many publishers found that visitors wont wait the few extra seconds it takes to load the content on the server. They need to see something loading in their browser or they abandon the content.

Then show them an AJAX spinner while fetching the static site in the background.

That's what one of the Blogger templates does, and I've seen people on HN complain about having to see an AJAX spinner just to load a blog.

Re: A new approach to web performance

#33
I suspect that the issue of web performance is less a technical problem than an organisational one. We have the technology to build performant pages right now, as well as best practises — they're just not used pervasively enough. As long as the business processes that produce the slow pages don't change, no shift in technology alone can save us.

Re: A new approach to web performance

#34

Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…

At one point gamefaqs.com would generate static pages and serve those everywhere it could. This was before cnet bought the site though, I have no idea what they do nowadays, your post just reminded me of it.

Re: A new approach to web performance

#35

Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…

At one point gamefaqs.com would generate static pages and serve those everywhere it could. This was before cnet bought the site though, I have no idea what they do nowadays, your post just reminded me of it.

It doesn't matter much, the 70+ embedded youtube videos some users put into their FAQs will kill your browser either way.

Re: A new approach to web performance

#36
I don't seem to understand what this is for. If you want a fast loading page, don't add slow stuff to it.

What new is AMP bringing to the table? It seems to be some kind of a framework? Is it code or is it a preprocessor or what is it?

Re: A new approach to web performance

#37

Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…

Well, I would say the common argument is that you send an intermediate format to decouple yourself from the specifics of the receiver. HTML is an intermediate format and the client is free to render it how it sees fit for the device on which it is running, which allows compatibility with newer and different clients.

It's like shipping some intermediate bytecode doesn't seem to make sense, because every client needs to compile it, until you realize it allows you to ship one format that can even be used by many different architectures and even new architectures that didn't exist when you emitted the bytecode. At the cost of a second component that needs to be present on the machine to do the compiling.

When a vast majority of clients is the same or sufficiently similar, it may of course make sense to offer an optimized format, that requires less client-side processing But what would such an optimized format for the web be?

Re: A new approach to web performance

#38
What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.

This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as and that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.

Post reply on HN