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

11–20 of 177 posts

Re: A new approach to web performance

#11

Post by peterjmag »

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 anything too weird like that.

[1] https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...

[2] https://css-tricks.com/snippets/css/momentum-scrolling-on-io...

EDIT: Turns out there is some -webkit-overflow-scrolling trickery going on[3]. But again, why?

[3] https://github.com/ampproject/amphtml/blob/77d9f31263866e56a...

Re: A new approach to web performance

#12

Post by userbinator »

firasd wrote: post #7
radicalbyte wrote: post #3

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…

About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-​build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for…

Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that.

On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved.

As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept.

build or host their own server-​side analytics or commenting systems

I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.

Re: A new approach to web performance

#13

Post by onewaystreet »

radicalbyte wrote: post #3

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…

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.

Re: A new approach to web performance

#14

Post by joosters »

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…

The scrolling feels unchanged for me, but the top shortcut doesn't work.

In general though, why sites feel the need to change / reimplement scrolling is beyond me. Every reimplementation is worse than the native behaviour.

Re: A new approach to web performance

#15

Post by mpweiher »

radicalbyte wrote: post #3

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…

Excellent point, I never understood that either, with developers being happy that their supercomputing buzzsaw can generate a couple of 100K of text in about a second.

OTOH...it turns out that so-called "static" content actually also requires quite a bit of processing. Apache (or whichever server you are using) is not exactly doing nothing. And it also turns out that this sort of processing is I/O heavy, which isn't exactly the fastest path on the machine, even if all the caching done by various entities (more processing) tries and mostly succeeds in making sure very little I/O actually takes place.

Add to that that moving data around nowadays is generally much more expensive than doing computation on it (several instructions per clock-cyle, multi-Gigahertz clocks, so well over a hundred clocks per main memory access, and millions per I/O, even with an SSD).

In short: if we re-examine our assumptions in light of a changing environment, might a well-optimized "dynamic" stack not be faster than a "static" one? (Compare: VoltDB...). And of course you could then cache the results in memory as well.

Re: A new approach to web performance

#16

Post by mpweiher »

radicalbyte wrote: post #3

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…

Excellent point, I never understood that either, with developers being happy that their supercomputing buzzsaw can generate a couple of 100K of text in about a second.

OTOH...it turns out that so-called "static" content actually also requires quite a bit of processing. Apache (or whichever server you are using) is not exactly doing nothing. And it also turns out that this sort of processing is I/O heavy, which isn't exactly the fastest path on the machine, even if all the caching done by various entities (more processing) tries and mostly succeeds in making sure very little I/O actually takes place.

Add to that that moving data around nowadays is generally much more expensive than doing computation on it (several instructions per clock-cyle, multi-Gigahertz clocks, so well over a hundred clocks per main memory access, and millions per I/O, even with an SSD).

In short: if we re-examine our assumptions in light of a changing environment, might a well-optimized "dynamic" stack not be faster than a "static" one? (Compare: VoltDB...). And of course you could then cache the results in memory as well.

Re: A new approach to web performance

#17

Post by Rifu »

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…

If you take a look at the source[0], you'll notice they roll their own viewport renderer, presumably as a way for them to do their "tracking pixels". I imagine this might be what causes the difference in behavior? If anyone more knowledgeable could jump in, that would be cool.

[0] https://github.com/ampproject/amphtml/blob/master/src/viewpo...

Re: A new approach to web performance

#18

Post by microtonal »

bshimmin wrote: post #5

"With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could…

Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form.

I don't think it will necessarily fail, if AMP has a good ad story.

I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad blocking) and more behaved and subtle advertising, they will choose the latter.

Given that AMP is pushed by Google, it's pretty obvious that they did think about ads:

http://www.wsj.com/articles/what-googles-amp-project-means-f...

Re: A new approach to web performance

#19

Post by betageek »

I'm tremendously not keen on this, but am willing to be persuaded otherwise.

I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO.

I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working overnight.

This looks like Trojans bearing gifts in my (maybe paranoid) mind.

Re: A new approach to web performance

#20

Post by joosters »

I hate it when pages suddenly change their scroll position, it makes reading the site painful. So any project that aims to fix this gets my approval!

One more pet peeve of mine: websites with giant non-scrolling banners at the top of the page. Thanks for wasting my screen space just so you can show your stupid website logo. As well as the pixel wastage, half the sites can't even make their banner stay still, it wobbles slightly as you scroll and it tries to reposition itself. Or, it breaks page scrolling - page up/page down will skip content hidden under the banner.

And while I'm moaning about the web of today: Also annoying are the sites that hide/shrink the banner as you scroll down the page, but make it pop back up as soon as you scroll upwards. If you accidentally move slightly too far down a page, you shift back up a row or two to catch a missing line of text, only to find a banner popping up and obscuring the bit that you specifically tried to view. Argh!

Post reply on HN