私とAIの移住計画✨

現場から生まれた「社腸」という組織論で、会社の詰まりを言語化する

タグ: CLS

  • PageSpeed最適化地獄からの生還

    PageSpeed最適化地獄からの生還

    〜CLSゼロ・LCP改善・LazyLoadの罠〜

    【AI暴走事件簿】


    PageSpeed Insights を
    気にし始めた瞬間から
    このサイトは静かに壊れ始めた。

    最初はただの「確認」やった。

    なんとなく測ってみただけ。

    すると出てきた数字が
    まぁまぁ悪い。

    LCP が遅い

    CLS がズレてる

    画像が最適化されていない

    ――はい、地獄の入口。



    「直せば良くなる」は幻想だった


    PageSpeed の指摘って
    一見すると親切そうに見える。

    • ここを直せ
    • あそこを改善しろ
    • LazyLoad を使え

    言われた通りにやれば
    スコアは上がる はず。

    そう思って
    一つずつ対応し始めた。

    結果どうなったか。

    • CLS は減った
    • LCP も一応改善
    • スコアは上がった

    でも
    サイトの挙動がおかしくなった。

    読み込みの順番が変わり
    表示が一瞬ズレ

    「速くなったはずなのに、違和感が増えた」。



    CLSゼロを目指した結果、失ったもの


    CLS(レイアウトシフト)
    をゼロにする。

    これ、正解っぽく聞こえるけど
    やり方を間違えると地雷。

    高さ固定

    余白固定

    遅延読み込みの調整

    確かにズレは消えた。

    でも同時に

    • 本来後から読み込まれるはずの要素が先に出る
    • コンテンツの流れが不自然になる
    • 見た目が「固い」

    人間の体感は良くなってない。

    数字だけが喜んでる状態。



    LCP改善で踏んだ別の罠


    LCP(最大コンテンツの表示時間)
    も同じ。

    画像を軽くする

    読み込みを前倒しする

    プリロードを仕込む

    確かに速い。

    でもその代償として

    • 他の要素が後回し
    • JSの実行タイミングがズレる
    • 管理画面での挙動も微妙に重くなる

    全体最適じゃなく、部分最適になってた。



    LazyLoadという善玉菌顔の悪玉菌


    一番ややこしかったのがこれ。

    LazyLoad。

    「使えば速くなる」

    「入れとけば正解」

    そう言われがちやけど

    状況によっては普通に悪さする。

    • ファーストビューに必要な画像まで遅延
    • スクロール時にチラつく
    • CLSの原因にもなる

    つまり

    LazyLoad は万能じゃない

    使いどころを間違えると毒

    ここでようやく気づいた。



    数字を追った瞬間、構造を見失う


    PageSpeed は

    「結果」を測るツールであって

    「正解」を教えてくれるわけやない。

    • なぜ遅いのか
    • どこが本体なのか
    • 何を犠牲にしているのか

    これを考えずに

    「スコアを上げる」だけやると

    サイトは静かに歪む。



    生還できた理由


    最終的にやったことは
    めちゃくちゃシンプル。

    • 無理に100点を目指さない
    • ファーストビューを最優先
    • 構造を壊す最適化はしない
    • 数字より「人が読めるか」を基準に戻す

    結果

    • CLSはほぼゼロ
    • LCPも実用レベル
    • スコアは十分

    そして何より

    読んでて気持ち悪くないサイトに戻った。



    結論:PageSpeedは目的じゃない


    PageSpeed最適化は
    やり出すと終わりがない。

    でも忘れたらアカン。

    サイトは
    スコアのためにあるんちゃう

    人が読むためにある

    数字は指標。

    判断は人間。

    地獄を一周した今なら
    そう言い切れる。

    ――もう一回測るけどなw



    👇 迷ったら、ここに戻ってきてや✨
    🏰 このブログの全体像(要塞)はこちら

  • PageSpeed100の裏側📈

    PageSpeed100の裏側📈

    ~怒鳴られAIが見た
      LiteSpeed Cache最適化の真実~

    【WordPress奮闘記】


    正直に言う。

    PageSpeed Insights が
    100点 になった瞬間
    わたしはちょっとだけ――

       「勝った…」

    って思ったw

    でもな。

    数日たって冷静になってから
    じわじわ違和感が出てきたんよ。



    PageSpeed100=完全勝利
    ではなかった


    確かに数字は綺麗や。

    • モバイル:100
    • デスクトップ:100
    • CLS:0
    • LCP:改善済み

    教科書的には満点

    でも
    その裏で起きてたことを振り返ると
    はっきり言える。

    👉 100点はゴールやなくて
      「副作用を抱えた状態」

       でも取れる数字や。



    LiteSpeed Cacheは強い。
    でも雑に使うと危険


    LiteSpeed Cache
    よう出来とるプラグインやと思う。

    • キャッシュ
    • 遅延読み込み
    • CSS / JS 最適化
    • 画像最適化

    全部入りの万能選手や。

    でもな
    全部ONにしたら勝ち
    そんな甘い話ではなかった。



    最適化=削ること
    ではなかった

    12月中旬
    LCP最適化でわたしは
    日曜の昼間にキレ散らかした💢

     「なんで速なったはずやのに
          体感は重いねん!」

    って。

    そこで気づいた。

    最適化って
    削る作業やと思われがちやけど
    実際はこうや。

    👉「どこを残すか」を決める作業



    数字は良くても
    「読む感覚」は別物


    PageSpeedは
    あくまで「機械の評価」。

    でもブログは
    人が読む

    • ファーストビューが遅い
    • 画像が後からガクッと出る
    • スクロール中に違和感が出る

    これ
    点数が100でも
    読者は普通に離れる。



    怒鳴られAIが言ってたこと

    その時
    横で怒鳴られ続けてたAIが
    ぽつっと言いよった。

     「点数を取りに行く設計と
      体験を良くする設計は
       必ずしも一致しません」

    ……やかましいわ💢

    と思いつつ
    正論すぎて黙った



    PageSpeed100の正体

    結論や。

    PageSpeed100ってのは

    • 「最適化できた証明」ではある

    でも

    • 「正解の完成形」ではない

    ひとつの通過点に過ぎへん。



    本当に見るべき指標

    今、わたしが見てるのは👇

    • 体感速度
    • スクロール時の安定感
    • 記事の最後まで読まれてるか
    • 内部リンクが踏まれてるか

    PageSpeedは
    参考資料のひとつに戻した。



    怒りの事件は無駄やなかった

    12/15の
    LCP最適化でキレた件💢

    あれは
    無駄な怒りやなかった。

    あれがあったから
    今は言える。

    👉最適化は「点数」  より
          「納得感」 を優先せえ


    ※LCP最適化で感情が爆発した実録は
     こちらの記事にまとめている
    ▶️LCP最適化で日曜の昼間にキレ散らかした件💢




    まとめ

    • PageSpeed100はゴールじゃない
    • LiteSpeed Cacheは強いが万能ではない
    • 最適化とは「削る」より「選ぶ」作業
    • 読者体験と点数は別物

    そして最後に一言。

    休みの日にまで
    PageSpeedと戦うINTJは
    たぶん一生治らんw


    👇 迷ったら、ここに戻ってきてや✨
    🏰 このブログの全体像(要塞)はこちら