User Interface Performance Criteria for Web Designers and Front-End Developers
And if every domain you request obviously requires the DNS process to resolve the domain name, then you should be one hundred percent sure that it is really worth it. In the case of a non-large site (such as CSS Wizardry, for example), using a subdomain to load resources would be an unreasonable step. In all likelihood, the browser will be able to cope with this task more quickly by parallel downloading of several objects from one domain than by pre-initiating a DNS search with subsequent parallelization of downloads. If you have, say, a dozen objects, then when placing them you should consider using one subdomain, and in this case, the initialization of the process of searching for an additional domain in order to better parallelize the loading of the available amount of resources may be justified. If there are, say, forty objects, it is advisable to place them on two sub-domains, and the total number of DNS searches performed for the correct operation of your site will be three, which also makes sense in this case. Keep in mind that the resolution of a domain name is a very laborious process, and you should decide what is preferable for you: perform an additional DNS search or use one domain to provide the resources of the site. It is also important to remember that since the request for the HTML code was made, for example, from the foo.com domain, the search process for this domain name has already been completed and all subsequent requests for this domain no longer need to contact the DNS service.
Proactive domain name resolution. If you, like me, want to have a Twitter widget on your site, provide analytical information and perhaps use some web fonts, then in this case you will still have to connect to other domains, which will entail the use of the DNS service. My advice to you is to always carefully weigh the pros and cons before using any widget, first of all paying attention to the harm done by this performance widget. However, if you still find that some of them can not do, please note the following information. Since all such things are on third-party domains, this means that, for example, the required font will be loaded in parallel with your CSS code (which, in fact, initiates this download), which is to some extent a positive thing, but the scripts will still be block parallel downloads (at least if they are not asynchronous). To the maximum extent, the DNS lookup problem manifests itself when third-party domain names are enabled. Fortunately, there is a super fast and easy way to speed up this process: “DNS prefetching” (* pre-resolution of domain names). DNS prefetching does exactly what the term itself says of this process, and it is also incredibly easy to use.
If you need to select objects from, say, widget.foo.com, then it’s best to take advantage of the ability to pre-resolve DNS by simply adding the following code directly to an element of your page: … … By simply inserting a regular string, we inform the browser supporting this method start the process of proactive domain name resolution a few steps before it is really required. This means that the DNS search will already be done at the time when the browser encounters the element