Hacker News Reader

Comment by rasz | Hacker News Reader

Im actually surprised how good YT comes out in this. The page is a dumpster fire:

Before Polymer (current YT framework) YT video page weighted somewhere around 50KB (10KB compressed) and was ordinary HTML + 1MB js player (400KB compressed). As soon as HTML part loaded the page was all there.

Now its 600KB (100KB compressed) JSON + additional 8MB desktop_polymer.js (1MB compressed) that needs to be compiled/interpreted before it even starts building the page client side and anything starts showing up. 1MB js player is on top of that.

View on HN

It truly is a terribly site, in terms of performance. Streaming HD content used to be the "hard problem", but now it's displaying the site hosting the videos that the issue.

You can stream HD content on the lowest end device, or hardware almost 10 years old. The same hardware just isn't powerful enough to let you use the YouTube website in a performant way. I cannot fathom how YouTube doesn't see that as a problem.

How many people, especially among the best advertising demographics, have 10 year old hardware? I have had 6 computers in that timeframe and 4 phones.

Running a 2012 Mac Mini as a HTPC. It's been wonderful for anything h.264 and has no problems even playing 4K files (h.264, it chokes on 265 of course).

But YouTube is increasingly becoming unusable to the point where I just youtube-dl what I want to watch in advance.

I'm amazed at how much slower Youtube has gotten in the past couple of years. That fake paint stuff is terrible too.

Here's something to try, resize youtube horizontally and watch your browser grind to a halt. At least in the case of Chrome for me.

YouTube even fakes FCP by initially showing a lot of dummy grey boxes until they have any idea of what to really show.

These so-called skeleton screens are a common technique and not inherently bad.

When you know an elements exact dimensions but not its contents and have more important things to serve first, it’s completely valid to use.

It gets infuriating when these grey boxes animate about but them decide not to display anything anyway and just collapse. Or they load and load and load and not account for network errors. Or when the box sizes has nothing to do with the size of the element it’s being a placeholder for.

> These so-called skeleton screens are a common technique and not inherently bad.

The technique may not be bad by itself, but it's so common mostly among super bloated website behemoths that every time I see those skeleton screens I automatically prepare myself for another 5 second of loading.

It's the modern web equivalent of seeing an hourglass cursor on an underpowered Vista machine - not inherently bad but usually a bad omen.

Can't argue with that.

It's easier to randomly place grey boxes around a page than to address the real problems. Plus you get to lecture people with terms like "perceived performance".

Did we forget wombocom so quickly? A big part of the joke was that loading screens (of any kind) on sites are really stupid.

Link in case anyone doesn’t know what this is referring to (I think)

https://www.zombo.com/

(Appears to have been upgraded to HTTPS and other modernities!)

"Do not trust any statistics you did not fake yourself."

It's astonishing how much worse they made it - and intentionally made it worse in browsers without Web Components, like Firefox. Forcing the old non-Polymer website was like hitting the turbo button on an old PC.

It wasn't Web Components (Firefox supports those[0]) it was Shadow DOM v0, the original deprecated Chrome-only predecessor to Web Components. Except it has been removed from Chrome now so I don't think this is an issue anymore.

[0]: https://caniuse.com/custom-elementsv1

Well that would be why it's so much slower than it use to be! HN is one of the last bastions of fast sites :(

Anyone observed similar increase in overhead after ionic migrated from angular component into web component ?

Reply on news.ycombinator.com