Web App Speed • Hacker News Board

Re: Web App Speed

#11

Post by anilgulecha » Mon, Jun 01, 2015, 3:50 AM UTC

userbinator wrote: post #8

olalonde wrote: post #4

Earlier quoted context omitted.

On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site...

I understand the reasoning but I don't agree with their implementation, because it essentially favours large sites run by those who can afford the faster infrastructure, while penalising the small ones that may actually have more relevant and detailed content but not very fast servers. Sites which load much faster get a ranking advantage even if they offer only superficial lower-quality content. Maybe if they didn't…

Interesting take.

I'd hedge that 95-99% of alexa top 1000 sites could be delivered under 30kb -- just content+ css. (assuming ajax/video/fonts are asyncronous in google's algo and not counted towards load time).

In which case it's easy even for the cheapest AWS server to host and server instantaneously. I think the bigger sites have a distinct disadvantage -- they have so many tracking and ad resources, that it kills their load time.

Re: Web App Speed

#12

Post by tedunangst » Mon, Jun 01, 2015, 4:38 AM UTC

olalonde wrote: post #4

Detrus wrote: post #3

Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. In the Flash vs HTML5 iPhone wars, people argued that if Flash was hated because of the developers who abused it, what's going to stop the same thing happening to HTML5/JS/canvas? It's happening. Usually not on some interactive visuali…

On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site...

Ironic, since blogspot is a prime offender for showing a blank page while the js gears turn and grind until the article text finally appears.

Re: Web App Speed

#13

Post by bottled_poe » Mon, Jun 01, 2015, 4:54 AM UTC

est wrote: post #10

tl wrote: post #6

Earlier quoted context omitted.

> Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. That's one reason. The other reason is that all Flash runtimes other than the heavily-optimizied primary implementation for Windows universally suck. That ends up being a rather large pain point when developers are more likely than a…

To be fair, in Linux, X window GUI sucks in general. For Mac system, everything besides Quicktime sucks. Also NPAPI sucks compared with ActiveX. Flash in its original popularity was its vector animation streaming capability, think SVG withe a timeline with streaming. Plus a decent ECMA scripting environment, and later hardware accelerated 3D apis and C++ compilation support. It's a good platform past its prime time a…

> "caught in a marketing controversy in an unfortunate mobile age."

I understand this argument, but I don't believe that this was primarily a marketing war. Browser plugins are dirty, they always have been. It is not surprising that the latest web standards are attempting to plug this gaping security hole.

Furthermore, all of the features you have listed were only implemented because Adobe had a huge financial monopoly on the technology.

Re: Web App Speed

#14

Post by est » Mon, Jun 01, 2015, 5:28 AM UTC

bottled_poe wrote: post #13

est wrote: post #10

Earlier quoted context omitted.

To be fair, in Linux, X window GUI sucks in general. For Mac system, everything besides Quicktime sucks. Also NPAPI sucks compared with ActiveX. Flash in its original popularity was its vector animation streaming capability, think SVG withe a timeline with streaming. Plus a decent ECMA scripting environment, and later hardware accelerated 3D apis and C++ compilation support. It's a good platform past its prime time a…

> "caught in a marketing controversy in an unfortunate mobile age." I understand this argument, but I don't believe that this was primarily a marketing war. Browser plugins are dirty, they always have been. It is not surprising that the latest web standards are attempting to plug this gaping security hole. Furthermore, all of the features you have listed were only implemented because Adobe had a huge financial monopo…

No, abused and over-powered browser plugins are dirty.

Quicktime is a plugin, do you feel its presence? Yet WWDC video pages were not HTML5 compatible and using Quicktime plugin.

The same applies to Canvas or SVG, yes they are standards, but their performance will suck worse than Flash if advertisers start abuse animations with canvas. Best part, you can not disable canvas like you can with Flash.

Re: Web App Speed

#15

Post by justin_d » Mon, Jun 01, 2015, 5:35 AM UTC

There are issues however with the way that some browsers render canvas, particularly stock browsers. I've had wildly different fps on different browsers.

Re: Web App Speed

#16

Post by jwr » Mon, Jun 01, 2015, 6:06 AM UTC

tedunangst wrote: post #12

olalonde wrote: post #4

Earlier quoted context omitted.

On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site...

Ironic, since blogspot is a prime offender for showing a blank page while the js gears turn and grind until the article text finally appears.

It also breaks scrolling and zooming. I was hoping someone would mention that.

"Do as I say, not as I do".

Re: Web App Speed

#17

Post by jakobegger » Mon, Jun 01, 2015, 6:23 AM UTC

anilgulecha wrote: post #11

userbinator wrote: post #8

Earlier quoted context omitted.

I understand the reasoning but I don't agree with their implementation, because it essentially favours large sites run by those who can afford the faster infrastructure, while penalising the small ones that may actually have more relevant and detailed content but not very fast servers. Sites which load much faster get a ranking advantage even if they offer only superficial lower-quality content. Maybe if they didn't…

Interesting take. I'd hedge that 95-99% of alexa top 1000 sites could be delivered under 30kb -- just content+ css. (assuming ajax/video/fonts are asyncronous in google's algo and not counted towards load time). In which case it's easy even for the cheapest AWS server to host and server instantaneously. I think the bigger sites have a distinct disadvantage -- they have so many tracking and ad resources, that it kills…

Yup. For my company website I made sure that most pages require just a single request to render: CSS is inlined and (small) scripts are loaded at the bottom of the page. This means that even when hosting it on a crappy host, without a CDN, you get stellar page load performance.

Re: Web App Speed

#18

Post by logotype » Mon, Jun 01, 2015, 6:31 AM UTC

jscottmiller wrote: post #7

Absolutely agree with respect to ads. While the steady state performance of most banner ads is fine, loading new ads often force large javascript files to be fetched and parsed as well as needless reflows. On our game building site [1], we try to refresh ads only during natural breaks in gameplay (level changes). While this doesn't improve the loading time, it does help to shift the disruption to a time when it is le…

well, it's not surprising web apps are slow. as an example, 1dash1.com mentioned above: 57.480 lines of JS across 8 separate domains. and the result? site is loading slow (at least on my 500MBit/s fiber connection) and the browser is executing a lot of stuff, most of which is not really efficient or time sensitive (or required). this is how most sites does it, it has to be better ways.

Re: Web App Speed

#19

Post by rimantas » Mon, Jun 01, 2015, 7:59 AM UTC

thekingshorses wrote: post #5

supster wrote: post #2

People are using the canvas now to achieve fast speeds on mobile web. See Flipboard's post on this [1]. The big issue ppl brought up was that using canvas instead of DOM meant losing accessibility. Btw Flipboard released an interesting framework called React-Canvas[2] based on their efforts. 1. http://engineering.flipboard.com/2015/02/mobile-web/ 2. https://github.com/Flipboard/react-canvas

Flipboard assumed DOM is slow. I don't even think they created a prototype to see how slow DOM is. I implemented this in few hours. Works on iOS, Android 4+ and WP - Demo for mobile: http://premii.com/play/flipboard-style-news/ - I am using it in real app here. http://reddit.premii.com/#/r/news/

DOM is slow. And your example on iPhone 6… well it „works“, but for sure it does not work well.

Re: Web App Speed

#20

Post by xorcist » Mon, Jun 01, 2015, 8:07 AM UTC

est wrote: post #10

tl wrote: post #6

Earlier quoted context omitted.

> Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. That's one reason. The other reason is that all Flash runtimes other than the heavily-optimizied primary implementation for Windows universally suck. That ends up being a rather large pain point when developers are more likely than a…

To be fair, in Linux, X window GUI sucks in general. For Mac system, everything besides Quicktime sucks. Also NPAPI sucks compared with ActiveX. Flash in its original popularity was its vector animation streaming capability, think SVG withe a timeline with streaming. Plus a decent ECMA scripting environment, and later hardware accelerated 3D apis and C++ compilation support. It's a good platform past its prime time a…

Flash was always very buggy. Perhaps you didn't see them if you kept to a strict web developer subset of Flash. But the problem was that it had a different set of bugs on every platform. I guess that codebase was very old and could have been shared better between platforms. So at least for for non-Windows users that meant the plugin crashed daily on whatever input you happened upon on the web.

It also had (and still has) an enormous set of language features, a billion codecs, a handful of protocols and several different scripting languages, a vanishingly small subset of which was still maintained. The result was probably the most insecure software ever to grace the face of the Earth. Running by default. Taking input on every web page you ever visited.

So it was never just a "marketing controversy". Sure, Apple and Adobe could never agree on the terms for flash on non-Mac devices. But that alone would never have been enough for the demise of Flash. Google, and to a lesser extent Microsoft, did large parts of the work. They were rightfully concerned not just with Flash as a vector for malware, but also the power it brought to Adobe who could single handedly decide what Flash would run and on which platforms.