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

171–177 of 177 posts

Re: A new approach to web performance

#171

Post by anonred »

solofounder1 wrote: post #170
felipeerias wrote: post #154

Earlier quoted context omitted.

Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.

In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tra…

While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).

Re: A new approach to web performance

#172

Post by solofounder1 »

anonred wrote: post #171
solofounder1 wrote: post #170

Earlier quoted context omitted.

In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tra…

While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).

I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach.

see https://en.wikipedia.org/wiki/BPCS-Steganography

The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices.

The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility.

As you rightly point out there may be both vectors for either side which neither of us has thought of though.

Re: A new approach to web performance

#173

Post by cramforce »

ttepasse wrote: post #167
cramforce wrote: post #113

Earlier quoted context omitted.

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.

How? Multiple -Element as in Atom with special rel-values? Or a link in the already linked HTML page? There's nothing on that in the Github Wiki and neither on the project page. The superset of HTML is specced, yes, but information on the containing ecosystem is spare.

Yep, we're not done. Being careful with defining this finally because it can basically never be changed. Follow the project for details.

Re: A new approach to web performance

#174

Post by mreiland »

creshal wrote: post #116
mreiland wrote: post #108

Earlier quoted context omitted.

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.

no link?

Re: A new approach to web performance

#175

Post by tvararu »

bitwize wrote: post #159
GFischer wrote: post #109

Earlier quoted context omitted.

It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for. I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it. RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.…

As a distributed platform, the internet has failed. The solution is to rebuild the OS and network from the ground up: http//www.urbit.org /s

I cackled and spat on my screen when I read the /s, well played.

Re: A new approach to web performance

#176

Post by pmlnr »

GFischer wrote: post #109
ducuboy wrote: post #96

Earlier quoted context omitted.

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?

It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for. I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it. RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.…

"Some of these parallels are obvious, and even more or less literal: Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbox is FTP on port 80. Reddit is Usenet on port 80." https://medium.com/@maradydd/on-port-80-d8d6d3443d9a

Re: A new approach to web performance

#177

Post by GFischer »

pmlnr wrote: post #176
GFischer wrote: post #109

Earlier quoted context omitted.

It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for. I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it. RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.…

"Some of these parallels are obvious, and even more or less literal: Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbo…

Good article, it makes the point I was trying to make better than I did.
Post reply on HN