Ad Blocker Detected
Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker.
EVERYONE is looking to improve the loading speed of their website these days – not only to better support mobile devices, but also in the hope their Google rankings will improve. The truth is that “loading speed” is a rather “loaded” issue (pun intended). There are hundreds of factors involved when adjusting the loading speed of a website or application, and many of them can only be addressed on a case-by-case basis.
However, the core principles listed below are relevant to ANY web project.
Optimizing Your Domain Registrar
Ever since ICANN was established by the United States government in 1999 – stripping Network Solutions of its monopoly on domain name registration – the world has been flooded by domain name registrars and resellers. In fact, at last count, more than 900+ ICANN-approved registrars currently exist in the world.
Now, skipping over an in-depth explanation of DNS, the important thing to know about registrars is that location matters. More specifically, the location of your domain registrar’s DNS servers, and how many other DNS servers are nearby. What many people don’t realize is that even when a domain registry, e.g. .FM, is technically from a Pacific Island community called Micronesia, it is actually completely managed by an American-based company BRS Media Inc. with California-based name servers (DNS).
Most domain registries (.COM, .ORG, .ME, etc) opt for American name servers simply because it is the most well-connected country in the world when it comes to internet infrastructure (although Europe is rapidly gaining). Plus, the US also tends to have well-established IT companies ready and willing to manage domain registries on behalf of foreign governments and entities – after all, there is a LOT of money involved. Here are the most important things to keep in mind when choosing a domain registrar:
- Avoid domain “resellers” by using a top-level ICANN domain registrar (this will help avoid any “downstream” lagging or other issues caused by resellers)
- Choose a domain registrar whose nameservers are located in a top “internet exchange point” hub city (i.e. New York, Amsterdam, Frankfurt, London, etc)
- Ensure that your domain registrar is using Anycast DNS technology rather than Unicast (soon, this will probably be quite standard for all registrars)
- NEVER do business with a domain registrar whose policies permit them to shut off your domain for any reason other than a direct court order, or who prevent you from transferring/adjusting your domain as you the owner see fit, or who penalize you for renewing late (a.k.a. avoid GoDaddy at all costs)
Optimizing Your Domain Name Itself
If you are using a reputable domain registrar, there is not a lot of extra work you need to do in regard to optimizing your domain “resolution” speed. However, there are still some rather important things that you should setup for overall performance:
- Consider using an Anycast-enabled reverse proxy service such as CloudFlare or other 3rd-party DNS management service such as DNS Made Easy to manage your DNS (even if your registrar already supports Anycast, there are many other benefits to using a service such as CloudFlare, including protection from DDOS attacks, etc)
- Increase your domain’s time-to-live (TTL) settings to be as high as possible if you are not expecting to migrate servers anytime soon – in the “old” days before technology like Anycast revolutionized things, a recommended TTL for most projects was 3,600 seconds (one hour). However, with the rise of Anycast and “automatic” TTL, you can easily increase your TTL to 86,400 seconds (one day) or even higher i.e. 604,800 seconds (one week) … if you are using CloudFlare or another DNS management service, you could also simply choose “automatic” TTL mode
- Make sure that you have an A record for your root domain AND for the www subdomain even if you don’t want to use the www, in which case 301 redirect it to your root domain using CloudFlare’s Page Rules or at the server level (slower) in order to avoid “redirect loops” which can greatly decrease performance
- Remove all CNAME records (or MX, etc) that are not absolutely critical, especially any localhost/loopback records that point to 127.0.0.1 as it only creates security risks and should not be necessary for any modern server application
- Do not use nameservers provided by your hosting company – instead, whenever possible, simply point your A records directly to your server’s IP address – CloudFlare, and many web hosting companies, now support IPV6 as well
Optimizing Your Content Delivery Network
There’s really no getting around it – if you want a truly fast and reliable website that loads smoothly from anywhere in the world, you’re going to need a CDN at some point. With web technology advancing so quickly, its easy to get all these acronyms and services confused. For example, while CloudFlare is known mostly for its DNS services, it also technically provides CDN capabilities as well. Competitors such as Incapsula, EdgeCast, and Amazon’s CloudFront also provide integrated services that combine many aspects of DNS, content delivery, DDOS protection, firewalls, and beyond.
For small to medium sized businesses (who are probably reading this) I recommend using CloudFlare for DNS services along with MaxCDN. The pricing and customer service at both these companies is outstanding, and they are well accustomed to working together.
- Whether you use CloudFlare or another DNS/etc hybrid service, consider enabling support for SPDY, a new web protocol invented by Google that loads web pages noticeably faster than the older HTTP protocol (Note: SSL only)
- If you have a m. (mobile version) of your website, redirect mobile users at the DNS level, not at the server level, for better performance (again, this option is available on CloudFlare and other DNS services)
- Considering enabling other security features such as DDOS attack protection, image hotlink protection, and “challenge passage” which forces suspicious bots/users to enter a Captcha code in order to view your website
- Setup a cache system at the DNS level with a high TTL (and server level)
- Unless you are an advanced developer, do NOT cache query strings
- Strip all cookies out from your resources via your CDN settings (unless needed)
- To save your server extra stress, enable serving “expired” content via your CDN
- Consider ignoring max age/cache settings sent by your server, and instead maintain a default cache control headers via your CDN i.e. one month
- If your website is targeted often by brute force or comment spam bots, try using CloudFlare Page Rules to set higher security settings on specific pages
Optimizing Your Web Server (Host)
Phew! Are you still with me? Now we are getting to the juicy part – server configuration. This section is definitely the most debatable among web developers, if for no other reason than because there are so many options out there. So, I will try to keep it short and sweet; ultimately, professional server administrators all have their own preferences.
- Choose a reputable web hosting company – unless you are Google or Facebook, you probably don’t own massive datacenters of your own, so parnering with a reliable web host who updates their technology often and is well connected to internet backbone providers in a top “internet exchange” hub city is key
- Stick with VPS (easiest to scale) servers with SSD hard drives (fastest available) and 64-bit operating systems so that you can easily scale up your RAM memory (also, ensure your VPS uses top notch virtualization i.e. KVM or Xen)
- In general, Ubuntu (based on Debian) is probably the most reliable Linux distribution out there because it is maintained by a private London-based company, Canonical Ltd. (although CentOS has traditionally been popular among cPanel/WHM users, the impressively on-time release schedule and repository maintenance of Ubuntu make it a favorite among many web developers)
- Abandon cPanel/WHM (or any other control panels) and manage your server directly via shell – not only do control panels slow down your server like crazy, but they also create a ton of security risks for your website(s)
- Say goodbye to Apache, and switch over to NGINX – there’s a reason why most of the top 1000 websites in the world are now using this minimalist, Russian-born open source server software, because it scales like a champ and rarely crashes
- Unless you are an advanced developer, stick with MySQL 5.6+ and PHP-FPM 5.5+ which are an impressive duo (while older MySQL versions had performance issues, and many devs have switched to alternatives like MongoDB, MySQL 5.6+ (innoDB) should still be the go-to choice for most small and medium sized businesses)
- Ensure that files are loaded via PHP-FPM (i.e. fastcgi_pass unix:/var/run/php5-fpm.sock; in the NGINX server block) to leverage the built-in caching abilities (I do NOT recommend advanced accelerators like Varnish for most small businesses)
- Avoid installing FTP servers, email servers, nameservers, etc whenever possible
- Ensure that all gzip options are enabled and keep-alive is enabled (default)
- Specify “50x” and “404″ error directives to avoid server “hanging” delays
- For extra confidence, specify “expires max” on static content files
- Specify UTF-8 (universal encoding) and language locale (i.e. en-US) within your actual website header HTML to speed up browser loading speed
- Consider using WordPress as your content management system (CMS) to leverage powerful (and FREE) cache plugins such as Quick Cache which work wonders
- Consider advanced security firewalls for your server such as fail2ban (but, personally, I try to avoid any unnecessary software that deals with “logging” IP ranges)
- Always implement basic security hardening measures, such as disabling remote MySQL connections, changing the default port number for SSH, disabling root logins via SSH, etc (these types of things will help you avoid the vast majority of common security risks)
If you made it this far, hopefully you’ve seen the bigger picture: website performance is becoming much more DNS and CDN based – therefore, servers themselves should be slimmed down as much as possible.