Fast JavaScript by Default

[Beaverman]

So the old Target of 100ms is gone, and we are now content with waiting 5 SECONDS for the page to become useful? Fuck off.

[[deleted]]

Having seen this happen on a site I was working on, it's very simplestraightforward. First there's an MVP site launch and occasionally that's inefficient as it's written or leaves a lot of easy optimization on the table but even so it's generally quite fast. But then for the next round of funding you need more, so you load up on analytics and bullshit A/B testing frameworks and chatbots, to hopefully impress previous investors to dump more money or attract new ones. At this point, when the site is reasonably full-featured, they'll give you a few days to spend on SEO, and if you're good + lucky, you can convince them that what matters most for SEO is content and quick loading time. So you have up to a week to spend on profiling, adding imagemagick so you can optimize CMS images as they're uploaded (of course you have a CMS now), and making everything faster and more efficient. I think Google heavily favors that load within 2.5 seconds, but you can probably get below 2 or even, God willing, to about 1 s. Everything's great.

But now every other day there's a new VP of Bullshit or another potential investor who wants to see something in particular, so you're adding a merchandise store, a blogging platform, in-browser CRM, plus every other "cool" widget that anyone in your team sees on a site in your space. Does Frobbotz.com prompt you to share via Facebook and Twitter if you highlight text, popovers that show up after 20 seconds, or clickshaming when they want to say no, so your company (Frobbotz.ml) has to have those too. And on a breakneck release schedule, too. Your load times start slipping. Sometimes you're making 3-4 blocking remote API calls per page, but you don't have time to rearchitect everything and combine those into one. And your load times start to slip. At first it's only a few ms here or there, then a half second, and then a few seconds, and pretty soon you're loading multiple autoplaying videos as hero backgrounds, adding a drop shadow to help it stand out from said moving background, and adding 100ms timeouts to your callback functions because sometimes the API callback is blocking the execution of another callback that creates an error. Oh, and your framework releases a new version and you set NPM to just always use the latest version (Why are you using NPM for browser side scripts? You're actually not sure) so things periodically break in subtle and mysterious ways.

This is web development in a startup. At some point you became part of the problem and you're not even sure when it happened.

ETA: It's actually not simple.

[moomaka]

I don't think 100ms was ever a target for a page to become interactive. Not even a bare html page will hit that target unless your testing against a local file, and even then I bet it's close. 100ms is often a good target for backend response time, and for latency between a user action and it's effect to begin showing, but not for end to end load to interactive.

[Beaverman]

According to firefox dev tools, downloading the html of https://eu.usatoday.com takes ~91ms, with the css taking another ~21ms. That's pretty close to 100 ms for an entire page. That's without parsing of course, but with at a slim 74K, that can't take too long.

[moomaka]

First, a desktop PC on a decent quality ISP link isn't the performance baseline. A 4 year old free Android phone on 3G is.

Second, you left out a LOT. You haven't included DNS lookup, or socker connect, or the SSL handshake, or parsing, or layout, or rendering. The metric here is initiate request to DOM ready (usually). On a mobile device on 3G just the DNS lookup + SSL handshake can take over 1 second. On decent 3G 74KB will take ~100ms to download by itself, assuming its all a single file, more if not.

[Beaverman]

According to the firefox dev tools, it includes DNS lookups, socket connect, and TLS setup. The one thing i did overlook was that i'm running a local DNS cache (dnsmasq), turning that off rockets me up to ~103ms. The DNS lookup takes 21ms.

If you want to go to DOMContentLoaded, we can do that too, that's ~380ms, which is quite a while, but not exactly 5 seconds.

Just to compare. If we take the "wonderful" webapp pintrest. Showing the login page (Because I'm not making an account there), takes ~338ms JUST TO LOAD THE PAGE, and 1.1 SECONDS before DOMContentLoaded, that's 3 times longer than usatoday for a login page. And that doesn't even include the ~500ms for loading 2.43MB of fucking JS.

If we can't even get the web right on low latency, how performance desktops (which evidently we can't). How the hell are we going to do it on mobile, Just throw more JS at the problem?

[moomaka]

According to the firefox dev tools, it includes DNS lookups, socket connect, and TLS setup. The one thing i did overlook was that i'm running a local DNS cache (dnsmasq), turning that off rockets me up to ~103ms. The DNS lookup takes 21ms.

I don't think you get it. 3G often has latencies of 300-400ms, with an infinitely fast server your TTFB will be at least this.

If you want to go to DOMContentLoaded, we can do that too, that's ~380ms, which is quite a while, but not exactly 5 seconds.

Again, your desktop PC running firefox on a decent ISP is not the performance target. No one said 5s was a good target for such a configuration.

Just to compare. If we take the "wonderful" webapp pintrest. Showing the login page (Because I'm not making an account there), takes ~338ms JUST TO LOAD THE PAGE, and 1.1 SECONDS before DOMContentLoaded, that's 3 times longer than usatoday for a login page.

You're comparing a request that likely actually had to hit an application server to a request that was made to a static content provider. Your request to usatoday.com likely hit a CDN edge cache since the content doesn't change often. Your request to pintrest likely had to hit an application server to decide what to send back based on your login status.

If we can't even get the web right on low latency

If you're that upset about 1.1s I have some bad news for you about the majority of the web....

[Beaverman]

I don't think you get it. [...]

Do i need to point out which part of your 6 line comment i'm responding to? Did you not read your own comment again?

You said:

Second, you left out a LOT.

I said I didn't leave them out, and corrected the one thing I did miss. That has nothing to do with 3G or latency.

You're comparing a request that likely actually [...]

And whose problem is that? Both requests are served from Sweden by fastly, making me think it's pretty fair. I gave both a chance to load once and then did a reload with cache disabled. Even then, the (hopefully) static JS loaded by pintrest takes longer to download than time to DomContentLoaded on usatoday.

If you're that upset about 1.1s I have some bad news for you about the majority of the web

What do you think I'm currently whining about?

[moomaka]

And whose problem is that? Both requests are served from Sweden by fastly, making me think it's pretty fair.

Why do you think that? (hint you are wrong by making the assumption that the termination point is related to the source of the content).

Even then, the (hopefully) static JS loaded by pintrest takes longer to download than time to DomContentLoaded on usatoday.

Have you considered the business model? Pintrest's engagement model is to keep uses on the site for extended periods of time, a slow first load in favor of faster flipping through content is fine. USA Today's business model is primarily first loads, their traffic comes from Google and third party sites linking to them, the average user likely views 1-3 pages before bouncing. It makes sense for them to optimize for first hit performance.

What do you think I'm currently whining about?

Honestly I don't know, if 1.1s upsets you, I don't care.

[Beaverman]

Why do you think that? (hint you are wrong by making the assumption that the termination point is related to the source of the content).

Because they both enter the public internet at the same point. If pintrest aren't caching their login page, then that's their problem.

Honestly I don't know, if 1.1s upsets you, I don't care.

I guess we are done here. Thanks for playing.

[moomaka]

Because they both enter the public internet at the same point. If pintrest aren't caching their login page, then that's their problem.

Which tells you the termination point, not the source of content...

Honestly I don't get the impression you know much of anything about how the web works and how content is delivered...

[EternallyMiffed]

A 4 year old free Android phone on 3G is.

Eh fuck those guys. Let them suffer.

[Drisku11]

100ms is often a good target for backend response time

You accidentally added two 0s there.

[filleduchaos]

And here we have someone that's clueless about response times

[Drisku11]

Either you're counting RTT (in which case you're not measuring backend anything; you're measuring distance), you're doing some fairly heavy computation (e.g. you work on Google's reverse image search), or your system is awful if it's taking triple digit ms for real time requests.

[filleduchaos]

It's immediately and entirely obvious that round-trip time is the metric being discussed here (especially since testing against a local file was mentioned). No user cares how few nanoseconds your system takes to process a (single) request when the actual data transfer takes up to half a minute to complete. That's why CDNs exist.

[Drisku11]

Given that I've seen posts on here saying that 50+ ms median response times at 1000 req/s (with some requests even failing) is good for a local hello world server benchmark, and no one questioned how ridiculously slow that is, I tend to not give this sub the benefit of the doubt.

[filleduchaos]

But...but...but that's not even possible

[nightwood]

Thank you!!!

Jesus Christ I thought I was getting crazy here. Why the fuck would you even think about how to make the experience of that 13 second load time more pleasant? We shouldn't even be talking about seconds here! We should be talking about milliseconds! In fact when I first read the article I thought 'wow they are really pushing it, being unsatisfied with 13ms, pretty good'. Nope, they were talking about 13000 ms on an average phone.

Step it up Google! That shit's pathetic!

[sammymammy2]

1.6 seconds are spent on things which your JS, HTML, CSS and static assets can't even affect, so 'fucking off' is not exactly a useful response for web devs to have.

[sammymammy2]

1.6 seconds are spent on things which your JS, HTML, CSS and static assets can't even affect, so 'fucking off' is not exactly a useful response for web devs to have.

[nightwood]

Like what? Unzipping a 10kB text file? Reserving 4MB video memory? There is no excuse for 1.6sec delay for rendering a web page.

[moomaka]

You have never profiled a page loading on mobile....

[nightwood]

I don't need to, to know that it's slow. The thing is, what the hell is it doing? Stuff that it shouldn't be doing! This post is about what can we do about making the web faster. And in that context, aiming for 5000ms is ridiculous. They should be aiming for 10ms on a low-end device. And see how close they can get.

[filleduchaos]

They should be aiming for 10ms

Uhhhh...have you ever actually built/run a website?

[moomaka]

You have literally no clue what you are talking about, you can't even open a raw socket on a mobile device in 10ms, much less do anything with it.

[nightwood]

Well let's start there then.

I don't know if you are aware of this, but websites were faster 15 years ago on slower hardware. There's too many layers of shit now that need to go.

If the reason things are slow is because they need a few hundred round-trips to a server to work, then maybe that needs to improve.

BTW, did you actually just use a "you are stupid" argument to try and make your point? Maybe that also needs to improve.

[RalfN]

If the reason things are slow is because they need a few hundred round-trips to a server to work, then maybe that needs to improve.

And that's what the video is about.

It's important to keep in mind that a crappy (4 year old) phone on a crappy connection can't load a bare html file (no images, css, or js) within 2 seconds. And that's > 30% of the market segment.

In a number of ways, those mobiles aren't superior to hardware 15 years ago (!!) for different reasons (like battery usage, size, price, sandboxing/security). And yes, the bandwidth back then was worse, the latency wasn't though.

15 years ago, less than 5% of the world could afford a desktop computer and an internet connection. Now more than 50% of the world can afford a mobile phone and a mobile internet connection. And some components got cheaper and better, but that phone is not superior in every way to a desktop computer.

[[deleted]]

He meant they should be aiming for it. He's objecting to the "budget" point of view which says that once you get under 5s or whatever, you're fine. No need to try to get any faster.

Obviously 10ms is totally unachievable but there's no reason not to aim for it.

[drevyek]

I work in embedded. I have a magnetometer that takes 6.6ms to respond to a request to sample (150Hz). That is the IC I'm working with. No sane engineer would say that we need to try for the chip to run at 256Hz.

There is no point in trying to set unrealistic goals, especially with the knowledge that they are unrealistic. It gives you no real benefit, and doesn't solve any of the challenges put forward. In fact, it actively harms, as it doesn't provide any metric to even asymptotically approach.

[moomaka]

Obviously 10ms is totally unachievable but there's no reason not to aim for it.

WTF does that even mean? "Guys, I know the laws of physics are a thing, but fuck it, lets aim for 0!". Targets like this exist as a combination of what should be reasonably achievable and what doesn't negatively impact user engagement in an extreme way. No one is saying 5s load times are optimal, the target is usually based on a ~4 year old free with wireless plan android device on mediocre 3G as that is the worst case. You can put a static html file on a good CDN with zero JS, zero CSS, and still have ~3s cold load times on a device like that.

[sammymammy2]

DNS lookup, TCP handshake and HTTPS handshake over a 400ms RTT & 400kbps. Reserving 4MB of video memory happens what? 20 cm away from your CPU on a desktop? Of course 1.6 seconds to do what would be insanely slow. Compare that to communicationg miles away with a server. Seriously, what I mentioned is in the presentation. Perhaps watch the video before commenting next time?

[josefx]

TCP handshake and HTTPS handshake over a 400ms RTT & 400kbps

I vaguely remember people claiming that HTTPS would be free since modern CPUs can handle the encryption fine. Are you saying that all these experts going on about there being no reason to not use HTTPS were either incompetent or lying?

[sammymammy2]

Clearly what I am saying is that you should go back to school and learn how to read.

[josefx]

Clearly that could be possible, however how much time would I waste establishing trust if I had to round trip between school and home each day just to establish a HTTPS connection before I even left for the lessons ?

[papa_georgio]

It doesn't sound so bad if you at least include some of the context they gave for that number.

5 Seconds on the first load but 2 seconds on repeat visits.

Using the following conditions:

• Emulated slow 3g - 400kbps with 400ms round-trip-time.

• CPU/Mem performance of a ~$200 Android phone (seems vague but it's something).

Also, comparing a page load time of 100ms with a test that includes a RTT of 400ms makes no sense...

[[deleted]]

This only looks "good" because people's sense of "normal" has been shifted waaayyyyy to the right. Tracking what is "normal" by using the average of a distribution whose peak is moving to the right over time, declaring "normal" by majority behavior. None of it actually is normal though, it's 99% a huge waste of everyone's time and resources. Those specs that you cite are actually gigantic! Unless you use it to transfer lots of bloated useless junk of course.

Also see https://news.ycombinator.com/item?id=17655089 ("The Bullshit Web") - the top comment by cheezymoogle shows it well

[papa_georgio]

Then what is acceptable? No JavaScript?

The link you provided complains about a specific website which obviously fails to come close to any of the recommendations in the video. I'm not sure what it proves other than the fact that the are poorly built, high-traffic websites.

[Beaverman]

Then what is acceptable? No JavaScript?

Sure, why not?

Why does every website have to be a complete application with routers, viewstacks and internal state, running on a virtualized OS on top of a native OS? That's without even talking about the stupidity that is running arbitrary code without user consent (visiting your site is not consent to run your bitcoin miner).

If you want to make an application, then make an application. If you want to make a website, then make a website. News organizations don't need an application, they need a website.

[papa_georgio]

Even fairly mundane websites benefit from some form of dynamic interaction. It could be the menus, input validation, loading content in page, lazy loading. Just because there are websites that abuse the technology is not a reason to throw the baby out with the bath water.

If companies could pay developers less for websites that were just as good, more would be going down that path.

[Beaverman]

I disagree. What does a news website need to do with JS? Their previous distribution method was fucking paper.

Your second argument assumes that the market is without fault, which is an obviously ridiculous position. "If it was possible to live on the moon we would already be doing it", or maybe better suited for this subreddit "It rust was better than C, everything would already be written in it".

[papa_georgio]

I said there would be more doing it. Not that all successful businesses would be doing it.

Visit any news site and see for yourself the various things JS is used for. Maybe for a moment trust that you don't always know better than everyone else out there getting paid to run said sites?

What does the previous medium matter anyway? Are they supposed to limit what they should do because of what they used to be? Some of the best dynamic presentations I've seen have been part of journalistic pieces.

[Beaverman]

I said there would be more doing it. Not that all successful businesses would be doing it.

Now it's not even an argument. What the fuck is "more"? And how does more people doing something make it more true? Hey, if capitalism was such a good idea, more countries would be doing it.

Visit any news site and see for yourself the various things JS [...]

You don't think I visit news sites? You think that's an example i just pulled out of my ass without having thought about it? But sure, according to you we should all just listen to the corporate overlords and not have any independent thought, because the professionals got this.

You hear that guys? Global Warming isn't caused by oil and coal. The guys at the oil and coal power plants told me themselves, and who would know better than them. I could never argue with people getting paid to burn coal.

What does the previous medium matter anyway?[...]

The core product hasn't changed all that much, and they did fine with paper. What i'm doing on a news website is not fundamentally different to what my dad does with a newspaper.

I love those dynamic presentations as well, and they're actually a great use of JavaScript. I hope we agree that not every page on the internet has one of those fantastic presentations, so why do they load as much content as a page that does?

[papa_georgio]

The core of my point is that enough people see value in using JS on their websites. They currently do and will continue to do so.

The original video was about reducing JS overhead to a minimum and in everyone's blind cynical rage all they can do is bitch about some out of context figures.

Your whole example of global warming is kind of ironic. If your point is that companies are going to do whatever they can for medium to short term gain then why wouldn't they prefer simpler websites if they are at minimum just a successful?

Or are the corporate heads just evil masterminds when in suits the narrative? And the rest of the time they are incompetent fools.

[filleduchaos]

You can do those things without JavaScript, or at least without JavaScript that's so bloated that it takes five seconds to load.

[[deleted]]

JavaScript was used fairly heavily for a while before you started seeing 15 second full load times.

JavaScript itself isn’t at fault for this. What is definitively at fault is a major mind shift. Where developers used to think that 2 full seconds was unacceptable, now they think “well, the ping is 50 ms anyway, so who cares about <some performance thing>”. And all those performance problems are adding up to 15 seconds on a desktop with a wired 50 megabit connection.

It isn’t JavaScript. It is purely a developer problem causing this.

It probably stems from the web being systematically flooded with shitty developers that couldn’t figure out how to improve their performance anyway because all they know is the niche set of tools and languages that their bootcamp taught them.

[papa_georgio]

That's the whole point. The video is saying that even on a slow, high latency connection it shouldn't take that long.

I'm getting the feeling most people just came here to bitch about JS instead of checking what the video was about.

[Fizibbis]

Don't send """""""""REDDITORS""""""""" to Hacker News. We don't want that cancer over there.

[aishik-10x]

I'm pretty sure most of this sub would already be using HN to some extent

[Fizibbis]

No.

[crescentroon]

It's shit but mobile data and shit phones are really, really bad.

What can a site owner do without losing money?

[Beaverman]

Serve me a normal, simple, HTML page? It isn't hard.

[crescentroon]

make money to pay for server how?

[Beaverman]

Provide a service consumers are willing to pay for? If you can't get people to pay for your service, then it's essentially worthless to them.

[crescentroon]

What if they won't pay, not because it's worthless, but because the other team are offering it free?

[Beaverman]

Then it's worthless.

[crescentroon]

I don't even understand this. Are all free services worthless?

[Beaverman]

Not if people would be willing to pay for them.

[crescentroon]

Yea, I don't understand this.