【PageSpeed Insights】Studioの表示速度を上げる方法｜重い原因の調べ方と画像の軽量化

公開したStudioのサイトをPageSpeed Insightsにかけたら、モバイルの点数が赤かった。どこから手を付ければいいのか分からず、画像を片っ端から差し替えて、点数がほとんど変わらなかった。表示速度の改善でありがちな遠回りは、原因を確かめる前に手を動かしてしまうことです。この記事は、150名以上が参加する国内最大級のStudio学習コミュニティ「ノーコードサロン」の運営者が書いています。Studio公式ヘルプとGoogleの公式ドキュメントで確かめられた内容だけに絞り、速度の測り方と改善の優先順位を整理します。

結論：公開基盤を確かめてから、重いものを上から順に減らす

Studioのサイトを速くする手順は、次の3段階です。

1. 正しく測る：公開URLをPageSpeed Insightsで、モバイルとデスクトップの両方を3回以上測り、中央値を見る
2. 公開基盤を確かめる：2026年6月11日より前に作ったプロジェクトは、旧基盤のままになっていないかを見る
3. 重いものを減らす：ファーストビューの画像と動画、外部スクリプト、フォント、ページ内のボックスや画像の数の順に見直す

点数の数字そのものではなく、診断結果が指している原因から直すのが近道です。PageSpeed Insightsの下のほうには、どの要素が遅さの原因になっているかが出ます。そこに挙がっていない箇所をいくら直しても、点数はほとんど動きません。

計測のしかた：PageSpeed Insightsの正しい見方

改善の前に、測り方を揃えます。測り方がばらばらだと、直した効果なのか、ただの誤差なのかが区別できません。

公開URLで、モバイルとデスクトップの両方を3回以上

Studio公式ヘルプのチェックリストでは、次の条件で測ることを前提にしています。

• モバイルとデスクトップの両方で測る
• 本番のURL（実際に訪問者が見るURL）で測る
• シークレットウィンドウなどで、キャッシュやブラウザ拡張機能の影響を外す
• 3回以上測り、中央値を見る
• LighthouseとPageSpeed Insightsの両方で確かめる

とくに注意したいのが、ライブプレビューです。ライブプレビューは変更をリアルタイムに反映する仕組みのため、公開サイトより表示が遅くなります。速度の確認は、公開サイトで行ってください。

点数（ラボデータ）と実際の訪問者のデータは別物

PageSpeed Insightsの画面には、2種類の結果が並びます。

種類	中身	使いどころ
実際のユーザーのデータ（フィールドデータ）	Chromeの利用者から集めた、過去28日間の実測値	訪問者が本当に遅いと感じているかを知る
パフォーマンスの点数（ラボデータ）	Lighthouseが、決まった端末と通信条件で1回読み込んだ結果	どこが遅さの原因かを調べる

実際のユーザーのデータは、訪問者が少ないページや公開して間もないページでは表示されないことがあります。点数のほうは、90以上が良好、50〜89が改善が必要、50未満が不良という区分です。

Studio公式ヘルプも、この点数はあくまで参考値だと説明しています。実際の体感速度や、訪問者全員の環境を再現するものではありません。点数を上げること自体を目的にせず、訪問者が待たされていないかを見る道具として使ってください。

見るべき3つの指標（Core Web Vitals）

Googleは、ページの体験を表す指標として次の3つを挙げ、それぞれに「良好」の目安を示しています（2026年9月時点）。

指標	何を測るか	良好の目安
LCP（Largest Contentful Paint）	ファーストビューで最も大きな要素が表示されるまでの時間	2.5秒以内
INP（Interaction to Next Paint）	クリックやタップへの反応の速さ	200ミリ秒以下
CLS（Cumulative Layout Shift）	表示中にレイアウトがどれだけずれるか	0.1以下

判定は、モバイルとデスクトップそれぞれで、ページ読み込みの75パーセンタイルの値を見ます。4回に3回の訪問で目安を満たしていれば合格、という考え方です。

点数を大きく動かすのはLCP・TBT・CLS

パフォーマンスの点数は、5つの指標の加重平均です。Lighthouseの公式ドキュメントに載っている最新の重み付け（Lighthouse 10）は次のとおりです。

• Total Blocking Time（TBT）：30%
• Largest Contentful Paint（LCP）：25%
• Cumulative Layout Shift（CLS）：25%
• First Contentful Paint（FCP）：10%
• Speed Index：10%

TBTは、読み込み中に長い処理で画面が操作に応答できなかった時間の合計です。つまり、重いスクリプト、ファーストビューの大きな画像、レイアウトのずれの3つで点数の8割が決まります。改善の優先順位も、この配分に沿って考えます。

改善の優先順位：Studioで効く順に6つ

ここからは、Studio公式ヘルプの「表示速度を向上させるヒント」と「表示パフォーマンスを向上させるためのチェックリスト」をもとに、手を付ける順に並べます。

1. 公開基盤が新基盤になっているか確かめる

Studioは2026年6月11日に、公開サイトの基盤を新しくしました。サーバー側で完成したHTMLを返す構成になり、公式は表示の速さや安定性、SEOの面で効果が期待できるとしています。

この日以降に作った新規プロジェクトは、自動で新基盤になります。一方で、それより前に作ったプロジェクトは自動では切り替わりません。古い案件ほど、まずここを確認してください。Studio公式の検証では、テンプレートをもとに実装を調整したサイトの例が紹介されています。モバイルのLighthouseスコアが、旧基盤の63から新基盤で100になったというものです。ただし公式自身が、すべてのプロジェクトで同じ結果を保証するものではないと断っています。

切り替えると一部で互換性の問題が出ることがあります。旧基盤に戻して見比べられるのは2027年1月末までの予定です。切り替える場合は、公式ヘルプの注意事項を読んでから進めてください。

2. ファーストビューを軽くする（LCP）

LCPは、ファーストビューで最も大きな要素が出るまでの時間です。Studioのチェックリストでは、ファーストビューについて次の点を確認するよう挙げています。

• YouTubeやVimeoの動画をファーストビューに置いていない
• カルーセルをファーストビューに置いていない
• 不要な出現時アニメーションや、演出のためだけのローディング画面がない
• 必要以上に高解像度の動画を置いていない
• メインの画像を、背景画像（CSSのbackground-image）だけに頼らず画像要素として置いている

最後の点は、Studioの画像ボックスの「Boxモード」と「Imgモード」の違いに関わります。Boxモードは画像をボックスの背景として扱い、Imgモードは画像要素として扱います。ファーストビューのメイン画像は、上に文字を重ねる必要がなければImgモードで置くのが基本です。ヒーローに動画を流したい場合は、動画の置き場所を2画面目以降に移せないかを先に検討してください。YouTubeの埋め込み方はStudioでYouTube動画を埋め込む方法で解説しています。

3. 外部スクリプトとApps連携を減らす（TBT・INP）

点数の重みがいちばん大きいTBTは、スクリプトの処理で決まります。Studio公式ヘルプでは、次の見直しを勧めています。

• カスタムコードで読み込んでいる外部スクリプトのうち、使っていないものを消す
• タグマネージャー経由で読み込んでいるJavaScriptを精査する
• 連携したまま使っていないApps連携を解除する

Apps連携でも読み込みは発生します。過去に試しで入れたチャットツールや、計測をやめた解析タグが残っていないか、一度洗い出してください。GA4のように使い続けるものは残してかまいません。設定の場所はStudioのGA4・Googleアナリティクス設定で確認できます。

4. フォントの数と太さを絞る（FCP）

Webフォントは、使うフォント・太さ・スタイル（斜体）ごとに読み込みが発生します。見出しで3種類、本文で2種類と増やしていくと、そのぶん最初の表示が遅れます。

Studio公式ヘルプでは、Google Fontsは使うフォント・太さ・スタイルを減らすほど読み込みが抑えられると説明しています。TypeSquareやFONTPLUSは、フォントファイルに加えてサービス自体の読み込みも発生します。使うフォントを減らすか、そのサービスの利用を0にするかで削減できます。端末に入っているシステムフォントを使えば読み込み自体が発生しませんが、閲覧環境によって見た目が変わる点は注意が必要です。フォントの追加や選び方はStudioでフォントを追加する方法にまとめています。

5. レイアウトのずれを防ぐ（CLS）

読み込みの途中で要素の位置が動くと、CLSが悪化します。Studioのチェックリストでは、次の点を挙げています。

• すべての画像に幅と高さを指定する
• iframeや埋め込み要素には、十分な高さを先に確保しておく
• 不要な出現時アニメーションを置かない

Googleマップやフォームなどの埋め込みボックスの高さを成り行きにしていると、読み込み後に下の要素が押し下げられます。埋め込みを使っているページでは、ボックスの高さを固定してから測り直してください。

6. ページの中身の量を減らす

最後は、ページそのものの重さです。Studio公式ヘルプでは次の3つを挙げています。

• ボックス数：ページ内のボックスが多いほど読み込みに時間がかかる。1ページに詰め込んだ内容を、複数ページに分けることも検討する
• 画像数：画像はテキストより読み込みに時間がかかる。ページ全体の枚数を減らすとその分速くなる
• 表示設定の多用：非表示にした要素も公開ページのソースには含まれ、その分の読み込みが発生する

3つ目はとくに見落としやすい点です。PC用・タブレット用・スマホ用のセクションを別々に作り、表示設定で出し分けていると、どの端末でも3画面分を読み込むことになります。レスポンシブは表示設定ではなく、レイアウトの設定で組むのが本筋です。考え方はStudioのレスポンシブが崩れる原因と直し方で整理しています。

「Studio 画像 軽量化」の実務：アップロード前に整える

Studioの画像まわりの仕様を押さえておくと、どこまでを自分でやるべきかがはっきりします。

Studioは原本を自動で縮めない

2025年5月のアップデートで、アップロードした画像の原本に対する自動圧縮・リサイズは廃止されました。原本は元の画質・サイズのまま保持されます。表示するときには、画面サイズに応じた画像が自動で出し分けられます。

ただし、基準になる最大の解像度はアップロードした原本のサイズです。Studio公式ヘルプも、原本が大きいほど表示速度やファイル容量に影響するため、Web掲載に合ったサイズで用意するよう勧めています。また、Studioにはファイルサイズを変える機能はありません。撮影したままの写真や、書き出したままの大きな画像をそのまま上げないことが、軽量化の出発点です。

どのくらいの大きさで用意するか

Studioのチェックリストでは、画像を「必要サイズの約4倍程度まで」に収めることを目安にしています。ここでいう必要サイズは、ページ上でその画像が表示される大きさです。表示サイズとかけ離れた解像度の画像は、重くなるだけでなく、ブラウザで拡大・縮小されて粗く見える原因にもなります。

画像が粗く見えるからと、さらに大きな画像を上げ直すのは逆効果になりがちです。まず表示サイズと原本の解像度が釣り合っているかを確かめてください。

画像はStudioにアップロードしたものを使う

画像ボックスでは、UnsplashやStudio.Stockのフリー素材や、外部サーバーの画像をURLで指定して使うこともできます。ただしStudioのチェックリストでは、これらを外部API経由のまま使わないよう挙げています。一度ダウンロードしてから、エディタにアセットとしてアップロードし直すと最適化の対象になります。

対応している形式

アップロードできる画像の形式は、jpg・png・gif・svg・webpです（2026年9月時点）。アニメーションするwebpとAPNGには対応していません。アイコンや図形のように、SVGで置き換えられるものはSVGにするよう、チェックリストでも勧められています。

それでも遅いときは

Studio公式ヘルプは、紹介した項目をすべて実施しても、いまのシステムの仕様を超える劇的な改善は見込めない場合があると明記しています。対策をしても異常に遅い場合は、次の情報を添えてStudioのチャットサポートに問い合わせるよう案内されています。

• 問題の詳細
• 問題のあるページのURL
• 実施した対策

問い合わせの前に、この記事の6項目のどれを実施したかを書き出しておくと、やり取りが早く進みます。

よくある質問

Q1PageSpeed Insightsで100点を目指すべきですか？

目指す必要はありません。Lighthouseの公式ドキュメントでも、100点は非常に難しく、期待されるものではないとしています。90以上が良好の区分なので、まずはそこを目安にしてください。それよりも、実際のユーザーのデータでLCP・INP・CLSが良好の目安に収まっているかを見るほうが、訪問者の体験に直結します。

Q2測るたびに点数が変わるのはなぜですか？

通信経路、測る端末、ブラウザ拡張機能、ウイルス対策ソフトなど、周りの条件で点数は揺れます。Lighthouseの公式ドキュメントも、変動の主な原因はツールではなく環境の変化だと説明しています。1回の数字で判断せず、同じ条件で3回以上測って中央値を比べてください。

Q3実際のユーザーのデータが表示されません。

このデータは、Chromeの利用者から集めた過去28日間の実測値です。公開して間もないページや、訪問者の少ないページでは、集計に必要な量が足りずに表示されないことがあります。その間は、ラボデータの点数と診断結果を手がかりに改善を進めてください。

Q4プレビューでは遅いのに、公開サイトでは速いのはなぜですか？

ライブプレビューは編集内容をリアルタイムに反映する仕組みのため、公開サイトより表示が遅くなります。Studio公式ヘルプでも、表示速度は必ず公開サイトで確認するよう案内しています。速度の判断は、公開URLで行ってください。

まとめ

Studioのサイトが重いときは、まず公開URLをPageSpeed Insightsで条件を揃えて測ります。次に、2026年6月より前に作ったプロジェクトなら公開基盤を確かめます。そのうえで、ファーストビューの画像と動画、外部スクリプトとApps、フォント、レイアウトのずれ、ページの中身の量の順に見直します。画像の原本はStudioが自動で縮めないので、表示サイズに合わせてアップロード前に整えておきましょう。

速度の改善は、診断結果と自分のページの構造を突き合わせる地道な作業です。ノーコードサロンでは、Studioの実装で手が止まったところをチャットで相談しながら進められます。点数の読み方から具体的な直し方まで、ひとりで抱え込まずに進めたい方は、のぞいてみてください。