diff --git a/components/content/X__Blog__2023-12-19-mac202319__Figure1.vue b/components/content/X__Blog__2023-12-19-mac202319__Figure1.vue
new file mode 100644
index 00000000..08ed1edc
--- /dev/null
+++ b/components/content/X__Blog__2023-12-19-mac202319__Figure1.vue
@@ -0,0 +1,58 @@
+
+
+
+
+
Child Components
+
Chart.js, etc.
+
+
+
+
+
OS
+
Global Components
+
UI Components
+
+
+
+
+
Fastify
+
Pug
+
BOOT LOADER
+
+
+
+
+
+
Hello, world!
+```
+
+
+スタイル属性
+
+
+
+
+
+```html
+
+Hello, world!
+```
+
+
+スタイル要素
+
+
+
+
+
+```html
+
+Hello, world!
+```
+
+```css
+.red {
+ color: red;
+}
+```
+
+
+スタイルシート
+
+
+
+このうち, 最後のスタイルシートによるスタイル連繫は, コンポーネントのロジック部分とスタイル部分が分離されることで, それぞれのライフタイムの長寿化を期待することができるため, プロダクションにおいては望ましい形式といえます. スタイルシートのスタイルルールは, セレクタを記述して, 条件に合致する要素にスタイルを適用するよう Web ブラウザに指示します. セレクタは大局的なものから局所的なものまで多種多様な指定が可能ですが, コンポーネントのパーツに細かくスタイルをつけていくという状況においては, そのほとんどは局所的かつ単純なものになります. なお, 再利用性を担保してなるべくシンプルにセレクタを記述する方法は, 単一のクラス名を指定するのが, もっともパフォーマンスが高いとされています. この理由をきちんと説明するには, Web ブラウザの実装の話などが大きく絡むので, ここでは割愛します.
+
+Misskey と Vue.js に話を戻すと, SFC にはスタイルシートを直接記述できる機能が備わっています. この機能を使用して SFC にスタイルを直接記述すると, vue/compiler-sfc によってスタイルシートが抽出され, @vitejs/plugin-vue によって仮想モジュールとして Vite に参照されるようになり, 最終的に Vite がそれらをバンドルします. このおかげで, 成果物として適切な様態で CSS が配信されることを保証しながら, 一方で開発体験としてはコンポーネントごとに関心を寄せてスタイルを記述できるようになります.
+
+さて, 個々のコンポーネントが自由にスタイルを記述し, それを統合した場合, 実際にはそれらのルールが意図せず他のコンポーネントに影響を及ぼしたりする問題が予想されます. SFC の機能には, この問題を避けるため, スタイルをコンポーネントのスコープに閉じ込めるよう指示できるものがあります. スコープ付き CSS は, ビルド時にコンポーネント毎に一意の識別子を生成し, コンポーネント内の要素にそれを属性として割り当て, スタイルシートのセレクタにも書き足すことで, ユーザーのコード変更なしにスタイルをスコープに分離することができます. SFC のタグに属性を足すだけでドロップインに使用できる手軽さから, 多くの Vue.js ユーザーに使用され, Misskey もかつて主方針として使用していました. しかしその実, [スコープは完全ではなく](https://github.com/vuejs/vue-loader/issues/957), また, セレクタが肥大化してしまう問題も孕んでいました.
+
+より踏み入った代替策として, SFC では CSS モジュールを使用することができます. これは, ビルド時にセレクタのクラス名を機械的に再構成し, そのバインドを JavaScript で参照できるようにするものです. コンポーネントにおけるテンプレート内のクラス名は直接指定ではなくバインドされるフィールドへの識別子に置き換える必要があるので, コンポーネントのリファクタリングが必要ですが, スタイル連繋における課題点は概ね払拭されます. 現在の Misskey では, ほとんどのコンポーネントが CSS モジュールを使用しています.
+
+## CSS モジュール注入の最適化
+
+Misskey が CSS モジュールを使うようになった後のある日, syuilo は言いました.
+
+:::fukidashi{chara="syuilo" charaName="しゅいろ"}
+えー、CSS Modulesってminifyしてくれにゃいんだ
+
+
+:::
+
+— https://misskey.io/notes/9fd9w06qah
+
+このノートには, CSS モジュールのクラス名バインド用マップが成果物に丸々含まれていることを憂う気持ちが込められています. 例えば, 次のような SFC があったとします.
+
+
+
+```vue
+
+ Hello, world!
+
+
+
+```
+
+
+赤色で挨拶文を表示するコンポーネント
+
+
+
+このコンポーネントは次のように変換されて欲しいです.
+
+
+
+```jsx
+export const HelloWorld = defineComponent({
+ setup() {
+ return () => jsx( // 実際にはより具象的なコードになる
+ Hello, world!
+ );
+ },
+});
+```
+
+```css
+.r3a9t {
+ color: red;
+}
+```
+
+
+理想的な変換後のイメージ
+
+
+
+しかし, 実際には, 次のように変換されてしまいます.
+
+
+
+```jsx
+export const HelloWorld = defineComponent({
+ setup() {
+ return (_ctx) => jsx( // 実際にはより具象的なコードになる
+ Hello, world!
+ );
+ },
+});
+
+HelloWorld.__cssModules = {
+ $style: {
+ redColoredText: "r3a9t",
+ },
+};
+```
+
+```css
+.r3a9t {
+ color: red;
+}
+```
+
+
+実際の変換後のイメージ
+
+
+
+このようなことになってしまうのは, バインドの参照を常に静的に置換できるとは限らないためです. 例えば, $style.redColoredText のような参照は静的に置換できても, $style\[color + "ColoredText"\] のような参照はビルド時に color の値が定まるとは保証できないので, 静的に置換できません. また, Vue.js の Composition API では, useCssModule() を呼び出すことで, バインド用のマップ全体を取得することを許容しています. このような経緯で, 成果物にマップがそのまま含まれているのです. 逆に, それらの機能を一切使わないのであれば, 完全にそれらは無駄になっているといえます. 完全に無駄なものは安全に除去できるはずです. そこで, Misskey では, $style 配下を識別子のメンバーアクセスによる参照のみを認めるルールで運用することを前提に, 静的置換を行う Rollup プラグインを開発および使用することで, 成果物からマップを除去するようにしました. これにより, バンドルサイズの 3% 程度の削減につながりました.
+
+:::tip
+詳細は [#10923](https://github.com/misskey-dev/misskey/issues/10923) を参照してください.
+:::
+
+## 今後の展望
+
+現在まだ取り組まれていない最適化として, ルーティングの静的化を検討しています. 記事の最初の方に提示した図を見ると Router がレイヤーの中でも上部にあることがわかります. そのため, Page Components の読み込みはページが読み込まれてしばらくしてから始まります. しかし, どのルートがどのページを表示するかはビルド時にほぼ決定できると言って差し支えありません. この情報を静的に管理してバックエンドに連繫することで, バックエンドはより早いタイミングでユーザーエージェントに必要なアセットを知らせることができるので, ユーザー体験の向上を見積もることができます.
+
+ここで, SFC の機能を利用して,
+
+```vue
+
+
+
+
+
+
+
+name: note
+path: /notes/:noteId
+
+```
+
+といったようにページコンポーネントに直接ルーティング情報を記述できれば, ビルドの際ルーティング情報を抽出して静的に集約でき, ついでに path props も同一ファイル内で管理でき, 保守性の向上にもつながります.
+
+あくまでも構想かつ一例にすぎませんが, このようにコンパイラの機能を使用するなどして, Misskey の開発では今後も表層的な枠組みに囚われず, 野心的に様々なものを活用し, より良いユーザー体験に貢献できるよう努めていきたいと思っています.