Notes on Twind runtime performance (observe/shim, just-in-time stylesheet creation)

[danielweck]

Discussion topic started in this "issue":

#157 (comment)

(moved here to avoid polluting the main conversation thread)

Fun test: use Twind/shim to render https://tailwindcss.com (a really impressive landing page packed with cool interactives!)

---

---

SPOILER ALERT: Twind shim/observe is slower than precompiled stylesheets, and on first impression it even seems much slower. However when configured appropriately, it is actually impressively fast! Details below.

---

---

I "downloaded" a local copy of the website's landing page ("save as" from Chrome), and I ran Lighthouse's "performance" test from a localhost HTTP server:

Desktop:

Mobile:

---

Then, I removed the Tailwind CSS stylesheet, and I added:

<script type="module" src="https://cdn.skypack.dev/twind/shim"></script>

(Skypack CDN, but I ran a local test too, see further below)

**EDIT: this is a suboptimal method for loading Twind, due to the async / deferred nature of ECMAScript modules. Traditional script loading yields much better perceived and measured performance due to scheduling layout recalc in relation to the DOMContentLoaded event. Please make sure to read the entire thread below to see much improved performance figures :) **

Desktop:

Mobile:

---

Finally, I replaced the Skypack CDN Twind/shim script link with locally-hosted copies:

Desktop

Mobile

Here's the performance flamegraph:

Without Twind:

With Twind:

(the activity graph on the left hand side is Twind's observe aka "shim" immediately after DOMContentLoaded, working its way through the DOM to build the stylesheet just-in-time)

@sastan :

These results are to be expected because the shim kicks in after DOMContentLoaded.
For production sites we recommend critical CSS extraction.
I'm currently experimenting with one or two ways to optimize this. One of them is:

<script>
// Inline https://unpkg.com/twind/twind.umd.js
// Inline https://unpkg.com/twind/observe/observe.umd.js

twindObserve.observe(document.documentElement)
</script>

Could you try that one?

Sure. My current test is with:

  <!-- script type="module" src="https://cdn.skypack.dev/twind/shim"></script -->
<!-- LOCALHOST COPY: -->
  <script type="module" src="./shim.js"></script>

---

---

---

Much better :)

---

---

---

Desktop

Mobile

Interesting flamegraph now:

[danielweck]

@sastan you can see in the performance flamegraph (immediately above) the DCL event (DOMContentLoaded) in the blue box on the right hand side (the hydrate phase is immediately after), and some fragmented activity before DCL. I interpret this as the HTML markup being parsed and observe triggering incrementally, as opposed to a single pass after DCL? (see the other flamegraph further above)

[danielweck]

Yeah, and my visual assessment matches the Lighthouse score too. I retract my previous statement:

The performance metrics reported by Lighthouse are equally good with the type="module" method

(I made a mistake in my measurements)

[danielweck]

I should also explain that I tried:

  <script type="module">
    import { createObserver } from 'observe.js';
    const twindObserver = createObserver();
    twindObserver.observe(document.documentElement);
  </script>

and (async):

<script type="module" src="tw.js" async> </script>

and (defer):

<script type="module" src="tw.js" defer> </script>

...with tw.js:

    import { createObserver } from 'observe.js';
    const twindObserver = createObserver();
    twindObserver.observe(document.documentElement);

=> same results (async is more likely to kick in after DOMContentLoaded, whereas defer in principle occurs before the DCL event).

[ggoodman]

But we could try to detect if there is twind CSS in the page from (critical CSS extraction on the server) and prevent the initial run you see in the graph and go straight to just observing.

This sounds like something that could dramatically reduce the amount of work needed in an SSR -> CSR transition. Love it!

[danielweck]

This is equally performant, no need to inline the scripts:

  <script type="text/javascript" crossorigin="anonymous" src="https://unpkg.com/twind@0.16.9/twind.umd.js"> </script>

  <script type="text/javascript" crossorigin="anonymous" src="https://unpkg.com/twind@0.16.9/observe/observe.umd.js"> </script>
  <script  type="text/javascript">
    twindObserve.observe(document.documentElement)
    </script>

[danielweck]

As you can see, when fetching the scripts from the unpkg CDN, the pre-hydration activity is less fragmented:

[danielweck]

@sastan I added the following paragraph in the introduction post, to avoid misleading readers:

SPOILER ALERT: Twind shim/observe is slower than precompiled stylesheets, and on first impression it even seems much slower. However when configured appropriately, it is actually impressively fast! Details below.

[danielweck]

I also added the following clarification in the thread:

**EDIT: this is a suboptimal method for loading Twind, due to the async / deferred nature of ECMAScript modules. Traditional script loading yields much better perceived and measured performance due to scheduling layout recalc in relation to the DOMContentLoaded event. Please make sure to read the entire thread below to see much improved performance figures :) **

[sastan]

I implemented the umd+observe method on twind.dev

Before: https://lightest.app/c/HpfJQxGTN2

After: https://lightest.app/c/WrH41q_VYB

[danielweck]

...looks like Twind's doc pages (TypeDoc-generated) could be much leaner :)

https://estimator.dev/#twind.dev/docs/

See:

https://github.com/tw-in-js/twind/tree/main/docs

=>

https://github.com/sastan/typedoc-plugin-pages
+
https://github.com/TypeStrong/TypeDoc

[sastan]

Yes. working on in the docs #124 PR

[danielweck]

Yes. working on in the docs #124 PR

Oooh, very nice! 👍 Thanks for the "heads up".