Solving the puzzle to an effective website
Having worked with numerous websites through hosting, website design, and re-designs, we’ve seen many pieces necessary to solve the puzzle of making a website really work as a marketing tool. A common misconception we’ve found is that all you need is a good website, and a fast host for your website. Well, those two pieces sure help, but let’s briefly look at all the pieces that must be working, from the moment a customer / potential customer (referred to as end-user here) starts trying to find you.
Note, JV Host can make a package for monitoring / dealing with any of the following pieces of the puzzle. Contact us if you don’t feel comfortable troubleshooting or maintaining these pieces!
Scenario: end-user tries to go to your website, from any number of places
Step 1 – DNS (should happen in tenths of a second):
- End-user types jvhost-design.ca into the address bar .. browser says “where do I find that? What is the internet address (IP Address) of that site?” This is called DNS .. this is the translation of your website address to an internet address (IP Address). This is the start of TTFB (time-to-first-byte).
- The basic flow is, your computer sends a question to your set name server (ie. google, or your Internet Provider), “I’m looking for a website, jvhost-design.ca”. When you registered your domain (signed up for xxxx.com), the domain registrar (eNom, Namecheap, GoDaddy, etc) told 1 or more of the 13 sets of root name servers in the world which feed the response to these requests, where to look for translation of your address (ie. ns1.jvhost-design.com).
- The name server then looks at the website name, including any particular parts such as estore.jvhost-design.ca, and if it has an IP address, it will give that out. It also tells Google or your internet provider how long that address is valid for so it can cache it on its end, so it doesn’t have to go all the way to the main name server.
- This step alone has numerous possible points of failure. This could even be the step where you say to me, “my website is loading slow” .. the possible reasons for that often fall in this step, especially if it’s loading normal for someone else. Anything from a bad piece of network equipment along the line to the name server, to a bad line from your Internet provider. Meanwhile the hosting company who often gets blamed, may not be the cause of your slow website – their server is running nice and fast, internet is nice and fast. The problem could be just getting to the fast server.
Step 2 – Webhost response:
- Now that our computer knows the IP address of our easy-to-remember website name, it makes a direct call to that IP address, along with the website name, asking it for the website or specific page. This IP address begins the connection to the web host (ie. GoDaddy, JV Host & Design, etc). Think of this stepping up to a drive-through window.
- You might not actually be connecting directly with the host computer, but instead a proxy web server, essentially a traffic cop (you’re not talking directly to the chef, but instead the order taker). The proxy server looks at the website (or part of the website) that you’re asking about and says, “I know that site, I’ll get it for you, just hold on please (yes, we still have fries, I’ll put in your order)”.
- Before it even asks for the website, it might do a quick check for what you’re really looking for? Is there anything funny about your request? Who’s asking for the website (the requesting IP Address)? Are you a known trouble maker?
- When the web host responds with the first byte of data (he gives you your drink while you wait), that marks the end TTFB.
- Things that can slow down load time include no caching, pages with heavy duty calculations, and many others pieces.
Step 3 – Rendering in your browser:
- The first pieces of the website are sent to your computer / phone / tablet. That doesn’t mean it’s ready to load … there could be scripts that need to load from 3rd parties – only the necessary scripts should be loaded at the top of the website. That tells your website, “I need this script for rendering the website so until I get it, don’t show the website”. Careful analysis of each script should be given, determining if it’s necessary to load before showing the website or not. If you are sure users are using updated browsers, you can put all your scripts in the head, but use “defer” in the script tag: (script defer src=”xxx”). This lets it load the script as the html is parsing but waits until parsing is finished before the script executes.
Step 4 – How does the website look to the end-user?
- Are your fonts loading correctly? Google fonts sometimes fail to load.
- Are all your links working?
- Are all your images loading? Are they small enough to load quickly yet hi-res enough so they don’t look pix-elated?
- Is your contact form working?
- Did an update break some functionality?
Are you ready to have us deal with the pieces we understand so you can focus on reaching out to customers through an effective website? Contact us today for a quote!