You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+35-12Lines changed: 35 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
# JSON/CSS Module notes
2
2
[JSON modules](https://github.com/whatwg/html/pull/4407) and [CSS modules](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) provide several ergonomic benefits for web component developers. They provide easy integration into the JavaScript module graph with automatic deduping of dependencies, and eliminate the need to manually manage `fetch()`es or pollute the DOM with extra `<style>` and `<link rel="stylesheet">` elements.
3
3
4
-
Additionally, there are important quantitative performance advantages to JSON and CSS modules over the current equivalents. This document describes these advantages and illustrates them with code samples.
4
+
Additionally, there are important behavioral differences and quantitative performance wins to JSON and CSS modules over the current equivalents. This document describes these advantages and illustrates them with code samples.
5
5
6
-
## A performance-equivalent JSON module can't be built with JavaScript modules
6
+
## An equivalent to JSON modules can't be built with JavaScript modules
7
7
8
8
A naive attempt to replicate the functionality of JSON modules with a JavaScript module wrapper might look something like this:
9
9
@@ -58,7 +58,7 @@ export default jsonObject;
58
58
or alternatively:
59
59
60
60
```JavaScript
61
-
let response =awaitfetch("./data2.json")
61
+
let response =awaitfetch("./data.json")
62
62
let responseText =awaitresponse.text();
63
63
let jsonObject =JSON.parse(responseText);
64
64
exportdefaultjsonObject;
@@ -71,30 +71,53 @@ From the perspective of the importer this is ergonomically more or less equivale
71
71
72
72
And the above depends on the standardization and broad adoption of top-level await. Until that happens, devs are stuck exporting a Promise that the importer needs to deal with.
73
73
74
-
## Demo 2
75
-
### [CSS/JSON modules have a lower memory footprint than inlining the CSS/JSON as a JavaScript string](https://dandclark.github.io/json-css-module-notes/demo2/index.html)
74
+
## CSS Module Performance/Memory examples:
75
+
76
+
### Demo 1: [Overhead from `<style>` or `<link>` elements in custom element shadow root](https://dandclark.github.io/json-css-module-notes/demo1/index.html)
77
+
78
+
A common way of applying a custom element's styles is to include a `<style>` element or (perhaps less commonly?) a `<link>` element in the custom element's shadow root. This suffers from the problem that for each instance of the shadow element that exists on the page, there is an additional copy of the `<style>`/`<link>` element that gets stamped out. It costs CPU cycles to instantiate these extra elements, and do the necessary work when they are connected to the document. There is also memory overhead for their allocations.
79
+
80
+
A custom element that pulls in its styles with CSS module, however, only processes the stylesheet one time, when the sheet is imported, and there is no cost for an additional element in each custom element instance's shadow root. For a page that has many instances of the custom element, this can result in percievable performance and memory differences.
81
+
82
+
[Demo 1](https://dandclark.github.io/json-css-module-notes/demo1/index.html) illustrates this difference with a custom element written 3 different ways: with a `<style>` element in each shadow root, with a `<link>` element in each shadow root, and with a single CSS module applied to each shadow root's `adoptedStyleSheets`. To make the performance differences easily distinguishable, each page includes 15,000 instances of the respective custom element version.
83
+
84
+
I generally observe the CSS module element version loading about 1 second faster than the `<style>` element version, though the difference will vary per machine.
85
+
86
+
The `<link>` element version loads much more slowly:
91
+
92
+
93
+
94
+
It's not clear why `<link>` is so much slower; caching should prevent it from making a new network request for each element instance. There might be a Chromium bug here, but in any case we expect that the performance best case should be similar to the `<style>` version.
95
+
96
+
There are also memory savings from omitting the extra elements. After reaching baseline (putting tabs in background and waiting for final GC at ~60 seconds) I see these numbers:
### Demo 2: [CSS/JSON modules have a lower memory footprint than inlining the CSS/JSON as a JavaScript string](https://dandclark.github.io/json-css-module-notes/demo2/index.html)
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested a custom Chromium build).
79
104
80
-
An alternative non-module approach for packaging CSS/JSON in a custom element is to inline the content as a JavaScript string rather than `fetch()`ing it dynamically. This string can be fed into a [Constructed Stylesheet](https://developers.google.com/web/updates/2019/02/constructable-stylesheets) or a `<style>` element.
81
-
This eliminates any concerns about a a delay in the `fetch()` as outlined above. However, in addition to the clunky developer ergonimics
82
-
of a bunch of inlined JavaScript string content in one's custom element JS logic, this approach has a quantifiable memory cost. This is due to the fact that the original JS string lives on alongside the CSSStyleSheet or JSON object that it is eventually parsed into. Whereas with CSS/JSON modules, nothing persists but the CSSStylesheet or JSON object.
105
+
An alternative non-module approach for packaging CSS/JSON in a custom element is to inline the content as a JavaScript string rather than `fetch()`ing it dynamically, and feeding it into a [Constructed Stylesheet](https://developers.google.com/web/updates/2019/02/constructable-stylesheets).
106
+
This eliminates the issues in Demo 1 where extra work is repeated for each custom element instance. However, in addition to the clunky developer ergonimics
107
+
of a bunch of inlined JavaScript string content in one's custom element JS logic, this approach can still have an extra memory cost. This is due to the fact that the original JS string lives on alongside the CSSStyleSheet or JSON object that it is eventually parsed into. Whereas with CSS/JSON modules, nothing persists but the CSSStylesheet or JSON object.
83
108
84
109
[Demo 2](https://dandclark.github.io/json-css-module-notes/demo2/index.html) illustrates this difference. Both the no-module and the module case load a custom element that pulls in ~30MB of CSS. The no-module case imports inlines it in the JS file defining the custom element, in the style of some of the [existing Chromium layered API elements](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/script/resources/layered_api/elements/). The module case imports the same CSS as a CSS module. After reaching steady-state, the memory difference is around the same ~30MB as the raw CSS text:
85
110
86
111
87
112
88
113
This steady state is reached after leaving both tabs in the background for ~60 seconds. Before this final garbage collection, the difference is even more stark; in my observations the inline CSS case hovers around ~95MB for the first 60 seconds, whereas the CSS modules tab goes down to ~38MB within the first few seconds.
89
114
90
-
91
-
## Demo 3
92
-
### [CSS modules vs `<link>` elements in shadow roots](https://dandclark.github.io/json-css-module-notes/demo3/index.html)
115
+
### Demo 3: [Delayed stylesheet fetching for `<link>` elements in shadow roots](https://dandclark.github.io/json-css-module-notes/demo3/index.html)
(There is no general CSS modules browser support as of this writing; that part of the demo was created and tested using a custom Chromium build).
96
119
97
-
This demo compares two similar custom elements written as a JavaScript module, each of which loads its styles from a separate `styles.css` file. The first custom element applies its styles by adding the styles via a `<link rel="stylesheet">` in the custom element shadow root. The second loads its styles via a CSS module.
120
+
This demo shows an additional disadvantage to using `<link>` in a shadow root to load a custom element's styles. It compares two similar custom elements written as JavaScript modules, each of which loads its styles from a separate `styles.css` file. The first custom element applies its styles by adding the styles via a `<link rel="stylesheet">` in the custom element shadow root. The second loads its styles via a CSS module.
98
121
99
122
With the `<link>` element approach, the `<link>` isn't processed until an instance of the custom element is inserted into the document. In [demo3/NoModule.html](demo3/noModule.html), there is a delay before an instance of the custom element is created and inserted (to simulate, for example, a custom element that is only added based on some user action) and thus a corresponding delay before styles.css is fetched.
0 commit comments