Static websites are well known to perform among the best of all types of websites, and much faster when compared against web content management systems like WordPress. If fact, there are modifications and paid services that turn WordPress sites into static websites to improve performance.
Cosmos also is a web content management system, and its performance was tested against a static website with the same content. Cosmos was found to match the speed of a static website. This is without modification.
How can that be? In short, Cosmos was designed that way.
To know why the Cosmos performs so well is to know the story behind it--its origins and why it was built, and its evolutionary journey.
In 2019, California experienced a historic event with extremely high winds and dry conditions, creating a significant wildfire risk. To mitigate this, electric utilities across 30 counties turned off power for about 2.5 million customers. The Governor's office, as part of the emergency communication plan, set up a website to share event details and disaster relief information. The California Department of Technology (CDT) was tasked with its overnight creation.
The team knew the website had to be highly reliable and fast, as tens or hundreds of thousands might access it simultaneously. Many would do so on cell phones, often in rural areas with limited coverage and bandwidth. Thus, the web pages had to be minimalistic, using the fewest bytes possible to ensure accessibility in such regions.
Initially, WordPress was considered, but there wasn't enough time to create a site that could serve so many users reliably. Additionally, WordPress is known for generating large, inefficient pages unsuitable for weak cell connections.
The decision was made to build a "static" website with a Content Delivery Network (CDN) front. The staff was confident this was the most reliable and efficient approach for website design, especially when paired with a CDN.
The "Response" website proved to be a success, operating seamlessly and meeting performance expectations. Presented below is a streamlined overview of its architecture: The design is straightforward, with a blob storage account containing the web pages and associated files. A static website delivers these files from the storage account to the internet, complemented by a content distribution network, or "CDN," at the forefront.
During the event, disaster relief personnel from various agencies provided new and updated content. This information was relayed to a team of web developers who were on call around the clock. The developers used a code editor to make changes to the website and then pushed the updates to a Git repository. Once prepared, two DevOps automations, known as "pipelines," were executed. The first automation uploaded the content to blob storage, and the second triggered a "purge" on the CDN, enabling the new content to be displayed.
This method offered clear advantages, such as high reliability and excellent performance. Additionally, it was relatively straightforward to implement. In some respects, this harked back to the early days of the web when websites were merely collections of HTML, CSS, and JavaScript files, served to the internet by a basic server that processed requests and delivered the files.
This approach had its drawbacks. It necessitated web developers to manage content changes. Moreover, content updates needed to be initially stored in a Git repository, followed by automation to synchronize the updates with both the blob storage and the CDN.
Ideally, once web developers have designed and launched the website, they should be able to transfer content management responsibilities to non-technical staff. Moreover, content updates should be automatically propagated through the website and the CDN, eliminating the need for managing and executing two separate automation scripts from the Git repository.
In December 2019, a decision was reached to capitalize on the successes of the autumn season by developing a new architecture or web platform.
The goal was as follows:
Create a dynamic content management system designed for use by non-technical users, maintaining the same level of performance as the original static website. This system would include features like automatic content updates and CDN integration. Additionally, it needed to seamlessly integrate with contemporary cloud services, be straightforward to install and manage, and have minimal computational requirements.
As conceived the ideal situation for this system is where a web developer would design and initially construct the website, then turn it over to regular staff to keep updated and current. That is precisely the situation that Cosmos is built for.
In thinking about how to accomplish this goal was to recognize what was already working well. Website files storge in blob storage, fronted by a static website, was reliable and fast. So that was largely left alone. What changes the most frequently in a dynamic website is are the web pages. The associated CSS, JavaScript, images changed less often.
With this realization in mind, the decision was made to maintain the blob storage/static website as it was, while adding a web application that exclusively serves web page HTML content from a database. This led to the creation of a "hybrid" that combines elements of both a static and a dynamic website.
It became evident that non-technical staff would not utilize a code editor for managing web pages and uploading files. A more user-friendly alternative, like a WYSIWYG editor similar to familiar tools, was required. Such functionality could be incorporated into a web application akin to Google Docs or Word Online, simplifying file management. Moreover, the possibility of hosting these applications on the dynamic website was explored.
However, integrating content management applications into the dynamic website was deemed unwise due to potential resource constraints, such as RAM, CPU, and network limitations, which could degrade the website's performance. The dynamic website was designed for anonymous access, and merging it with content editing tasks, which require secure, authenticated access, raised significant security issues. Therefore, the decision was made to create a separate dynamic website specifically for content editing and management, restricting anonymous access to bolster security and alleviate the public website from the strain on resources.
The editor web app has been enhanced with built-in features to manage files in the storage account, web pages in the database, and to initiate actions in the CDN—all in a synchronized, automated manner. That resulted in the following basic architecture.
The majority of a web page's size in bytes is made up of assets such as images, CSS, and JavaScript files. A single web page may contain numerous such asset files. These files are typically served through a "static" website.
The HTML web pages are served from a memory-optimized “dynamic” website--which is its only task.
The "Editor" web application serves as a platform for users to create and modify content. It handles assets on the static site using a file manager, code editor, and image editor. For the dynamic site, it manages web pages with a WYSIWYG editor (CKEditor) and a code editor powered by the Visual Studio Code engine.
By having the Editor separate, it unburdens the dynamic website from the overhead associated with editing web pages or uploading or managing files on the static website. This ensures the dynamic website is always as fast as possible.
Finally, whenever a web page is “published” the Editor automatically alerts the CDN to refresh the changed content on both the static and dynamic websites. Currently Cosmos works with Azure CDN (Edgio and Microsoft), and Sucuri.
Early next spring in 2020, COVID came to the United States and California. All attention now turned to the response effort and further development of this website framework slowed considerably and stopped. It wasn't until spring of 2021 that work could begin again, and in the fall of 2021, the project was open sourced by the California Department of Technology.
Since then, the product now known as “Cosmos” has developed and grown, sponsored by Moonrise Software. Now we are trying to grow the open-source community, and encouraging its adoption by promoting its use