How fast is a "Gyroscope Site"? September 6, 2019

Gyroscope is a high performance platform for building industry-specific solutions; its application ranges from retail, financial services, inventory control, ecommerce, document life cycle management, digital assets, production and the list goes on. And of course, in some "trivial" use cases, Gyroscope is used as a content management system (CMS) back end.

In the CMS space, Gyroscope is often evaluated as a replacement option for WordPress. It is therefore fair to ask, how fast is a Gyroscope site?

The simplest answer is a "Gyroscope site" is as fast as your network and browser can transfer and deliver content; it can be "lightening fast". To put in numbers, a moderate feature-rich web page can be loaded in L+20ms, though your mileage may vary. The "L" stands for latency, it's the unavoidable wait time between your browser and the web server. When a website is deployed in the same city as its target audience, the latency is around 30ms. This means the total response time is 50ms, or 5% of a second.

In comparison, the time to first byte (TTFB) on a typical WordPress website is 4 seconds. The product page on a "lean" Shopify store takes about one second to load, this is not counting the "blocking time", which we'll discuss later.

Now, the really comprehensive and technically correct answer is that there is no such thing as a "Gyroscope site". Yet, the mere presence of a Gyroscope deployment, even when it's used for the "back office", makes the overall system light and fast. Why is that?

1. Zero Framework Overhead

Many out of the box CMS products such as WordPress generate the "front end" web pages. This convenience comes with a performance price tag. Each time a simple "About Us" page is loaded, the entire "WordPress Run-time" - the environment, or "core" for running WordPress pages, is engaged. Like an overbearing parent on the first school day, the core is always around to facilitate the communication between the web page and its outside world.

Gyroscope, on the other hand, does not get in the way. This means that the overhead that is introduced by the Gyroscope environment is literally non-existent. The time to generate a page is all about the page itself. There is no waste on tech-bureaucracy.

2. Minimal Memory Footprint

The most direct benefit of having no framework overhead is the efficient memory uptake. On a 64-bit operating system, a typical "lean page" consumes 2MB to generate. A standard WordPress page, in comparison, requires 60MB. Compounding the response time of 50:4000ms, a "lean site" has 2,400 times the concurrency level as a WordPress site. This means that given the same hardware, a web site that's not weighted down by any CMS run-time can serve over two thousand times as many visitors as a WordPress site.

3. Pristine Data

The reason that a front-end web page can be simple is because of the non-tainted database structure thanks to Gyroscope. While other CMS and ERP platforms use over generalized structures to build generalized features, Gyroscope focuses on tailoring the database as closely as possible to the end user. At the same time, Gyroscope provides its developers an effective environment for making expressive and accurate interfaces.

Gyroscope calls your business concepts and objects the way they are. There is no "generics" or approximation. The user doesn't have to mimic one concept with another. An author of a WordPress blog is familiar with the notion that every thing is a "post". Even an attached image inside a post is a post! Shopify users have also likely accepted the Shopify way of classifying their products. In particular, what is considered a "variant", and what is an attribute. The complete lacking of a "dimension" for a faceted search is somehow offset by the almighty "collection".

Again, Gyroscope doesn't twist its users minds. When the data honestly represents reality, the front end pages can be easily generated, and the end result is also much easier to use.

4. Non-blocking Rendering

Earlier we mentioned a "blocking time" in our time measurement. The fact that it takes one second to download a Shopify product page doesn't mean the user can start reading in just one second. As many frameworks use generalized storage structure, also called an "abstraction layer", the unique characteristics of certain records are not captured by the back end. Instead, the added functionality is often added on the client-side, in the form of JavaScript transformations.

In a Shopify site, for example, pairing picture frames with paintings is considered a fancy feature. Because every shop is different, the pairing concept is not part of the "core". JavaScript is therefore used instead of the back end code. This means for the shopping site to respond, the related web components have to be loaded. This is a "blocking wait" when the browser often becomes unresponsive. It is common to have a 200ms, or one fifth of a second blocking on a Shopify page.

Gyroscope's database, as mentioned in Point 3, is accurately modeled after the use case. This means special features are built in the back-end and JavaScript is only used to progressively enhance the user experience without clogging down the browser. When integrated with FFC, our specialized shopping cart framework, the front-end performance is further enhanced to support a large volume of transactions in a given time.

5. Flexible Clustering

Gyroscope helps the front end with a clean database (#3); yet it is not adding to the rendering overhead (#1). The fact that nothing is shared in the application layer means the capacity of the overall system can be increased by simply adding more hardware. This is often not the case with non-Gyroscope systems where doubling resource can only marginally improve the performance.

In conclusion, a Gyroscope deployment is performant not only by itself. It also contributes to its ecosystem. Through a truthful database and various design features, a public facing website that runs alongside Gyroscope without being shadowed by it, can be extremely fast and scalable.