Comment by Figs | Hacker News Reader

Comment by Figs | Hacker News Reader

As someone who actually regularly uses a slow mobile connection (8 kilobytes per second!) with somewhat high ping (~90ms to Google), please don't do this thinking you're making my life significantly better. It barely makes a difference in performance once loaded, and the initial load time is ridiculously worse. I'd much rather you make your page work without JavaScript, kept the design light (as this page has otherwise done), and make your CSS cacheable.

Right now, it takes over 5 seconds(!!) for this page to load because of all the freaking JavaScript it has to download! With JS off, the page loads almost immediately. With a keep-alive connection, subsequent loads over HTTPS are not particularly long, unlike what this article seems to think. (Hacker News is one of the FASTEST sites I can access, for example. Even on my crappy connection, pages load nearly instantly.)

Simply letting me type, press enter, and wait 0.1~0.3 seconds for a new page response would not be a significantly worse experience -- however, due to the way the site is written, search doesn't work AT ALL with JS disabled.

So, lots of engineering effort (compared to just serving up a new page) for little to no actual speed improvement, and a more brittle website that breaks completely on unusual configurations... Yeah. Please don't do this!

You should get the iOS app: https://itunes.apple.com/us/app/instant-domain-search/id1068...

It uses the streaming API, and will work well for you.

Thank you for the link, but I have Android, and I'm looking at the performance by tethering to my PC.

You wouldn’t wait 0.3s for the next page - that’d be 0.3s + a few seconds waiting for all the queries to return before showing anything. Streaming let’s you show results earlier.

Most likely the page loads instantly because the server is not doing any real work, which is offloaded to the client/js.

I'm looking at the behavior of the search tool on the page, which makes a request to https://instantdomainsearch.com/services/all/<query parameters> through AJAX and gets streamed lines of JSON back as a result. It's not doing DNS queries from JS or whatever.

Looking at the behavior with curl and wireshark, what I see is that a full, new connection to the service does spend most of its time in DNS lookup and HTTPS handshake. It takes about 0.1~0.3s for the actual data to transfer.

What the article is recommending is basically, don't make a request per JSON object. (It streamed back 69 objects for the query I tried.) Using one connection to transfer the information saves a lot of overhead -- and I don't have a problem with that part of the advice.

What I mean is, instead of using JS at all to do this (and consequently triggering a 5 second initial page load, etc etc.), have the server build the page the traditional way, and send that -- that's still one connection for that data transfer, and with a light page design and keep alive connection, the page load time does not seem like it would be significantly different here (most of the time is going to be in that 0.1~0.3s for the query to execute regardless) -- but the initial page load time would be significantly faster on slow connections.

If your queries do actually take many seconds, sure, maybe there would be a benefit there, but I'm not seeing the value on a page like this, and I really don't want people to take away the idea here that they should redesign their sites to use AJAX to "reduce latency on mobile" by default as it won't help, and in fact, tends to make things worse.

These services seem to often get .com/.org/.net/etc results back immediately (maybe cached or API is just faster) while the longer-tail stuff is slower. Maybe not cached or has to hit one of those weirder tld servers to check.

This is a case where the streaming solution makes sense because you don't want to have to wait til `example.weirdtld` is resolved when you just want to check for `example.com`.

Now, you kinda admitted this in this post which is quite a change from your original post, at which point it seems that you're saying "this isn't always good" which is kinda self-evident.

There were a couple hours between the two posts, and I was actually pissed off when I wrote the first one -- I'd had more time to think about it and cool down a bit by the time I got through with that second one.

As someone who is in the class of people actually affected by developers' choices on how to "reduce latency on mobile", I reacted really badly when presented with a page that had a massive increase in load time because of JS -- when JS was being presented as the solution to a problem on mobile connections. (Frankly, I hate the way JS is being used on the modern web as it tends to make my experience browsing the web absolute hell for a couple weeks each month after I hit my bandwidth cap. I browse with it off by default, and my experience is usually better on the majority of otherwise well-designed websites.)

After reflecting on it more, I acknowledged that the article does make a good point -- don't make lots of small connections to the server if you can avoid it since connection start up time can be large -- and people in the replies reminded me that the average performance I'm seeing isn't necessarily the worst case performance, and problems with the way this site was put together didn't necessarily mean the technique is bad.

Now that more time has passed, I have to wonder why didn't the author just use chunked transfer encoding of HTML instead of JSON for the results? You'd get basically the same effect without needing any JavaScript at all -- and as the author brought it up in the post, he/she is clearly aware of it. That's really the first question I should have asked...

I share your sentiment. But isn't it just their experiment page that uses too much JS as opposed to the approach requiring a ton of JS by nature?

I haven't tried to unpack their JS -- but you're right that it might not need to be as heavy as it actually is here.

Reply on news.ycombinator.com