Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new approach to web performance

ampproject.org

Post reply on HN
Print view View original

111–120 of 177 posts

Re: A new approach to web performance

#111

Post by coldtea »

ducuboy wrote: post #96
coldtea wrote: post #84

Earlier quoted context omitted.

> Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. If a single company killing a sigle product could kill RSS, then it wasn't that alive in the first place. The fact is, after 10 years of RSS being available in blogs, news sites and elsewhere, Reader still had an insignificant number of users in the web scale of things. A…

Ok but that still shows how much Google cares about open standards. And did you just say "few tens of millions" of users is insignificant? How many users are we here on Hacker News again?

>And did you just say "few tens of millions" of users is insignificant?

Yes.

>How many users are we here on Hacker News again?

I'd say well under a million (or around that at most). What does that have to do with anything? Did anybody say that HN has a significant amount of users web-wise?

Slashdot and then Digg, which were both something like 100 times HN in size fell off the side and nobody much cared.

Re: A new approach to web performance

#112

Post by z3t4 »

The problem is that publishers want to know everything about their users, so they add tons of "spyware" that slow down the site.

Who does already know EVERYTHING about your users? But can they sell it?

startup idea: Make a blazingly fast CMS that tracks everything and show pretty graphs.

Re: A new approach to web performance

#113

Post by cramforce »

ducuboy wrote: post #59
ducuboy wrote: post #43

Earlier quoted context omitted.

AMP is just broken HTML, hardly a standard. https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...

What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers. Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.

This is kind of orthogonal to RSS. AMP and RSS work great together. Your feed reader can detect that the feed item URL has an AMP alternate and chose to display that instead.

Re: A new approach to web performance

#114

Post by ino »

peterjmag wrote: post #11

Two scrolling behaviors that I found odd on this page and on the NY Times example[1] on iOS: - You can't scroll to the top by tapping the status bar. - The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail). Anyone know how/why? I thought it might be some -webkit-overflow-scrolling trickery[2] with a full-size container div or something, but I don't see an…

-webkit-overflow-scrolling makes scrolling feel like native, important for web apps and web views. It's like when you make an overflow: scroll div, and you make your main content inside this it.

It also ads the permanent url bar at the top and the navigational arrows at the bottom. This is useful for some web apps, because if those weren't permanent, you couldn't have buttons fixed on the bottom. This is because when you would click them, the back/forward arrows bar would appear pushing your button up so you have to click it again.

I used to use it but I've stopped because it's a whole level of complexity on your complex app.

I wish iOS safari scrolling would feel like native. Many people are using this property for this reason only, sacrificing screen space (the always-on browser interface). It used to be worse with the small screen of the iPhone 4.

Re: A new approach to web performance

#115

Post by ducuboy »

cramforce wrote: post #100
ducuboy wrote: post #76

Earlier quoted context omitted.

A platform for sharing ad revenue. They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.

Many ad networks are supported already, all will be. There is no rev share at all.

Of course this can't be DoubleClick only.

But please tell us more about the business model, I see you're a Google employee.

Re: A new approach to web performance

#116

Post by creshal »

mreiland wrote: post #108
creshal wrote: post #35

Earlier quoted context omitted.

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

Can you link to an example of this? I've been on gamefaqs since the very beginning and I've never seen that. In fact, the vast majority of FAQs on that site are still text.

One of the MGSV walkthroughs was my most recent run-in to this.

Re: A new approach to web performance

#117

Post by cramforce »

ducuboy wrote: post #115
cramforce wrote: post #100

Earlier quoted context omitted.

Many ad networks are supported already, all will be. There is no rev share at all.

Of course this can't be DoubleClick only. But please tell us more about the business model, I see you're a Google employee.

Business model is the same as any other content website. Monetization through ads, paywalls, etc.

Same as before, just with happier users including myself. Happy users are good for business in the long term.

Re: A new approach to web performance

#118

Post by kostarelo »

manigandham wrote: post #2

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...

Did just this page disabled my Ad Blocker????

Re: A new approach to web performance

#119

Post by TazeTSchnitzel »

spankalee wrote: post #97
TazeTSchnitzel wrote: post #83

Earlier quoted context omitted.

It's not a subset, it's not a superset. It lacks some HTML things and adds new ones.

Custom elements are a part of HTML, they can be part of a subset. Disqualifying custom elements from an HTML subset would be like claiming function declarations can't be in subsets of JavaScript.

That's not really the same... HTML elements are more like keywords than functions.

Re: A new approach to web performance

#120

Post by pookeh »

pjc50 wrote: post #77
ducuboy wrote: post #76

Earlier quoted context omitted.

A platform for sharing ad revenue. They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.

If they're putting ads in custom tags that makes it extremely easy to block them. I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.

It also becomes extremely easy for browser vendors to not allow blocking them.
Post reply on HN