18 ms·

Benchmarking DNS response times of TLDs

273 points by twapi 7y ago

ShorsHammer 7y ago
> The biggest shockers were the .info and .org domains that showed really poor performance especially in the 85 percentile range, despite being one of the oldest and well established top-level domains with millions of registered domains each Why do I imagine this being spun into some upbeat marketing exercise for .org?
arkitaip 7y ago
ccTLDs like .ru kinda make sense being slower on a global scale because they mainly target a national audience, but a lot of the worst offenders are gTLDs where your audience can be anywhere on the planet.
bscphil 7y ago
> For each top-level domain, our system picked a random nameserver published for each of the top-level domains and queried a random domain name that we picked for it. We then grouped the results by region and logged the data every 10 seconds. Am I misunderstanding what they're doing or is this completely misleading? If they're only testing one randomly chosen nameserver, the results are much less likely to be a good indication of the speed of an average request for that TLD. Why not average across all of them? Also, as they kind of suggest near the end, caching is probably good enough that this is very rarely a problem anyone needs to worry about.
- mlthoughts2018 7y ago
  I think they are saying on each probe, a random nameserver and then random site are chosen. So overall it’s randomizing over all nameservers and sites, to make the median a more useful metric of the overall TLD. In other words, what they wrote suggests it’s not just one fixed nameserver chosen per TLD, rather randomly chosen each time they will make a request.
- toast0 7y ago
  This methodology doesn't really consider what recursive resolvers tend to do either. Recursive resolvers will keep track of performance of the authoritative servers they use and send more queries towards the servers where they get faster responses. For popular TLDs like .COM/.ORG, it's almost guaranteed your recursive resolver will have enough data to pick a fast authoritative. If you're using a .bike domain though, I'd guess it makes some difference.
jjcm 7y ago
This is one of those things you simply don't expect to test when you're benchmarking performance. I've been trying to cut away chunks of 20-50ms on a side project I've been working on hosted on a .io domain, and I'm seriously considering switching because of this. Great article for sure. I also wonder at what point the trade off is between a vanity domain vs a more performant domain. For a CDN this makes perfect sense, but would it be better to launch with a less-notable url vs a more performant one?
- recuter 7y ago
  I humbly suggest this is not a good use of your time.
  - jhymn 7y ago
    Not if you like nerding out on this stuff. Then it's more like a hobby or pleasant diversion. But I agree one needs to zoom out and put things into its proper perspective.
  - C1sc0cat 7y ago
    nope I would kill to be able to cut 50ms by DNS tweaks across the large fleet >100 sites for a major brand
    - dsr_ 7y ago
      On the first request. All subsequent requests will be cached. Oh, and if the requestor has a large DNS cache upstream, it's already done. Oh, and if the browser used a pre-fetch, that's already done. Oh, and if you have already invested your branding effort across 100 sites, maybe you don't want to re-do all that? Oh, and if you need to cut 50ms from your first time page load, have you considered dropping all the trackers and analysis JS loads? Can you deliver your first page without any JS at all? Can you do it without a database lookup? Those are all things you should do before killing anyone.
    - Ayesh 7y ago
      If you haven't done already, take a look at don't delivery improvements. Serve don't files locally, subset them, and use variable fonts and woff2. I'm a micro performance enthusiast myself and it's my #1 optimization with the biggest gain.
random_savv 7y ago
Would love to hear if the same applies to SEO and/or spam filters. I have a .works domain, which looks nice, but it was a huge mistake and wish I had gone for a .com: - people often mispell it to .work, or just generally get confused - one customer actually couldn't receive my emails because some layer in their email stack was blocking this domain - .work exists, and somebody else owns [name].work, which is a potential security risk...
- danpalmer 7y ago
  I’ve heard anecdotally that getting .xyz email delivered is much harder than .com, some servers just blanket reject. I expect this will change as the domains become more popular.
  - tluyben2 7y ago
    There are still enough sites that actually call emails with some TLDs invalid when signing up. So I can imagine some of them simply have a fixed list when sending/receiving emails and just reject all the rest.
  - aequitas 7y ago
    I managed a hosted email platform in the past and can confirm one of our spam filters was a simple whitelist of all know TLD's, which was manually updated every now and then. We eventually dropped it when new TLD's where announced every few weeks. Can image some providers still use these kinds of lists and not updating them because they receive no complaints.
    - Avamander 7y ago
      > not updating them because they receive no complaints. I wonder why...
  - dsr_ 7y ago
    I blacklist .xyz, .ninja, and a few others. Nobody complains.
sdan 7y ago
I find this a bit hard to believe. Who's servers were you running this test on? Which regions exactly? Is there any other sources that back up this claim? Also interesting that .in (even though indian tld) is faster...
- Tade0 7y ago
  The company I used to work for switched from .io to .dev, because the former had issues with availability.
- dylz 7y ago
  .in is technically-operated by Neustar.
cotillion 7y ago
I don't think you can draw any conclusions at all from this. They appear to have measured how far it is from their CDN pops to the anycast instances of the TLDs. Edit: I see what they did. They picked a random nameserver for each TLD. This means that those using only anycast servers win as they always hit the same POP. .org uses only some anycast instances.
sandGorgon 7y ago
Damn the India cctld is the second fastest cctld out there - almost at par with .us . Not sure where the tests were ran - probably in EU/US, so this is actually really good. It pretty much outperforms .com/.net/.org #MakeInIndia
- anaganisk 7y ago
  How is make in india even relevant to resolution/cache?
- captn3m0 7y ago
  It is operated by Neustar (an American company) under contract from NIXI. https://en.m.wikipedia.org/wiki/Neustar https://en.m.wikipedia.org/wiki/Neustar
frereubu 7y ago
We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. We also had a client who had to change their TLD from .healthcare to .org.uk because (a) people were confused because they didn't understand that there are all these new TLDs and kept adding .co.uk, .org etc and (b) some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare, saying that it was a malformed email address. I think in the vast majority of cases these new TLDs aren't worth it until the general population's understanding catches up. I still advise clients to use www rather than a plain domain name for websites, because I've come across a significant minority of people who need that "www" as a clear signal that it's a website.
- Eikon 7y ago
  > I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.
  - SiVal 7y ago
    Could you (or someone) explain this? (I'm not arguing, I'm interested.)
    - faeyanpiraat 7y ago
      I'm interested in this aswell.
    - Eikon 7y ago
      You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly: - Given a record `@ IN ALIAS example.org.`. - Pull records at `example.org` (maybe with an AXFR request but usually just individual records). - Merge our domain APEX with `example.org` records we just pulled. - Reply to requester with the merged zone, discarding the ALIAS record. Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.
siscia 7y ago
A little off topic, but some of you folks have experience with bunnycdn, the company behind the post? Are they fine?
- jlelse 7y ago
  Yeah, they are doing an amazing job.
  - siscia 7y ago
    Thanks!
- busymom0 7y ago
  I don’t have experience with them but I did find that they started as a side project and shared it on Reddit 4 years ago: https://reddit.com/r/SideProject/comments/419hz0/bunnycdn_the_simple_affordable_content_delivery/ https://reddit.com/r/SideProject/comments/419hz0/bunnycdn_th...
- therealarmen 7y ago
  They are great! We have been using them for a couple years now. Highly recommend.
- ksec 7y ago
  Same question. Was wondering if I should submit the BunnyCDN on HN as topic.
- therealmarv 7y ago
  I'm watching them for years. They are from Eastern Europe and started really small (they are not so small nowadays) but they deliver extended (!) features which many other CDNs don't have or like in a 5-10x more expensive premium price range. Also their policy is really relaxed. Awesome value for the money. You get much more for lower pricing.
- herf 7y ago
  Using them for serving f.lux updates - super reliable and beats cloudfront prices by a mile.
Tepix 7y ago
I recommend that all DNS servers be in-bailiwick servers with glue. This recommendation is taken from Dan Bernstein, see https://cr.yp.to/djbdns/notes.html https://cr.yp.to/djbdns/notes.html, section "Gluelessness" It not only improves reliability but can help reduce the number of queries and speed things up.
davidgf 7y ago
Interestingly enough, the .top domain gives what it promises: it's at the top of the worst performing TLDs list
st_goliath 7y ago
Friendly reminder for people on HN reading this: I know this is actually quite interesting, but before you start worrying about the latency of the name servers of your TLD, you might want to do something about the metric ton of JavaScript on your site and the 25 different 3rd party servers from which you side load most of it. Also those 6 additional servers from which you load a bunch of TTF fonts. Especially if all your site does is just display some text and two or three pictures.
- RL_Quine 7y ago
  No kidding. I'm using a > 1GBit fibre line and the majority of my page loads is still downloading recursive, pointless javascript dependencies, or doing a billion CORS OPTIONS requests and waiting for the response. DNS latency doesn't even factor into the end result user experience, it's dominated entirely by front end design decisions. If this was a concern it’s an admission that JavaScript developers have optimized to the best of their ability. Which is just sad.
  - tgv 7y ago
    Do you have a moment to talk about The Great Saver, uMatrix?
    - RL_Quine 7y ago
      Disabling a lot of the bloat makes random pages break, which is an even worse experience.
      - jerf 7y ago
        But it is compensated for by the sites that actually work better when you strip their non-local JS from them. I've lost track of the number of times I've come to the HN comments and read about how unreadable the page was due to all the popups and ads and modal dialogs when I just read the text. You're absolutely not wrong that some sites get worse, but it's not one-sided in that direction.
irenedowd 7y ago
Hi. I ran over a generally excellent Hacker Goatse Security. They have assisted with a ton of issues like Phone Hack, Account Hack, Clear Debts, Grade overhaul E.t.c Contact: goatsesecure (at) gmail Text/Whatsapp: +1 646 389 4585
mxuribe 7y ago
Well, this is disappointing. As others have stated , clearly there usually are other areas (easier targets like too much javascript or tracker code crap) to optimize performance than here. But what i find disappointing is that i was under the belief that things like a TLD were merely cosmetic and didn't have an impact on underlying performance. Domain names were supposed to be sticky labels on more important underlying infrastructure. I always thought that choosing a .COM, .NET, .WHATEVER didn't matter for delivering digital assets across the internets to one's customers/users...well, if bunnycdn is onto something, color me surprised, and slightly saddened. I've owned my own {$last_name}.CC domain name, and have used it as the basis for my personal/family email for over a decade, and am quite aware of how it has gotten treated at least on the spam front. Admittedly, I've had very, very minor issues compared to many others who have used other seemingly "non-traditional" TLDs/ccTLDs. (I attribute the low issues to having used G Suite for many years. Spam fighting: One of the few good things i like about google.) While the .CC tld was originally based on a country code, it was marketed (and i guessed managed) for many years now as a generic TLD. My friend gave me the idea to use it after he set his domain name up for his then-nascent (ahem) computer consultancy ...And, since the .COM, and the .NET versions[0] of my $last_name at the time were not available for me, i went with a nice short and sweet .CC domain. Back then i also felt a mild sense of edginess for using something different than "boring old" .COM, or .NET. But i never figured there would be DNS/nme resolution performance issues...Its just a name resolve process going from some arbitrary text name to ip addresses, etc...why should there be an issue, right? Beyond the admittedly minor spam issues that I've had with using a "non-traditional" TLD, the biggest headache by far is having to educate people that the world has more than just .COM and .NET domain names. Having to emphasize (both verbally spell out, and through bold text or caps while written) that my email address ends in .CC and NOT .COM is quite annoying. After so many years, it still has not lessened much...At least not in the U.S. - where i live and work. However, strangely/unexpectedly, outside the U.S. this issue is vastly less of a thing. During the last 2 years I've traveled to many parts of the world for my dayjob, and wow, my {$last_name}.CC domain name is pretty much not an issue outside of the U.S. So this whole time it's my own Americans who lack the literacy in this regard. From my experience, in the minds of typical, layperson Americans there exists only .COM, .NET, .ORG, maybe sometimes .UK...But everything else might as well be .SPAM or .FAKE ;-) So, after the spam, after all the years of annoyance of emphasizing the spelling of the TLD, and now there could be possible performance issues!?! Man, this whole domain name thing sucks (to say nothing even of the sleazy business/marketing side of the racket). I mean, weren't domain names supposed to make things easier than having to remember arbitrary IP numbers/addresses? I think we need a new method or system. [0] By the way, the .ORG version for my domain name was available years ago, but I wasn't a non-profit, so felt i didn't want to grab it; happily allowing any true, legitimate non-profit to scoop it up. My mental jury is still out on whether that was a wise decision that i made or not. Because of recent news of the .ORG registry, maybe I'll make a separate post on this topic.
vegardx 7y ago
I mean, that would probably be true if DNS wasn't distributed and highly cacheable. But seeing that it is I would be surprised if you'd see anything other than statistical anomalies on a domain with even a limited traffic and poorly configured TTLs.
neurostimulant 7y ago
> The biggest shockers were the .info and .org domains that showed really poor performance especially in the 85 percentile range, despite being one of the oldest and well established top-level domains with millions of registered domains each. After some further investigation it appears 4 out of 6 of their nameservers are performing extremely poorly which is the reason for the poor results. I always thought with all the money collected from ten million .org domains they would have an army of nameservers to make sure latency is low, instead they actually only have 6 nameservers and are performing poorly? Sure it'll probably won't impact real world performance but I'm still disappointed that they seem to be only doing bare minimum. I wonder where those hundred million bucks actually goes?
- Ayesh 7y ago
  Most TLDs run the bare minimum amount of nameservers required by ICANN, specially the newer TLDs. However, hundreds of nameservers scattered around the globe wouldn't help much either, because they just need to have faster responses to the mass of recursive resolvers.
  - toast0 7y ago
    Hundreds of nameservers scattered around the globe with anycast absolutely helps. The main thing between a DNS request and a DNS response is network round trip time. Actually processing the request should be trivial (especially for .org, but even at .com), the zone file may be large compared to most, but it's all static records, with batched updates. I remember when internic would do updates at midnight, but you might not make it in the batch; mostly I see 5-20 minute delays on changes now.
dreamcompiler 7y ago
Off topic: My first thought was "Andrew Huang has a CDN?" but then remembered he spells his nickname differently. Never mind.
Aissen 7y ago
That's something for which we might want to see the raw data: to sort by region, see other percentiles, analyze whether it's bunnycdn's connectivity ? Also, it might be nice to be able to re-do the tests; better yet: have a website that's auto-updated so that we see results today (maybe TLD X had an incident when they were measuring?). Of course, that's not something you can ask a random stranger on the internet to do for you.
cordite 7y ago
Was this tested with different geographic points to account for latency across the earth?
3xblah 7y ago
I once read that the person running the .co registry was a k user and released his own k-like language. I wonder if that has anything to do with the speed of the .co TLD
d2wa 7y ago
Independently reproduced the tests for .com and .blog. Found that many of the TLDs at the bottom of BunnyCDN’s list has one thing in common: CentralNic. Avoid using any TLD that use it for their backend infrastructure. https://www.ctrl.blog/entry/dotblog-tld-performance.html https://www.ctrl.blog/entry/dotblog-tld-performance.html

273 points by twapi 7y ago

ccTLDs like .ru kinda make sense being slower on a global scale because they mainly target a national audience, but a lot of the worst offenders are gTLDs where your audience can be anywhere on the planet.

bscphil 7y ago

> For each top-level domain, our system picked a random nameserver published for each of the top-level domains and queried a random domain name that we picked for it. We then grouped the results by region and logged the data every 10 seconds. Am I misunderstanding what they're doing or is this completely misleading? If they're only testing one randomly chosen nameserver, the results are much less likely to be a good indication of the speed of an average request for that TLD. Why not average across all of them? Also, as they kind of suggest near the end, caching is probably good enough that this is very rarely a problem anyone needs to worry about.

mlthoughts2018 7y ago
I think they are saying on each probe, a random nameserver and then random site are chosen. So overall it’s randomizing over all nameservers and sites, to make the median a more useful metric of the overall TLD. In other words, what they wrote suggests it’s not just one fixed nameserver chosen per TLD, rather randomly chosen each time they will make a request.
toast0 7y ago
This methodology doesn't really consider what recursive resolvers tend to do either. Recursive resolvers will keep track of performance of the authoritative servers they use and send more queries towards the servers where they get faster responses. For popular TLDs like .COM/.ORG, it's almost guaranteed your recursive resolver will have enough data to pick a fast authoritative. If you're using a .bike domain though, I'd guess it makes some difference.

jjcm 7y ago

This is one of those things you simply don't expect to test when you're benchmarking performance. I've been trying to cut away chunks of 20-50ms on a side project I've been working on hosted on a .io domain, and I'm seriously considering switching because of this. Great article for sure. I also wonder at what point the trade off is between a vanity domain vs a more performant domain. For a CDN this makes perfect sense, but would it be better to launch with a less-notable url vs a more performant one?

recuter 7y ago
I humbly suggest this is not a good use of your time.
- jhymn 7y ago
  Not if you like nerding out on this stuff. Then it's more like a hobby or pleasant diversion. But I agree one needs to zoom out and put things into its proper perspective.
- C1sc0cat 7y ago
  nope I would kill to be able to cut 50ms by DNS tweaks across the large fleet >100 sites for a major brand
  - dsr_ 7y ago
    On the first request. All subsequent requests will be cached. Oh, and if the requestor has a large DNS cache upstream, it's already done. Oh, and if the browser used a pre-fetch, that's already done. Oh, and if you have already invested your branding effort across 100 sites, maybe you don't want to re-do all that? Oh, and if you need to cut 50ms from your first time page load, have you considered dropping all the trackers and analysis JS loads? Can you deliver your first page without any JS at all? Can you do it without a database lookup? Those are all things you should do before killing anyone.
  - Ayesh 7y ago
    If you haven't done already, take a look at don't delivery improvements. Serve don't files locally, subset them, and use variable fonts and woff2. I'm a micro performance enthusiast myself and it's my #1 optimization with the biggest gain.

random_savv 7y ago

Would love to hear if the same applies to SEO and/or spam filters. I have a .works domain, which looks nice, but it was a huge mistake and wish I had gone for a .com: - people often mispell it to .work, or just generally get confused - one customer actually couldn't receive my emails because some layer in their email stack was blocking this domain - .work exists, and somebody else owns [name].work, which is a potential security risk...

danpalmer 7y ago
I’ve heard anecdotally that getting .xyz email delivered is much harder than .com, some servers just blanket reject. I expect this will change as the domains become more popular.
- tluyben2 7y ago
  There are still enough sites that actually call emails with some TLDs invalid when signing up. So I can imagine some of them simply have a fixed list when sending/receiving emails and just reject all the rest.
- aequitas 7y ago
  I managed a hosted email platform in the past and can confirm one of our spam filters was a simple whitelist of all know TLD's, which was manually updated every now and then. We eventually dropped it when new TLD's where announced every few weeks. Can image some providers still use these kinds of lists and not updating them because they receive no complaints.
  - Avamander 7y ago
    > not updating them because they receive no complaints. I wonder why...
- dsr_ 7y ago
  I blacklist .xyz, .ninja, and a few others. Nobody complains.

sdan 7y ago

I find this a bit hard to believe. Who's servers were you running this test on? Which regions exactly? Is there any other sources that back up this claim? Also interesting that .in (even though indian tld) is faster...

Tade0 7y ago
The company I used to work for switched from .io to .dev, because the former had issues with availability.
dylz 7y ago
.in is technically-operated by Neustar.

cotillion 7y ago

I don't think you can draw any conclusions at all from this. They appear to have measured how far it is from their CDN pops to the anycast instances of the TLDs. Edit: I see what they did. They picked a random nameserver for each TLD. This means that those using only anycast servers win as they always hit the same POP. .org uses only some anycast instances.

sandGorgon 7y ago

Damn the India cctld is the second fastest cctld out there - almost at par with .us . Not sure where the tests were ran - probably in EU/US, so this is actually really good. It pretty much outperforms .com/.net/.org #MakeInIndia

anaganisk 7y ago
How is make in india even relevant to resolution/cache?
captn3m0 7y ago
It is operated by Neustar (an American company) under contract from NIXI. https://en.m.wikipedia.org/wiki/Neustar https://en.m.wikipedia.org/wiki/Neustar

frereubu 7y ago

We have a client who insisted on using a .house domain. It kept triggering alerts on our uptime monitoring service with DNS errors, so we had to reduce the sensitivity of that specific test. We also had a client who had to change their TLD from .healthcare to .org.uk because (a) people were confused because they didn't understand that there are all these new TLDs and kept adding .co.uk, .org etc and (b) some NHS systems in the UK (one of their target audiences) refused to accept emails that finished with .healthcare, saying that it was a malformed email address. I think in the vast majority of cases these new TLDs aren't worth it until the general population's understanding catches up. I still advise clients to use www rather than a plain domain name for websites, because I've come across a significant minority of people who need that "www" as a clear signal that it's a website.

Eikon 7y ago
> I still advise clients to use www rather than a plain domain name for websites And you should. Not only can’t you put CNAME at the zone APEX without doing nasty tricks but not doing so is also a security risk when dealing with cookies.
- SiVal 7y ago
  Could you (or someone) explain this? (I'm not arguing, I'm interested.)
  - faeyanpiraat 7y ago
    I'm interested in this aswell.
  - Eikon 7y ago
    You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly: - Given a record `@ IN ALIAS example.org.`. - Pull records at `example.org` (maybe with an AXFR request but usually just individual records). - Merge our domain APEX with `example.org` records we just pulled. - Reply to requester with the merged zone, discarding the ALIAS record. Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.

siscia 7y ago

A little off topic, but some of you folks have experience with bunnycdn, the company behind the post? Are they fine?

jlelse 7y ago
Yeah, they are doing an amazing job.
- siscia 7y ago
  Thanks!
busymom0 7y ago
I don’t have experience with them but I did find that they started as a side project and shared it on Reddit 4 years ago: https://reddit.com/r/SideProject/comments/419hz0/bunnycdn_the_simple_affordable_content_delivery/ https://reddit.com/r/SideProject/comments/419hz0/bunnycdn_th...
therealarmen 7y ago
They are great! We have been using them for a couple years now. Highly recommend.
ksec 7y ago
Same question. Was wondering if I should submit the BunnyCDN on HN as topic.
therealmarv 7y ago
I'm watching them for years. They are from Eastern Europe and started really small (they are not so small nowadays) but they deliver extended (!) features which many other CDNs don't have or like in a 5-10x more expensive premium price range. Also their policy is really relaxed. Awesome value for the money. You get much more for lower pricing.
herf 7y ago
Using them for serving f.lux updates - super reliable and beats cloudfront prices by a mile.

Tepix 7y ago

I recommend that all DNS servers be in-bailiwick servers with glue. This recommendation is taken from Dan Bernstein, see https://cr.yp.to/djbdns/notes.html https://cr.yp.to/djbdns/notes.html, section "Gluelessness" It not only improves reliability but can help reduce the number of queries and speed things up.

davidgf 7y ago

Interestingly enough, the .top domain gives what it promises: it's at the top of the worst performing TLDs list

st_goliath 7y ago

Friendly reminder for people on HN reading this: I know this is actually quite interesting, but before you start worrying about the latency of the name servers of your TLD, you might want to do something about the metric ton of JavaScript on your site and the 25 different 3rd party servers from which you side load most of it. Also those 6 additional servers from which you load a bunch of TTF fonts. Especially if all your site does is just display some text and two or three pictures.

RL_Quine 7y ago
No kidding. I'm using a > 1GBit fibre line and the majority of my page loads is still downloading recursive, pointless javascript dependencies, or doing a billion CORS OPTIONS requests and waiting for the response. DNS latency doesn't even factor into the end result user experience, it's dominated entirely by front end design decisions. If this was a concern it’s an admission that JavaScript developers have optimized to the best of their ability. Which is just sad.
- tgv 7y ago
  Do you have a moment to talk about The Great Saver, uMatrix?
  - RL_Quine 7y ago
    Disabling a lot of the bloat makes random pages break, which is an even worse experience.
    - jerf 7y ago
      But it is compensated for by the sites that actually work better when you strip their non-local JS from them. I've lost track of the number of times I've come to the HN comments and read about how unreadable the page was due to all the popups and ads and modal dialogs when I just read the text. You're absolutely not wrong that some sites get worse, but it's not one-sided in that direction.

irenedowd 7y ago

Hi. I ran over a generally excellent Hacker Goatse Security. They have assisted with a ton of issues like Phone Hack, Account Hack, Clear Debts, Grade overhaul E.t.c Contact: goatsesecure (at) gmail Text/Whatsapp: +1 646 389 4585

mxuribe 7y ago

Well, this is disappointing. As others have stated , clearly there usually are other areas (easier targets like too much javascript or tracker code crap) to optimize performance than here. But what i find disappointing is that i was under the belief that things like a TLD were merely cosmetic and didn't have an impact on underlying performance. Domain names were supposed to be sticky labels on more important underlying infrastructure. I always thought that choosing a .COM, .NET, .WHATEVER didn't matter for delivering digital assets across the internets to one's customers/users...well, if bunnycdn is onto something, color me surprised, and slightly saddened. I've owned my own {$last_name}.CC domain name, and have used it as the basis for my personal/family email for over a decade, and am quite aware of how it has gotten treated at least on the spam front. Admittedly, I've had very, very minor issues compared to many others who have used other seemingly "non-traditional" TLDs/ccTLDs. (I attribute the low issues to having used G Suite for many years. Spam fighting: One of the few good things i like about google.) While the .CC tld was originally based on a country code, it was marketed (and i guessed managed) for many years now as a generic TLD. My friend gave me the idea to use it after he set his domain name up for his then-nascent (ahem) computer consultancy ...And, since the .COM, and the .NET versions[0] of my $last_name at the time were not available for me, i went with a nice short and sweet .CC domain. Back then i also felt a mild sense of edginess for using something different than "boring old" .COM, or .NET. But i never figured there would be DNS/nme resolution performance issues...Its just a name resolve process going from some arbitrary text name to ip addresses, etc...why should there be an issue, right? Beyond the admittedly minor spam issues that I've had with using a "non-traditional" TLD, the biggest headache by far is having to educate people that the world has more than just .COM and .NET domain names. Having to emphasize (both verbally spell out, and through bold text or caps while written) that my email address ends in .CC and NOT .COM is quite annoying. After so many years, it still has not lessened much...At least not in the U.S. - where i live and work. However, strangely/unexpectedly, outside the U.S. this issue is vastly less of a thing. During the last 2 years I've traveled to many parts of the world for my dayjob, and wow, my {$last_name}.CC domain name is pretty much not an issue outside of the U.S. So this whole time it's my own Americans who lack the literacy in this regard. From my experience, in the minds of typical, layperson Americans there exists only .COM, .NET, .ORG, maybe sometimes .UK...But everything else might as well be .SPAM or .FAKE ;-) So, after the spam, after all the years of annoyance of emphasizing the spelling of the TLD, and now there could be possible performance issues!?! Man, this whole domain name thing sucks (to say nothing even of the sleazy business/marketing side of the racket). I mean, weren't domain names supposed to make things easier than having to remember arbitrary IP numbers/addresses? I think we need a new method or system. [0] By the way, the .ORG version for my domain name was available years ago, but I wasn't a non-profit, so felt i didn't want to grab it; happily allowing any true, legitimate non-profit to scoop it up. My mental jury is still out on whether that was a wise decision that i made or not. Because of recent news of the .ORG registry, maybe I'll make a separate post on this topic.

vegardx 7y ago

I mean, that would probably be true if DNS wasn't distributed and highly cacheable. But seeing that it is I would be surprised if you'd see anything other than statistical anomalies on a domain with even a limited traffic and poorly configured TTLs.

neurostimulant 7y ago

> The biggest shockers were the .info and .org domains that showed really poor performance especially in the 85 percentile range, despite being one of the oldest and well established top-level domains with millions of registered domains each. After some further investigation it appears 4 out of 6 of their nameservers are performing extremely poorly which is the reason for the poor results. I always thought with all the money collected from ten million .org domains they would have an army of nameservers to make sure latency is low, instead they actually only have 6 nameservers and are performing poorly? Sure it'll probably won't impact real world performance but I'm still disappointed that they seem to be only doing bare minimum. I wonder where those hundred million bucks actually goes?

Ayesh 7y ago
Most TLDs run the bare minimum amount of nameservers required by ICANN, specially the newer TLDs. However, hundreds of nameservers scattered around the globe wouldn't help much either, because they just need to have faster responses to the mass of recursive resolvers.
- toast0 7y ago
  Hundreds of nameservers scattered around the globe with anycast absolutely helps. The main thing between a DNS request and a DNS response is network round trip time. Actually processing the request should be trivial (especially for .org, but even at .com), the zone file may be large compared to most, but it's all static records, with batched updates. I remember when internic would do updates at midnight, but you might not make it in the batch; mostly I see 5-20 minute delays on changes now.

dreamcompiler 7y ago

Off topic: My first thought was "Andrew Huang has a CDN?" but then remembered he spells his nickname differently. Never mind.

Aissen 7y ago

That's something for which we might want to see the raw data: to sort by region, see other percentiles, analyze whether it's bunnycdn's connectivity ? Also, it might be nice to be able to re-do the tests; better yet: have a website that's auto-updated so that we see results today (maybe TLD X had an incident when they were measuring?). Of course, that's not something you can ask a random stranger on the internet to do for you.

cordite 7y ago

Was this tested with different geographic points to account for latency across the earth?

3xblah 7y ago

I once read that the person running the .co registry was a k user and released his own k-like language. I wonder if that has anything to do with the speed of the .co TLD

d2wa 7y ago

Independently reproduced the tests for .com and .blog. Found that many of the TLDs at the bottom of BunnyCDN’s list has one thing in common: CentralNic. Avoid using any TLD that use it for their backend infrastructure. https://www.ctrl.blog/entry/dotblog-tld-performance.html https://www.ctrl.blog/entry/dotblog-tld-performance.html