3 ms·

I'm looking at the behavior of the search tool on the page, which makes a request to https://instantdomainsearch.com/services/all/<query https://instantdomainse

by Figs 9y ago

I'm looking at the behavior of the search tool on the page, which makes a request to https://instantdomainsearch.com/services/all/<query 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.

always_good 9y ago
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.
- Figs 9y ago
  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...

by Figs 9y ago

always_good 9y ago

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.

Figs 9y ago
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...