About Site Health


Although there are several topics in site health that will be covered below the most important one is generally considered to be page timings, meaning the average load times for individual pages on a website. The most important one is almost always the load time for a home page, although any ‘landing page’ is a close runner up. Landing pages are not always chosen by the website builder but they can be easily identified using GA, meaning Google analytics platform. These are pages similar to the homepage in that users are often seen entering your site through them. Other site health topics covered here include dns configuration, smpt, dedicated IP addresses and something called dmarc. We’ll provide you with outbound links for those. Nerd goggles, on.

Note that Google PageSpeed Tools shows the rules your your page has already passed.
Note that Google PageSpeed Tools shows the rules your your page has already passed.

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

The tool provides an explanation on removing render-blocking JavaScript for example, along with the steps required. Before browsers can render a page, the parser can hit a script, causing it to stop and execute before continuing. Worse are external scripts which require waiting for a download before html parsing resumes. To prevent delays from these network roundtrips, Google recommends inlining the small scripts required to render a page. For example, say you have a small blocking script for adding two numbers,

<head>
 <script type="text/javascript"src="add.js">
 </script>
</head>

To fix the problem place the whole script file into the header code between the opening, <script…> and closing code, </script>. For example,

<head>
  <script type="text/javascript">
  var num1, num2, sum 
  num1 = prompt("Enter 1st number") 
  num2 = prompt("Enter 2nd number") 
  sum = parseInt(num1)+parseInt(num2) 
  alert("Sum = " + sum)
  </script>
</head>


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

Free and fast, Google PageSpeed Tools reports not only on the total load times, but include advanced features to give a play by play analysis in fractions of a second, showing which functions or code snippets are causing a delay. This is useful to a developer with JavaScript and html coding knowledge, because it gives more than insight; Google specifically shows the steps you should take to modify your code and in some cases, provides the code itself to drag and drop into the actual page you’re testing. Additionally, this site health tool has features to show you how each page’s CSS, html and JavaScript code can be rearranged, combined or minified, then provides that code for download. On the one hand, PageSpeed’s features reduce page load times improving SEO, while on the other hand they’re completely free, making it a bit of a toss up as to weather one should try it out. We’ve used it as a development tool for three years with nice results. Click to see a diagram showing the page render process and see how the basic DOM and CSSOM are combined with one another to form the render tree for a page.

Key Terms

  • Page Timings
  • Server Array
  • 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, 72.52.134.216 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 72.52.134.216 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.


See web design in by Google certified developers.