Closed6

Remix+CloudflareでWebサイトを作る 19(MUIスタイル速度比較・sx排除・コールドスタートの影響は?・MUIを名前付き→デフォルトimportに)

saneatsusaneatsu

【2024-03-24】MUIコンポーネントのスタイル付与の速度比較

https://zenn.dev/enish/articles/a2314fc2c00cf7#速度まとめと感想

各記述方法での速度は早い順に
CSS+className => emotion => MUI styled => MUI createBox => MUI sx props
という結果になりました。
・とにかく速度重視ならCSS
・通常はstyled or emotion
・themeを利用するならsx props

Box(div)程度のワンタイムカスタマイズではthemeを使わない限りはstyleを利用したほうがよい、というのが新たな知見だったかなと思います。

まずはtheme以外でsx propsを書くのを辞めてみる。
そのあとなるべくJoy UIのコンポーネントから脱却していく。

saneatsusaneatsu

【2024-03-24】MUIのsx propsをなるべく排除する

修正

ということでthemeに関わるところだけsxで書くが、その他は基本的にstyleで書く。
何回か計測したら良くもなったし悪くもなって誤差レベル。
多分import方法治すほうがインパクトでかそう。

思えばv2.6の時(= MUIのimport方法を変える前)はこんな目に見えるほど処理重くなかった気がする。

Before

After

因みに

Zennのトップページのスコア

Togetterのスコア
早くはないけど、このスコアの低さほど遅さを実感しないんだよな。
逆に自分の方はスコアがTogetterより高いけど明らかにBad UXで「このページおっそ...!」ってなる。

saneatsusaneatsu

【2024-03-24】 Coudflare Workersのサイズが1MBを超えているから初期描画が遅いのか?

https://zenn.dev/chimame/articles/d3e7af9a612038#結論(2024%2F3%2F19時点)

この記事には以下の記述がある。

Cloudflare Pages FunctionsつまりはCloudflare Workersはサイズが大きくなればなるほどコールドスタートの時間に影響が出てきます。

https://zenn.dev/msy/articles/4c48d9d9e06147#サーバレス環境のコールドスタート問題について

しかしこちらの記事には以下のような記述がある。

サーバーレス環境ではコールドスタートと呼ばれる問題が発生することがあります。
コールドスタートは、サーバーレス環境で初めて関数を呼び出したときに、その関数を実行するために必要なコンテナが起動されるまでに時間がかかる問題です。
このため、初回の呼び出しは遅延が発生し、パフォーマンスが低下することがあります。
また、サーバーレス環境では、起動状態のコンテナを維持することができないため、一定時間アクセスがない場合にはシャットダウンされます。そのため、再度関数が呼び出された場合には、再びコールドスタートが発生する可能性があります。

なので、gzipにした時に1MBを超えているから初期描画が遅いのかと思ったが、更に読み進めていくと以下のような記述がある。

Cloudflare Workersではコンテナが使用されていません。
その代わりにWorkersのランタイムとしてJSのV8エンジンを使用しています。

リクエストがCloudflareに到達する前のハンドシェイクの段階でWorkers Runtimeは起動されるためコールドスタートはゼロになります。
それゆえにWorkers Runtimeは、クライアントからのリクエストをCloudflare経由で受信した瞬間に処理の実行を開始することができます。

ん?関係ないのか?

https://www.cloudflare.com/ja-jp/learning/serverless/serverless-javascript/

公式が言うには以下。

JavaScriptコードの実行にV8を使用すると、JavaScript Workersの起動時間が大幅に短縮され、ほとんどの場合「コールドスタート」の問題がなくなります。

なさそうな気がする。

saneatsusaneatsu

【2024-03-25】MUIのdefault import時のError: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.というエラーを解消できた

問題

2つ前の【2024-03-24】MUIのsx propsをなるべく排除する にRemix v2.6でViteを使ったらimport方法がエラーになる問題、綺麗じゃないけど解決できた。

// 🚨 エラーになる
// Unexpected Server Error
// Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
import Box from '@mui/joy/Box';

// ✅ エラーはでないがパフォーマンスが悪くなる(?)
import { Box } from "@mui/joy";

今まではうまくいく方法で書いていたがこれだとパフォーマンスに悪影響がでている可能性が出てきた。
実際にRemix v2.6から2.7にしてこのimport方法にしてから遅くなった、気がする。

https://zenn.dev/tttela/articles/1e1d171bb5ece3522e87

結論

https://github.com/brillout/vps-mui/commit/89dd9925276ad8dab2238761332fb5f8e5efb407

以下のようにする。

import _Box from "@mui/joy/Box";
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore
const Box: typeof _Box = _Box.default ?? _Box;

経緯


MUIのIssueにヒントないかなということでまずはエラー文で検索

その中の1つのIssueに回答したよ、とのことでvikeというリポジトリのIssueのURLが貼られている

なんか解決してるぞ、ということでvps-muiというもののリンクを見にいく。

ありがとう...世界の誰か...!
ググるだけじゃなくてIssue見に行くの大事。

一旦全部このImport方法にリプレースしてみてパフォーマンス見よう。

saneatsusaneatsu

【2024-03-24】MUIのimport方法named import→default importにする

import方法のバグが直せそうなので全部default importにしてみる。

結論:あんま変わらん。

Before

2回実行した


After



このスクラップは2024/03/25にクローズされました