preface
This post is about the rendering engine Kraken v0.9. If you are not familiar with Kraken, please skip to the end of this post to read our previous post.
Following the upgrade of Flutter 2.0 + Null Safety to V0.8, this release focuses on the first screen loading performance, layout correctness and performance, and front-end community ecology. The detailed update log can be found in CHANGELOG.
Next I’ll highlight some of the new features that have been added to V0.9.
QuickJS is supported as a JavaScript Engine
QuickJS is a lightweight JavaScript engine that has several advantages over JavaScriptCore:
- Lightweight, its implementation consists of just a few C files with no external dependencies, and a simple “Hello World” program on x86 costs about 180 KiB.
- A fast interpreter with very low startup time, combined with the precompilation of JS source code into Bytecode format, the application startup performance is greatly improved after ignoring the parsing time.
- Almost complete ECMA standard support, with the latest version natively supporting ES2020, eliminates the need for Babel to compile to ES5, which not only reduces JSBundle size, but also improves execution performance.
- Better multi-platform support, even complete compilation does not require too much effort.
Kraken V0.9 migrates the original Bridge layer JavaScript Engine to QuickJS by default, which improves application startup performance with Bytecode precompilation. And these changes are completely insensitive to the front-end developers.
We also Benchmark Kraken’s performance against the new and previous versions:
Testing equipment: MI 6 (Android arm64) test page: kraken.oss-cn-hangzhou.aliyuncs.com/data/cvd3r6… Test method: Use 0.8.4 (JavaScriptCore) and 0.9.0-RC (QuickJS) versions to compare the loading time. Detailed log:
- 0.9.0 – rc
- 0.8.4
Analyzing key performance metrics related to JavaScript in the log:
- Js_context_init_cost: initialization time of the JS Engine
- Polyfill_init_cost: Kraken JS Polyfill initialization time
- Js_bundle_eval_cost: indicates the JS Bundle execution time
- Js_parse_time_cost: JS Bundle parsing time
| Version | js_context_init_cost | polyfill_init_cost | js_bundle_eval_cost | js_parse_time_cost | |
|---|---|---|---|---|---|
| 0.8.4 | 17.30 ms | 20.39 ms | 229.53 ms | 31.25 ms | |
| 0.9.0 – rc | 0.55 ms | 2.06 ms | 122.61 ms | 122.91 ms |
QuickJS supports Bytecode loading, so js_parse_time_cost is almost negligible when using the Bytecode format.
Get the total loading time of JS:
- JavaScriptCore: 17.3 + 20.39 + 229.53 + 31.25 = 298.47ms
- QuickJS: 0.55 + 2.06 + 122.61 = 125ms
Real machine screen recording verification
The above Benchmark data belongs to the code level. How about the actual user’s body sensation? We have conducted a screen recording test on a real machine:
Index definition:
- White screen stage: from the time when the user clicks on the App to the time when the first frame appears on the page
- Rendering stage: the time from the first frame of the page to the stable completion of all the content (including pictures) of the target page
Through frame by frame analysis, the average value of multiple groups is obtained as follows:
Limited by the accuracy of the progress bar of the video player, the accuracy of the test data is 0.05s.
| The test group | Blank screen stage (mean value) | Render stage (mean) |
|---|---|---|
| 0.8.4 | 0.95 s | 0.80 s |
| 0.9.0 – rc | 0.95 s | 0.60 s |
| 0.9.0 – rc + the bytecode | 0.76 s | 0.66 s |
It can be concluded that under the above conditions, Kraken V0.9 + Bytecode mode can improve the first-screen performance by 18.86% compared with V0.8 version. It is worth noting that the real test uses a mid-range Android device, and the JS Engine’s parsing time has a greater impact on low-end devices. Therefore, it is reasonable to believe that the optimization brought by QuickJS can gain more benefits on low-end devices. We will further test and update the specific data.
Support HTML file parsing and rendering
For browsers, SSR direct rendering performs much better than asynchronous JS rendering CSR, and Kraken also performs better. This time we are bringing Kraken support for parsing and rendering HTML files, directly parsing HTML and rendering views without waiting for JS initialization and execution.
There is no difference in usage from JSBundle. You simply pass in the URL of the HTML file to the bundleURL:
void main() {
runApp(Kraken(
bundleURL: 'https://domain.com/url/to/html')); }Copy the codeKraken uses HTML parsing or JavaScript engine startup based on HTTP Content-Type negotiation.
Performance test:
Testing equipment: MI 11 Lite (Android arm64) test page: kraken.oss-cn-hangzhou.aliyuncs.com/data/… Js test method: use 0.9.0-RC to start each cold page in JSBundle/Bytecode/HTML format, and compare the loading time.
| The test group | Total Time Cost (average) |
|---|---|
| JS Bundle | 865ms |
| Bytecode | 662ms |
| HTML | 255ms |
Supports HTTP caching
As we all know, the ultimate programming problem is naming variables and using caches.
The browser supports HTTP caching by default, including strong caching and negotiation caching. It is a specification for describing caching formed by multiple HTTP Headers combinations. HTTP caching is not included in the client ecosystem or in the underlying capabilities of Flutter. Kraken V0.9 supports HTTP caching by default. No matter XHR/ FETCH or images loaded by img tag, JS files loaded by script tag, etc., as long as HTTP(S) requests are sent from Kraken, Can enjoy the benefits of caching, currently supported features include:
- Strong caching without secondary requests
- Expires
- Cache-Control (max-age/no-store/no-cache)
- Negotiation cache that requires a second request (negotiated according to HTTP status code 304)
- Last-Modified / If-Modified-Since
- Etag / If-None-Match
This function Feeds to electricity goods flow and so on page contains a lot of pictures of the scene, the optimization of the benefits is more apparent, because the picture is almost all cache types of resources, in the case of a cache hit again without request network, and the cache is curing of disk cache, for secondary cold rev. Applications can also enjoy the optimization.
Support Vue/React official tool chain
Front-end developers are the audience for Kraken, and we continue to receive feedback from community developers after we open source.
A framework is essential for modern front-end development. In addition to the widely used Rax, we have recently added support for the official Vue and React toolchains and ecosystems. Now v0.9 will make developing Vue/React apps smoother.
Please refer to the official example project: github.com/openkraken/…
Support for Hot Module Replacement
Module hot updates are a common feature of Webpack, allowing you to replace, add, or remove nodes after code changes without reloading the entire page. Webpack official documentation
QuerySelector/querySelectorAll* is supported
At the same time we also do to calls for a larger querySelector/querySelectorAll support, has now support CSS selectors include:
- Id Id selector
- Class Class name selector
- Tag Indicates the tag selector
- Attr attribute selector, which contains the following judgments
- =
- ^ =
- * =
- $=
* : Currently, only some CSS selectors are supported. For details, see the above description.
More on North Sea KRAKEN
Community collaboration mechanism
We hope to build the underlying capabilities and ecology of Kraken together with many developers in the community through a good community collaboration mechanism.
The Kraken team participates in Kraken feature iterations and issue discussions in a collaborative manner. At the same time, a technical committee (TSC) composed of a group of collaborators determines the technical direction, releases, and customizations of standards.
Simply put, you can become a collaborator by submitting a certain quantity and quality of code to the Openkraken Group; After submitting constructive contributions to the project, TSC members have the right to nominate collaborators to participate in the TSC.
The Kraken team hopes that through a friendly, participatory and collaborative mechanism, developers in the community can better participate in the evolution of the project, so that everyone’s voice can be heard and contribute to the development of Kraken and the development of Web standards.
A more detailed collaboration mechanism can be found at Github TSC.
Previous articles are recommended
- Beihai, a Web rendering engine based on Flutter, is officially open source
- Kraken V0.8.0 — Supports Flutter 2.0
- The technical principles of “Beihai Kraken”, Flutter’s Web rendering engine
Contact us
For details about CHANGELOG, see CHANGELOG. For more information about Kraken, please visit our Github and official documentation to contact the Kraken project team.