The Faster Web can be defined as a series of qualities to be developed in all spheres of web technology in order to speed up any transaction between a client and a server.

But how important is speed? It is important enough for Google to have discovered, in 2010, that any slowdown had a direct impact on a company's website traffic and ad revenue. In fact, Google successfully established a statistical correlation between traffic and ad revenue, and the number of results and the time it takes to obtain them. The end result of their research was that it is possible to observe a decrease of the order of 20% in traffic and add revenue when obtaining more results in 0.9 seconds versus fewer results on a page in only 0.4 seconds. Yahoo also confirmed that about 5% to 9% of its users would abandon a web page that took more than 400 milliseconds to load. Microsoft Bing saw a 4% decrease in revenue when the search results were delivered with an additional delay of only 2 seconds. Clearly, speed not only ensures user engagement, but also has a major effect on a company's revenue and general performance.

At first glance, it would seem that the Faster Web is exactly the same thing as web performance. But is this really the case?

Performance is defined as the manner in which a mechanism performs. According to André B. Bondi[2], "the performance of a computer-based system is often characterized by its ability to perform defined sets of activities at fast rates and with quick response time." And, as J. D. Meier et al. stated in their book on performance testing[3], "performance testing is a type of testing intended to determine the responsiveness, throughput, reliability, and/or scalability of a system under a given workload."

Thus, it is very clear that web performance is a core concept of the Faster Web. But, do we always expect these characteristics to be the only ones? If an application promises a thorough analysis of a hard drive and completes its task in less than five seconds, we will most certainly think that something went wrong. According to Denys Mishunov[4], performance is also about perception. As stated by Stéphanie Walter[5] in one of her presentations on perceived performance, "time measurement depends on the moment of measurement and can vary depending on the complexity of the task to be performed, the psychological state of the user (stress), and the user's expectations as he has defined them according to what he considers to be the software of reference when executing a certain task." Therefore, a good manner in which an application does what it has to do also means that the software would have to meet the user’s expectations as to how this computer program ought to do things.

Even though the Faster Web initiative first concentrated its efforts on making the different web technologies go faster, the different studies led researchers back to the notion of subjective, or perceived, time versus objective, or clocked, time in order to fully measure how website performance influenced the user's habits and general behavior when it came to browsing the web.

Therefore, in this book, we will be covering the Faster Web as it applies to all the major web technologies—that is to say, those that run on 70 to 80 % of web servers around the world and on all the major browsers, namely Apache, PHP, MySQL, and JavaScript. Moreover, we will not only cover these major web technologies from a developer's standpoint, but we will also discuss the Faster Web from the system administrator's viewpoint by covering HTTP/2 and reverse proxy caching in the last chapters. And, although the greater part of this book will be addressing the question of web performance only, the last chapter will be covering the other aspect of the Faster Web, which concerns satisfying the user's expectations through good user interface (UI) design.