Kooboo can execute a complete dynamic page containing 10 content items in approximately 0.8 milliseconds, deliver a browser-measured server response in approximately 2 milliseconds, and run thousands of suitable websites inside one compact instance.
These are unusual claims, so we are not asking you to simply believe them.
We have prepared a downloadable Kooboo site package. You can import it to measure a real dynamic website and use the included example to generate 1,000 websites in your own Kooboo instance.
Do not benchmark our brochure. Download Kooboo and benchmark the product.
Demo 1: A full dynamic website rendered in 1 millisecond
The downloadable site package contains:
- 10 AI-generated blog articles
- A master layout, pages, header view, and footer view
- Dynamic queries for the blog list and individual blog detail pages
- URL rewriting
- Dynamic HTML titles and meta tags based on each blog article
- A fully responsive HTML design using Google Fonts and custom styles
- Kooboo labels and HTML blocks for smaller pieces of site text
This is a real dynamic website, not a 'Hello World' benchmark.
Download the 1 Millisecond Kooboo Site
How to reproduce the result
- Download and import the site package into Kooboo.
- Open one of the installed site's dynamic pages.
- Inspect its pages, views, content, and query definitions.
- Open the browser developer tools and select the Network panel.
- Reload the page and inspect the 'Waiting for server response' timing.
- Compare the browser result with the Kooboo execution time recorded in the visitor log.
| Measurement | Reference result |
|---|---|
| Kooboo execution time | Approximately 0.8 ms |
| Browser waiting for server response | Approximately 2 ms |
| Page type | Dynamic server-rendered page |
| Dynamic content | 10 content records |
Kooboo's execution-time measurement begins when the HTTP request enters Kooboo and ends when the completed response reaches the network-writing boundary. It includes website identification, route resolution, content access, template execution, and response construction.
The browser result includes additional local transport and browser timing overhead. This is why it can be higher than Kooboo's internal execution time.
Turning off visitor log will still speed up slighter
Test machine
We ran this test on a four-year-old local PC with an 11th Gen Intel Core i7-11370H processor at 3.30 GHz, 16 GB of RAM, an SSD, and Windows 11. Kooboo was running under the Visual Studio debugger. All Screenshots are taken from this machine
Screenshots from the speed test
Demo 2: Run 1,000 websites on one small server
The following example script can be added to a Kooboo API and run to generate 1,00 websites each time in your own instance:
for (let index = 0; index < 100; index++) {
var siteName = "generated" + index;
var fullDomain = siteName + ".localkooboo.com";
k.site.package.xCopy(siteName, fullDomain, true);
}
k.response.write("100 sites generated");
Each Kooboo website is stored as a separate folder. When you create 1,000 websites, they are 1,000 distinct sites. You can switch to any generated site and inspect it independently.
In many of our real installations, approximately 500 websites run on a virtual machine with 2 vCPUs and 4 GB of memory without observed performance problems.
Observed Kooboo memory usage
The following results come from our controlled test environment
Inside Kooboo desktop version backend, in the site list page, those sites are display inside an iframe with loading to real sites. In the list of 6 websites, it is real request to 6 kooboo sites at the same time. We load different pages with 6 sites every second to load the site and test the memory. We load all of them
Every website and workload is different. These figures apply only to our controlled environment, and we cannot guarantee identical results in every production deployment. We encourage users to run the test and report their results to us.
Why Kooboo is this fast
A website should not need a large server merely to turn content into HTML. Yet modern web development often places a product page behind a web server, application framework, middleware pipeline, dependency-injection container, ORM, external database, template engine, cache service, analytics service, and a large browser-side JavaScript bundle.
When the result is slow, the usual response is to add Redis, a reverse proxy, a CDN, full-page caching, more CPU, more memory, or another server.
Kooboo takes a different approach. It reduces the work required to produce the page.
One integrated performance path
Kooboo includes its own web-serving, domain routing, DOM processing, template rendering, content storage, B-tree indexing, server-side querying, caching, analytics, A/B testing, API execution, compression, and response-output capabilities.
This matters because performance comes from the complete request path:
HTTP request → website and route → render plan → required data → UTF-8 output → network response
Kooboo controls this path from beginning to end. Its storage, query, rendering, memory, and output systems are designed to work together instead of communicating through multiple general-purpose services.
Templates become prepared render plans
Templates are written for people. They contain HTML, views, layouts, values, conditions, loops, labels, queries, and placeholders.
A conventional template engine may repeatedly parse the HTML, construct an object tree, locate expressions, interpret instructions, create temporary strings, and combine the result for every request.
Kooboo prepares a compact render plan. The runtime executes operations such as writing static content, rendering a view, resolving a value, executing a query, repeating content, or evaluating a condition.
On the next request, Kooboo does not need to rediscover the page structure. It executes the prepared plan.
Bytes go directly toward the network
The browser ultimately receives UTF-8 bytes, not strings. A conventional rendering path may repeatedly convert string to bytes:
Stored bytes → strings → objects → more strings → UTF-8 bytes → network
Each conversion can allocate memory, copy data, encode text, and create later work for the garbage collector.
Kooboo keeps much of its rendering path byte-oriented. Prepared HTML can be accessed through byte spans and written into pooled output buffers:
Prepared UTF-8 bytes → response buffer → network
Dynamic values still need to be formatted, but the static parts of the page do not need to become new strings on every request merely to be converted back into bytes.
A small rendering memory footprint
Kooboo reuses memory throughout its rendering and response paths:
Rent buffer → write output → send response → return buffer → reuse
Small temporary operations can use stack memory. Larger operations can rent arrays from a shared pool. Prepared render plans and source data can also use memory-mapped files, allowing active data to remain hot while inactive site data stays compact and file-backed.
Kooboo also uses fast LZ4 compression in its render-plan storage path. A smaller block can reduce storage and memory movement while still being decompressed quickly for execution.
The biggest memory and cpu usage of Kooboo are the initial request of a page, we need to parse the dom, convert HTML into render plan.
Multilingual pages read only the requested language
Some multilingual systems load every translation in a content record and select the requested language afterward.
If a product is translated into English, German, French, Spanish, Chinese, Japanese, Arabic, and Portuguese, a German request should not need to materialize all eight languages.
Kooboo supports culture-specific content views. The content-reading path knows the requested culture and the default fallback culture before it materializes the required values.
Requested language → default-language fallback when needed → ignore unrelated translations
Adding more translations should not force every request to allocate every language.
Read only the fields the page uses
A product record may contain a title, summary, full description, specifications, gallery, video, SEO metadata, shipping information, related products, and multiple language versions. A product card may require only a title, price, image, and URL.
Kooboo's query and content-reading paths support selected fields. The goal is to retrieve the right records, in the right language, with only the fields the template needs.
Do not retrieve 100 fields when the page displays four. Do not retrieve eight languages when the visitor requested one.
<k-data>: server-side data queries inside HTML
Kooboo’s <k-data> system lets a template declare the data it needs close to the HTML that uses it. Kooboo executes the query on the server and renders the result directly into the page.
<k-data>
<query
as="products"
source="commerce"
resource="product"
action="list"
select="id,title,featuredImage,price,seoName"
page-size="10"
export>
</query>
</k-data>The template declares what it needs, the query runs on the server, and the result becomes finished HTML. The browser does not need another initial API request or a frontend framework to reconstruct the content.
Request → server-side query → rendered HTML → visible content
Kooboo built the engines for the job
Kooboo includes its own DOM engine, B-tree and B+ tree database technology, template engine, and render-plan engine.
The DOM engine understands website structure, templates, resources, editing, and relationships. The indexed database engine locates matching records without scanning the entire dataset. The query layer selects the required language and fields. The render engine writes the result toward UTF-8 output.
Indexed lookup → selected fields → requested culture → compact render operations → UTF-8 output
This integration is difficult to reproduce by connecting several unrelated systems after the fact.
Why 1,000 sites do not require 1,000 application stacks
Conventional hosting may duplicate an application process, framework runtime, plugin system, database connection pool, cache, scheduler, and container for every website. Even idle sites consume resources because their duplicated infrastructure remains active.
Kooboo hosts many websites inside one optimized platform. Each site still has its own domain, routes, pages, layouts, views, content, files, users, permissions, configuration, analytics, and history. The core server, routing, rendering, storage, caching, and management engines are shared.
One Kooboo runtime → thousands of separate website identities
The server does not need to run 1,000 copies of the rendering engine to host 1,000 websites.
What the performance numbers mean
One thousand small websites are not equivalent to one thousand high-traffic global marketplaces. Real capacity depends on hardware, traffic, concurrency, page complexity, data size, custom code, images, downloads, commerce activity, email, background jobs, and external integrations.
Kooboo's claim is not that workload no longer matters. The claim is that Kooboo adds remarkably little platform overhead per site and per request.
A fast backend still matters when network latency is higher. Short execution time preserves the latency budget, releases the CPU sooner, reduces queueing under load, limits allocation pressure, and allows more traffic and more websites to share the same server.
Performance without giving up a complete web platform
Kooboo is not a static-file server presented as a CMS. The same platform provides dynamic content, visual editing, multilingual websites, reusable layouts and views, forms, APIs, backend JavaScript, commerce, analytics, A/B testing, email capabilities, database access, permissions, version history, deployment, and AI-assisted website creation.
The achievement is not rendering an empty response in one millisecond. It is maintaining exceptional performance while supporting the complete lifecycle of a real website.
The fastest work is the work the system never performs
- Do not repeatedly parse an unchanged template.
- Do not build a large object graph when compact operations are sufficient.
- Do not turn bytes into strings only to turn them back into bytes.
- Do not allocate a new array when a pooled buffer can be reused.
- Do not load every language when the visitor requested one.
- Do not load every field when the template needs only four.
- Do not send initial content through an unnecessary browser API request.
- Do not run a separate application stack for every website.
Each avoided operation makes the system smaller. Together, they make Kooboo fast.
Download the demo. Import it. Inspect the source. Measure the response. Generate 1,000 sites. Then tell us what your machine can do.