PageSpeed Tools Insights
Google PageSpeed Tools offers developers an array of insights and detailed instructions on how to fix coding issues to improve page timings.
Removing Render Blocking Scripts
To fix the problem place the whole script file into the header code between the opening, <script…> and closing code, </script>. For example,
Page Timings aka Load Times
The time between a user’s click on a link to your page and the moment it finishes loading is simply called load time and each page of a site has its own. The topic is referred to as page timings and in the years leading up to 2017, it became still another factor to affect organic search ranking in Google, meaning page timings affect SEO. The same is now true for Bing and Yahoo results. While the effect appears to be small, it’s there, which requires measuring and optimizing each page of a site.
Variables Affecting Page Load Times
To annoy developers a bit more, all page timings are affected by variables outside our control, including host speed, network latency, traffic surges, geographic distance between web hosting server and user, not to mention the connection and device speeds of each user. Complex at first glance, problems posed by such variables are addressed using a group of servers called an array. Server arrays measure load time by taking averages from different geo locations using one standardized test. This goes a long way in keeping results consistent over time and across tests of multiple domains.
Comparable Results for Scoring Speed
The strategy makes each new result valid for comparison to all others, so that a percentile score can be assigned showing how your overall speed or page timings compare to all others on the web. That can be useful. At the 99th percentile mark only 1% of the pages in the world load faster than yours and it is recommended to stay at or above the 50th percentile mark for speed. This is only speculation on a newer topic for which there is not much data. Using the approach of averages measured by a server array, one of the standard web tools for analyzing page timings is built by Google and is completely free to use.
Features in Google PageSpeed Tools
DNS Name Servers & Site Health
When you’re browsing the web, DNS name servers are your guides. It’s because DNS name servers show your browser where to pull the info needed to connect with the site domains that you want to visit. There are about 20 million DNS name servers on the web serving roughly 220 million domain names. A TLD refers to what follows the last dot of a web address such as, .com, .net or .media and each one has it’s own DNS name server. Why is DNS important to site health? Look at what it has to do when you visit a new website such as www.nice.com:
1: A local server inside your device called your system DNS server sends out queries to (hits up) the root level server of the DNS server for .com, Here .com is the first part of the domain that you’re device is searching for and specifically the .com in www.nice.com or any .com, is called the top level TLD .
2: The root level server returns the address you requested for the DNS server for .com.
3: The next step happens in your device, as your system DNS uses the address for the DNS server for .com returned by the root level server, to send a query to the server that is only for .com domains called the .com server, asking it for the address of the DNS server for www.nice.com.
4: In response, the .com server returns the exact address, 126.96.36.199 which is the address of the authoritative DNS server meaning the one for every .com TLD that exists. It is named, NS1.TASTYTEK.COM.
5: Now it’s your device’s turn and your local DNS server uses the address it received of 188.8.131.52 to query (yodel at) NS1.TASTYTEK.COM in order to query (share the love w/) it for the address of www.nice.com. You have this.
6: To grant the request for the www.nice.com address, NS1.TASTYTEK.COM looks up the CNAME alias for www.nice.com and returns an address called its CNAME record to your local system’s DNS server.
7: Next, the system DNS server on your device uses the CNAME record it received in order to begin a new DNS query to ask for an “A” record for the canonical name of www.nice.com which is called its CNAME alias to keep you on your toes.
8: Next, your system DNS will query (ask) the NS1.TASTYTEK.COM server again but this time it sends the CNAME alias it received, as a query to the NS1.TASTYTEK.COM server asking for the FQDN of the domain of www.nice.com. It is in fact that simple.
9: But instead of getting back the FQDN your local DNS server asked for, NS1.TASTYTEK.COM, returns the “A” record for www.nice.com. instead: Ask for an FQDN, get an “A” record. Even though it isn’t what you asked for, it’s useful because your local device’s DNS server doesn’t need to send a query in the next step. Why? Instead it sends the “A” record to another process on your web connected device called the system DNS resolver. With this “A” record for www.nice.com passed to your system DNS resolver, your web browser connects to the web server for www.nice.com. That’s really all there is to it. A nine step process you could repeat with your eyes closed.. after a week of intensive study. So it’s this easy, and all thanks to our new special buddy, part of this complete site health check, the DNS name server.