Why does the Qwik SDK's `<Content />` component bloat the page response so much?

Technical Questions QWIK SDK
1

Does anyone know why the Qwik SDK’s <Content /> component bloats the page response so much?

When using it to render a simple footer (section model). The JSON from builder is only 30KB. The HTML, once rendered, is only 100KB. Yet the overall page response size is increased by well over 500KB. Combining this with the content rendered for the page itself and each page response is now well over 1MB in size for very simple content.

Please don’t ask me to provide an example, this happens for even the most basic content every time the component is used. Please just provide a full explanation as to why this happens and what the likelihood of it being resolved in the near future is.

This will enable Qwik developers to better assess whether using the drag-and-drop builder editor OR using Builder.io as a headless CMS better suits their project.

If I use Qwik API, the response is far far smaller, but then I miss out on certain features?

The builder marketing website talks a lot about “without performance trade-offs”, but this is exactly the kind of performance trade-off that the marketing content on the website hints at eliminating :melting_face:.

2

Hello @latchdigital,

The issue of increased response size when using the <Content /> component from the Qwik SDK can be attributed to a few factors inherent in how Qwik functions as a framework. Here are some insights:

  1. Virtual Nodes and Serialization: Qwik requires virtual nodes to manage component states and for serialization purposes. This includes attaching properties to components, updating signals, and having references for components to maintain resumability without re-rendering on the client side. This information, while essential for Qwik’s operation, adds to the size of the content being sent to the client.

  2. Streaming and Pruning: Qwik streams HTML data to the client, and at times, it may generate extra content just as a precaution (just-in-case content). The components might include more virtual nodes than necessary, as Qwik cannot determine component statics or needs until the entire application is analyzed.

  3. Content Enrichment: If the enrich option is used, it can significantly increase the size of the content sent by including multi-level references and symbols in the response to ensure a consistent experience between the Visual Editor and the live site.

  4. Qwik’s Serialization Method: The serialized data includes serialized props and state that are needed for resumable features. This can add to the perceived bloat when compared to more straightforward text-based rendering or less dynamic frameworks.

While these strategies mean more data is initially sent to maintain these advanced capabilities, they also enable features like resumable applications which do not require rehydration and provide segmented loading based on user interactions. Optimizations are being worked on in Qwik 2.0, which aim to reduce this overhead by moving non-human-readable data to the end of the HTML stream and improving the encoding scheme for virtual nodes.

If using the Qwik API directly results in a smaller response size, it may sacrifice some of these dynamic and interactive functionalities provided by the <Content /> component. Steps like minimizing the use of enrich, proper pruning, and leveraging caching can help balance functionality and performance.

We hope this helps!

Thanks,