Hello everyone, I am Yisar, a Javascript developer from China.
In China, there are few web pages, but just three months ago, I joined a game company. We have foreign websites and some foreign users.
I led our team to start the SSR transformation of our website, but finally failed because the QPS is too low.
This is because the SSR isomorphism requires the generation and traversal of vdom, and the server side cannot afford such computation.
No matter vue or react, or even preact or svelte, they all face the same difficulties.
Is there really no way？
Asta.js
Finally, I decided to write a new framework to optimize the characteristics of SSR, with the goal of solving the performance bottleneck of SSR.
It is meaningless to discuss performance beyond bottlenecks. If we want to optimize, we should start with performance bottlenecks
Server side bottlenecks, Jointing on Server
The biggest performance bottleneck of SSR lies in the server side. The server is very fragile. The traditional homogeneous SSR framework requires the generation and traversal of vdom, which brings pressure on the CPU. If the experience is not enough, it is also easy to leak memory.
To solve this problem, Asta has a jsx compiler, which no longer generates vdom, but now generates s functions for string splicing.
// jsx input
const view = ({list}) => <div>{list.map(i=><i>{i}</i>)}</div>
// server output
const view = ({list}) => s.openTag('div')+s.expression(list.map(i=>s.openTag('i')+s.text(i)+s.closeTag('i')))+s.closeTag('div')
It does not need babel, and perfectly retains the semantics of js.
It is worth mentioning that this is also completely feasible at the data structure level. All tree structures can be expressed through linear structures.
The second performance bottleneck on the server side is the component itself. The initialization, private state (usually publish and subscribe), and lifecycle of the component are huge performance overhead and difficult to be optimized by the compiler.
To solve this problem, Asta uses Elm's state flow model. The component itself has no state, and all states flow from the global single state tree from top to bottom.
export const loader = async (req) => {
const data = await fetch('http://localhost:1234/data')
.then((res) => res.json())
.then((data) => data)
return {
title: data.title,
}
}
const Header = ({ title }) => (
<header>
<h1>{title}</h1>
</header>
)
export default ({ title }) => {
return (
<div>
<Header title={title}/>
<div>
)
}
Yes, components are also pure functions, which are only used to splice strings without any overhead.
Pressure test results.
After these two optimizations, the performance of asta is super good. We pressure tested a simple application with an interface in the company, and the results are as follows.
Because Vue3 has the template compilation optimization of block tree, its QPS is higher than nextjs, but it still cannot avoid component overhead.
Asta's QPS is amazing. It's even much higher than Markojs.
Resumable on client
We have solved the performance bottleneck on the server side. We begin to focus on the client side. The performance cost of traditional SSR lies in full hydration.
A new concept named Resumable comes from Qwik.js, its basic idea is not to hydrate, serialize the necessary information into html, and then use vdom and dom on the client side to diff to directly recover the information.
Resumable
It is very suitable for the mental model of asta, so I implemented it easily.
In addition, in order to reduce the size of the client side js, people have also come up with other methods, such as selective hydration, islands, server components. However, the mental models are too corrupt, so we won't discuss them one by one.
Resumable is better at 0 js and Google scoring.
Summary
To sum up, after double optimization, asta has no bottleneck in its performance. It is open source. The github address is here.
If you are interested, you can run the demo to try, and you will understand.
I am a Chinese, so I may not use English all the time, but I also welcome exchanges.
Top comments (0)