ABOUT

SS Technologies is dedicated to speeding up websites and web applications using a modern efficient backend framework built around Node.js. Like others, we were perplexed at how slow even simple brochure sites could be while running backend frameworks based on PHP and content managers like WordPress, Joomla or Drupal. Changing a web page could take 5-8 seconds despite little content on pages and regardless of internet speeds. Delays like this might be plausible on sites with many users. But they are unacceptable on a small business site. This slow response is down to a number of factors.

Page Structure

Traditional websites have been multi-page, i.e. each page of a site was held on a separate HTML file. So for each new web page opened, the corresponding HTML file must be downloaded along with its associated style, image and other media content. Data transfer from a web server is many times slower than from the same machine so this delays initial load-up of each new page visited. In addition, dividing website content into several files will increase the total amount of data to be downloaded as file structure data is generated for each file. Once downloaded, all page content is cached by the browser. So further display of that page requires no external data transfer or assembly. Slow initial loading was a nuisance on sites with many pages of similar layout, e.g. e-commerce sites with large inventories. To mitigate this, page templates were introduced. A page template was essentially a HTML page with a small number of elements whose content could be changed via scripting. Changing from one template-based page to another thus needed minimal data transfer. An example of this would be item pages on an e-commerce site where only item name, image, product info, price, stock amount and delivery vary but all other content and styling of the page is unchanged. Using page templates sharply reduced the downloaded content volume. Yet busy e-commerce sites still depended on efficient execution at the server.

Navigation Mode

Single Page Application (SPA) website design mitigates the slow loading of multi-page sites in another way. It does so by putting all HTML content in a single file. The total content of this single HTML page is much less than the sum of the individual HTML files were the site multi-page. This reduces the amount of downloading needed. With a single HTML file, a web page is rendered by displaying the elements of that page and hiding all other elements. A web page in a SPA site is therefore simply a state of that single HTML file. Additional things like styling, images, media and scripts are downloaded as required, then cached. It is common to also have all styling and scripting in single files to minimise download time. Navigation to another page-state is achievable via frontend scripting and CSS manipulation. Despite the advantages of SPA website design, not all website owners have adopted it. Those who did so implemented it in a variety of ways, some involving as much interaction with the server as with the user's own machine. Regardless of implementation adopted, SPA websites still have to ensure that traditional browser buttons like Back, Forward and Refresh can function as in a multi-page site lest users become confused. Back and Forward page changing demands a page-state history stack on the browser's window object. Page refreshing requires storing a separate HTML file on the server for each page-state of the single HTML file.
SPA design made brochure site navigation as quick as a desktop application. Its frontend scripting functions were also useful when tasks otherwise entirely done from the backend, e.g. providing an on-screen message during authorisation followed seconds later by a page redirection, could now be partly delegated to the frontend. However, with more interactive websites and web applications, user requests to the server - especially those involving database queries, file searches or connections to other websites - would still be slow with common backend frameworks like those based on PHP or C#.

Server Blocking & Non-Blocking

Unless otherwise configured, web server machines operate rather like home PCs. They handle many processes simultaneously by means of allocating miniscule slices of CPU time (typically of the order of milliseconds) to each process in turn. Processes that are sharing CPU time simultaneously are said to be on separate execution threads. While this threading mode of resource sharing works efficiently enough on a desktop machine, it is highly inefficient on a machine used as a server for a web application. This is because web applications routinely query - and often alter - both the application's file system and its database. They also make frequent network requests in order to delegate tasks to remote servers or to acquire data from other organizations. To avoid the danger of one user querying a file system or database while another user is in the process of making changes to it, servers by default block execution of all processes on other threads until the querying is complete. With network requests, similar blocking is done lest the request be data altering and a concurrent one be given the old data. With servers frequently make database queries, file system operations and network requests this means that a large proportion of CPU time could be spent idling as execution threads are blocked from proceeding until an external, i.e. non-CPU, operation is completed. In addition, external operations typically take hundreds of milliseconds as opposed to milliseconds for normal CPU tasks. Blocking on a server therefore entails severe operating inefficency to hosting providers. It also creates an inordinate cost to web business owners who must lay on enough server capacity to enable acceptable response times to application users or risk losing them due to long wait periods.