Remix+CloudflareでWebサイトを作る 24（CfのCache Ruleを設定・Joy UI→Tailwindに変更・Darkモード対応）
saneatsu【2024-05-12】Cloudflare PagesのCache Rulesを設定する
こっちで決めた「Next Action」をやる。
設定する
ホスト名にhttps://example.com と書いてしまって全然反映されなかった。
正しくは example.com...。
1回目にリクエスト。MISSになっている。
2回目。HITしたことが確認できる🎉
測定する 1
Joy UIを削除して1000msオーバーを叩き出した時は1回アクセスしてから5分後とかに実行したときなので、今回も5分ほど待ってからLighthouseで測定する。
830ms。改善せず😔
1分後にもう1回実行すると30ms。早すぎ。
ちゃんとキャッシュされてるのか？
キャッシュは1日保持するように設定したが、5分ほど時間をおいてアクセスしてからResponse HeaderをみるとCf-Cache-Status: MISS になっている。
1日保持するならHITになるはずでは...？
以下のような条件もキャッシュには必要とのこと。
・Cache-Controlがpublicに設定されている
・max-ageが0より大きい or Expiresヘッダーが未来になっている
Response HeaderのCache-Control: max-age=14400 = 4時間だがこれは「Caching > 構成」で設定できる。
修正する
こう設定したのを...
こうした。
測定する 2
お？5分待っても早いぞ！！快適すぎ🙃
5分待って計測、を何回か繰り返したけど最大でも40ms！！
すごい！！
Joy UIを戻して再計測しよう。
saneatsu【2024-05-13】Joy UI使ったページで「最初のサーバー応答時間」を計測してみる
計測
1回目。1600ms。
2回目。30ms。キャッシュが効いてる。
3回目。580ms。キャッシュが効いてる...？
結論
ん〜いくらなんでも1回目が遅すぎるんだよな。
数値で見ても遅いし、体感でも「あれ、遷移するためのボタン押したよな？？」ってなるくらいには遅い。
【2024-05-12】初期描画が遅い原因を探る のNext Actionで書いた2つ目「2. UIコンポーネントを変えて再度測定してみる」をやってみる。
SSRとかサーバーの最適化などについてあまりわかってないけどそれでも遅い場合、そもそもサーバースペックの問題とかもあるのだろうか？
ChatGPTに効いてみると解決方法は以下。
- キャッシュを利用して、再レンダリングを最小限に抑える。
- 対応済
- コンポーネントのレンダリング時間を短縮するために、コンポーネントを最適化する。
- 次に対応する
- CDN（Content Delivery Network）を利用して、ユーザーに近い場所からコンテンツを提供する。
- サーバーのパフォーマンスを向上させる。
- コンポーネント最適化の後の結果を見て対応する
saneatsu【2024-05-14】Hello, shadcn/ui + Tailwind CSS
導入
公式がちょっと古かったのでここを見ながらインストール。
前回の測定結果
測定
Joy UIを完全に剥がして同じUIをTailwind CSSで作り直した。
「API連携無しのページ」「API連携有りのページ」の初期描画速度を測定する（Cloudflare側のキャッシュは無効にしている）。
ばーっと勢いのままに作ってたらshadcn使わずにすべてTailwind CSSだけで実装してしまっていた。
つまりJoy UI→Tailwind CSSへの変更ということになった。
早い。
API無しのページはに複数回測定したがだいたい250〜500ms。
600ms以内に収まった。
以前は600ちょいオーバーという感じだったので良かった。
やたらsxとか使ってたのは良くなかった気がするけどそんなに遅くなるのかな？？
ページ遷移遅い問題について
初期描画後一番初めにページ遷移する際にボタンをクリックしても1秒くらい待ってから遷移してしまう問題については多少ましになった気もするが治っていない。
これはサーバー側な気がする。
今回検証用に作ったのはめっちゃ簡素なページだしフロント側の実装が問題なわけではない、と思う。
saneatsu【2024-05-14】Lighthouseで指摘されている「使用していない JavaScript」を削除する
現状
一旦初期描画の問題はTailwindで解決された、ということにする。
次はLighthouseで指摘されている以下の問題に対応する。
これ何？
つまり...
- 「使用していない JavaScript」とは、Web ページに含まれているものの、そのページの読み込みや操作時には実行されない JavaScript のコードのこと
- 外部リソースに含まれる JavaScript のコードを最適化し、Web サイトの表示速度を改善させる目的で出ている
- 使用されていないJavaScriptが多くあることでページの読み込み速度を低下させる可能性がある
- 未使用コードは20KiB以内だとOK
どこが不要なのか？
Coverageを見てみる
この記事に書いてあるようにDev toolのCoverageを見てみる。
ほぼChrome拡張では？と思ったけど違うところもちょくちょくある（赤枠部分）
どうやらこの赤枠部分はLighthouseの「ツリーマップで見る」をクリックして表示される「使用していないバイト」が最も多いファイルと一致する。
クリックしてみる。
どうやら、自分が全く書いていないコードたちが不要と判定されているっぽい。
これはどうにかできるものなのかな？
とりあえず調査まで。
その他
面白そうな記事。
DOMの数が多くなる
→HTMLのダウンロード、パースに時間がかかる。場合によってはスタイルの再計算が複数回行われる
ということでHTMLのファイルサイズもパフォーマンスに大きな影響を出すとのこと。
スタイルの再計算とかあるのか〜と思ってみてけどLighthouseの結果に書いてたわ。
赤色になっていなくて見てなかった。
Joy UIの時のも見ておけばよかった...！
saneatsu【2024-05-16】TailwindでDarkModeを実現する
結論
ここのまんまやったらきれいにできた。
できること
- デバイスの設定を見て、デフォルトをLight/Darkモードのどちらかにするか自動で決定する
- トグルボタンでモード切り替え
- その後ブラウザをリロードした際に選択したモードが永続化されている
つまづいたところ
上記の記事だとCookieを使っているが最初はLocalStorageにテーマを保存していた。
LocalStorageを使っていることが直接的な原因ではないが、再読み込みしたさいに前に選択したモードが一瞬ちらつく。
例えばデフォルトがLightモードだが、トグルボタンをクリックしてDarkモードにしたとする。
再読み込みした時に一瞬だけLightモードが表示されてからDarkモードになる、というような挙動になってしまっていた。
この記事の「画面更新時のちらつきを防止」のところだけどこれを治すのに手こずった...。
色々調べた結果「結論」のところにリンクを貼った記事を見つけてそれに従ったらきれいに実装できた🙏🏻
その他見た記事
shacn/uiがLucid Reactを使っているので調べた。