20 Years of Websites Evolution: Part 11 – Availability

This is part 11 in the series: 20 Years of Websites Evolution.
Previous part: Part 10 – Reliability.


In the previous chapter, we learned that Reliability helps us to ensure the system will work correctly even in a case of data corruption or component failure. But even if the system will work correctly for one user doesn’t mean it will still work nicely when many users want to join in. Availability measure how available is the system for everyone who wants to use it. High availability systems can offer the same smooth experience regardless of how many users simultaneously use them or where they are on the planet.

Availability and Reliability usually complement each other, but they can be mutually exclusive. A system can offer great reliability for a fixed number of users, but may be limited to the maximum total/concurrent users or suffer from degrading experience. High availability system can support many users at the same time without affecting performance, but even a small malfunction can bring the entire system down. This is why often the Reliability and Availability aspects of the system supplement each other in order to deliver the best possible system stability at scale.


So users can access your site and it works without any bugs. Great! except it is slow, so very slow, and users are giving up on using your site.
Performance is a critical aspect of user experience, especially these days where everyone has a very short attention span.
Studies have shown the impact of site load time on bounce and conversion rate and now that Google ranks speed, sites need to load faster – no matter how complicated they are. You can read more about the importance of page speed here.


Optimizing site performance requires a combination of different methods like:

  • Reduce HTTP Requests
  • Image Optimization
  • Minify CSS and Javascript
  • Critical Path and Render Blocking Resources (CSS + JS)
  • Reduce Latency with a CDN
  • Minimize Time to First Byte (TTFB)
  • Avoid 301 Redirects
  • Caching (Expire Header, Client/Server, Data/HTML)
  • Prefetch and Preconnect
  • Delay loading images, components, and scripts
  • Use HTTP/2 when possible
  • Build Progressive Apps
  • Advance to modern programming languages and CMS (like asp.net 4.5 or PHP7 and HHVM)
  • Web Font Performance
  • Enable Gzip Compression
  • Fix 404 Errors
  • Serve Scaled Images
  • Server-side & Database Paging
  • Improve Site Design and User Experience (UX)
  • Infrastructure, Network & Disk optimizations
  • OS, Web Platform & Code optimizations
  • Database Optimization
  • Hotlink protection

Achieving those goals is a very difficult task which requires complete understating of every aspect of the site including the site client language (HTML/JS/CSS/Angular/React/Images), server language (C#/PHP/Python/Java/Ruby/Node), framework (PHP:Zend/Laravel/Symfony, Python:Django/Flask/Pyramid, C#:ASP.NET,MVC,Core, Ruby:Ruby on Rails) CMS (C#:SharePoint/Umbraco, PHP:Drupal/Joomla, Python:Mezzanine/Wagtail, Ruby:RadiantCMS/AdvaCMS) as well is the OS (Windows/Linux) and network protocols (HTTP, TLS, JSON) just to name a few.

You can learn more about performance optimizing in the following videos:



Here are some fun facts:

  • Around 40% (3.7 billion) of the world population has an internet connection today. In 1995, it was less than 1%.
  • There are over 1.2 billion websites on the world-wide web today. In 1991, there was 1 (one) website.
  • Google now processes over 40,000 search queries every second on average, which translates to over 3.5 billion searches per day and 1.2 trillion searches per year worldwide.

You can read more fun facts about how the Internet has grown here.

In simple terms, a lot more people are using the Internet now than ever. The amount of traffic sites needs to handle these days is much bigger than a decade ago, and so is the complexity of the sites. Making your site perform well for 1000 concurrent users is already hard, but what happens when your site gets popular and more users begin to use it? If you aren’t prepared for scale, your site will probably stop working exactly at the moment you need it the most.

But it’s not just the number of users, it’s also the amount of data that got bigger.

In 1992 the average data sent over the internet was 100 Gb per Day. In 2015 it is estimated that 20 TB per second was sent over the internet [infographic]. In 2016, every day 2.5 Quintillion bytes of data were created – most of them generated by the users:

Domo- data never sleeps

So it’s not just that we have more site users, it’s that the amount of data that we need to store for every user has been growing constantly and it will only keep getting bigger. Keeping up with all that traffic and data requires a big paradigm change in our entire technology stack and design philosophy since the technology that was based on the 90’s principals wasn’t designed for the current world needs.

This is where scalability comes into play, which is the ability for the site to handle a large amount of traffic without the need to change the way it works (Scalability = Performance @ Scale). For this purpose, sites need to be designed from the ground up, by using modern methods like

Creating high scalability sites requires using a combination of some of those methods, which makes them take considerable more time and effort to build.



The Internet made the world much smaller and made it much easier for small companies to provide high-performance, high-quality service in multiple countries and even continents (and who wouldn’t want more customers?). This is called Geo-distribution, but in order to do it, sites need to be deployed into multiple data centers around the world.

With the help of the Cloud (like Azure Traffic Manager) and High-Availability Global Distributed Databases (like Microsoft Cosmos DB, Apache Cassandra, and Google’s Firebase), it is possible, but will require careful considerations during the design phase and a dedicated operations team.



Creating high-reliability and high-availability sites require new technologies, complicated architecture and constant monitoring and maintenance. Up until now, only very large companies could afford it, but advancement in cloud technology has considerably lowered the bar which makes them accessible even for smallest business.

Diving Deeper

If you want to find out more about the topics discussed in the Operations chapter, I’ve created the following table where each topic is broken down to the requirements developers need to know in order to be able to fulfill it.

In the next chapter, we will learn how new delivery concepts and methods have changed site development velocity.

Next part: Part 12 – Delivery & Conclusion

What do you think?