「サイトが重い」。その一言で焦り、一人で解決しようとしていませんか？
コーディングを外注するデザイナーさんにとって、技術的な問題は大きな不安です。
しかし、重さの原因はサーバーやシステムなど、あなたの責任範囲外にあることがほとんどです。
この記事は、あなたが専属コーダーという専門家と連携するための実践ガイドです。
一人で悩まず、「どこまで確認し、何をどう伝えればいいか」の具体的なステップを学び、デザインの質を落とさずにクライアントの信頼を勝ち取りましょう。
1. 「サイトが重い」と言われたとき、まず焦らない心構え
（１）納品直後の“あの瞬間”
納品したばかりのLPについて、クライアントから「表示がちょっと重いかも」と指摘される。その瞬間、「どこを見ればいいの？」「私の作り方が悪かった？」と頭の中が一気に真っ白になる。
多くのデザイナーさんがここで固まってしまうのですが、それは決して珍しいことではありません。
なぜなら、Webサイトの「重さ」は非常に複雑で、デザイナーさんの努力だけで解決できる問題ではないからです。
↓↓↓まずは深呼吸。焦らないための2ステップ↓↓↓
深呼吸をする: まずは冷静になり、「これは私の責任範囲外かもしれない」と意識的に考える。
コーダーに一報を入れる: 自己判断で修正する前に、「サイトの表示速度についてご相談したいです」と専門家であるコーダーに助けを求めましょう。
（２）焦ると、つい“やらなくていい対処”に走りがち
焦る気持ちのまま動くと、つい極端な行動に走りがちです。
たとえば、「全部の画像を圧縮しなくちゃ！」と本来必要以上に画質の荒い画像にしてしまったり、「動画が重いんだ！」と動画を削除したり外部リンクに切り替えて構成を崩してしまったり。
こうした“勢いの対処”は、デザインの品質を下げるだけで、根本的な改善につながらないケースが多いのです。
なぜなら、画像圧縮ひとつとっても、最適な形式（JPEG、PNG、WebPなど）の判断や、遅延ロード（必要な時まで読み込みを遅らせる技術）といったコーディング側の処理が大きく関わってくるからです。
（３）実は“デザイナーだけの責任”ではないことがほとんど
サイトが重くなる原因は本当にさまざまです。
画像・動画だけでなく、サーバーの応答速度、WordPressのテーマやプラグインの干渉、CDN（コンテンツ配信ネットワーク）の設定、さらにはキャッシュ設定など、デザイナーさんの操作範囲外で起きることがかなり多いのです。
「どこを見ればいいかわからない」のは当然で、むしろ自然な状態なんですよ。
まずは「Google PageSpeed Insights」などのツールでサイトの現状スコアをチェックし、具体的な数値と原因候補を把握するだけで十分です。
その結果をコーダーに共有すれば、スムーズに次のステップに進めます。
（４）受注前にコーダーへ軽く相談するだけで“重さ問題”はほぼ回避できる
サイト公開後に焦るのを避ける一番の方法は、デザイン前の段階でコーダーと懸念点を共有することです。
ワイヤーフレームやデザインカンプの段階で、パフォーマンスに影響しそうな要素について相談するだけで、後からの「重い問題」のほとんどが未然に防げるのです。
例：動画の配置
デザイナー「ヒーローエリアに全画面動画を使いたいのですが、表示速度への影響が心配です。」
コーダー「ヒーローエリアなら、スマートフォンでは自動再生を止めるか、静止画に切り替えましょう。PC版は再生開始を遅らせる対策を入れます。」
例：複雑なアニメーション
デザイナー「このカルーセル（画像のスライドショー）、動きがかなり複雑ですが、実装は可能でしょうか？」
コーダー「複雑な動きはスマホで処理落ちしやすいです。CSSアニメーションに限定して対応すれば、重くなりませんよ。」
（５）相談できる相手がいるだけで、判断の不安はぐっと軽くなる
「これで合っているのかな」と一人で抱え込むより、経験豊富なコーダーに前もって懸念点を聞いておくと、デザイン段階で最適な落としどころが見えます。
結果的に、クライアントにも「コーディング担当者と連携し、パフォーマンスを考慮した上でこの構成に決定しました」と根拠を持って説明できるので、「要望どおりじゃなかったら怒られるかも」という不安も和らぎます。
2. 自分でまず確認できる“軽くするための簡単チェック”
（１）まずは“自分の目”と「検証ツール」で確認するところから
「重い」と言われると、つい設定やプラグインの原因を疑いたくなりますが、最初にするべきことはとてもシンプルです。
まずはブラウザで実際に開いて、体感としてどこでモタつくのかを確認します。画像がゆっくり読み込まれるのか、動画が止まるのか、スクロールで引っかかるのか。
この「ざっくりした体感」だけでも、後でコーダーと話すときの手がかりになります。
↓↓↓デザイナーさんが使えるチェックツール↓↓↓
実は、多くのブラウザにある「開発者ツール（デベロッパーツール）」を使うと、さらに詳しい手がかりを得られます。
画面上で右クリックし、「検証」を選択。
「Network（ネットワーク）」タブを開く。
ページを再読み込みすると、どのファイル（画像、CSS、JavaScriptなど）の読み込みに時間がかかっているかが秒単位で表示されます。
（２）画像サイズは“数字で見る”と冷静になれる
LP制作でいちばんありがちな原因が画像サイズの肥大化です。
とくにデザインカンプから書き出したままのPNGや、高解像度のままのJPEGは、意図せず3MBを超えてしまっていることもあります。
1ファイルあたり500KB〜1MB以下が望ましい。3MB以上のファイルがトップページにある場合、高確率で原因の一つです。
判断基準の目安
ここはデザイナーさん自身でも簡単に確認できる部分なので、「トップのメイン画像だけでも軽くしてみる（例：WebPに変換する、または画質を少し下げる）」といった小さな改善が効果を生むこともあります。
（３）動画があるから“必ず重い”とは限らない
動画を見ると反射的に「重い原因だ！」と思ってしまいがちですが、実は配置条件によって全然違います。
遅延ロード（Lazy Load）が効く、画面外の下の方に配置された動画であれば、実質的な負荷はかなり抑えられます。逆に、画面が表示された瞬間に読み込みが必要なヒーローエリアなどにプリロードありで置くと一気に重くなります。
「動画だから外す」ではなく、「どう読み込まれているか」を軽く見るだけで判断の精度はぐっと上がります。
この「どう読み込まれているか」は、先ほど紹介した開発者ツールの「Network」タブで、動画ファイルの読み込みタイミングを見れば分かります。
（４）PCだけで確認するのは“落とし穴”
多くのデザイナーさんがやってしまうのが、高性能なPCと高速なWi-Fi環境だけで確認して安心してしまうパターンです。
スマホ向けLPでは、読み込みのクセも、表示速度の感じ方もまったく違います。
↓↓↓ネットワーク速度をシミュレーションしよう↓↓↓
開発者ツールの「Network」タブには、ネットワーク速度を意図的に遅くする「スロットリング」機能があります。
設定を「Fast 3G」や「Slow 3G」に切り替えて再読み込みするだけで、低速回線でアクセスした際のサイトの挙動を再現できます。
クライアントが「ちょっと重い」と感じた「低速環境」を自分で再現できると、問題の特定に大きく役立ちます。
（５）WordPress案件は“自分で深追いしない”ほうが安全な場合もある
WordPressで構築しているLPの場合、テーマやプラグイン、サーバー設定など、デザイナーさんが確認しても判断しきれない部分が多くあります。
ここを無理に触ってしまうと、かえって症状が悪化したり、元に戻せなくなったりすることもあります。
「テーマやプラグインが絡んでいそう」と感じたら、保守やサーバー設定にも強いコーダーに相談するのが最善です。あなたの役割は「デザインの意図を正確に伝えること」であり、サーバー管理の専門家になる必要はありません。
（６）相談前に“ここだけ把握しておく”とスムーズ
コーダー視点で最も助かるのは、「この要素はLPの目的的に外せない」という情報を最初に共有してもらえることです。
↓↓↓コーダーへの相談テンプレート↓↓↓
＜トップの動画＞必須かどうか？：必須（クライアント指示）妥協できる点：自動再生を止める、PCのみ表示に切り替えるなどは可
＜複雑なアニメーション＞必須かどうか？：必須ではない妥協できる点：自動再生を止める、PCのみ表示に切り替えるなどは可
↓↓↓具体的な相談メール例↓↓↓
「〇〇さん、お疲れ様です。サイトの速度についてご相談です。PageSpeed Insightsのスコアは〇〇点でした。画像をチェックしましたが、メインビジュアルの画像（3.5MB）が最も重そうです。
ただ、この動画（A）はクライアントの商材の世界観として必須です。もし調整が必要な場合は、この必須の動画（A）以外の要素（アニメーションBなど）を優先的に軽くしていただきたいです。」
“外せるもの”と“外せないもの”が明確になるだけで、技術的な調整の方向性が一気に定まり、改善も早く進みます。
3. WordPress特有の要注意ポイント
（１）“見た目では原因がわからない”からこそ不安になる
WordPressのLPが重いとき、多くのデザイナーさんがまず戸惑うのは「デザインを眺めても原因がまったく見えない」という点です。
画像も圧縮した、動画も工夫した、それでも重い。
そうなると「もしかしてテーマ？ プラグイン？ サーバー？」と消去法で考え始めるものの、どこに注目すればいいのかがわからず不安だけが増えてしまいます。
↓↓↓まずは管理画面の「ざっくり診断」から↓↓↓
「もう手に負えないかも…」と感じてしまうのは自然な反応です。
しかし、まずはWordPressの「設定」や「プラグイン」の画面で、自分がインストールしていない見慣れないプラグインがないか、あるいはPHPやWP本体のバージョンが古くないか（警告が出ていないか）だけでも軽くチェックしてみましょう。
この簡易チェックの結果をコーダーに伝えるだけで、その後の作業が格段に早くなります。
（２）プラグインは“数”ではなく“どこでどう動くか”が大事
よくある勘違いのひとつが、「プラグインは数が少なければ軽い」というシンプルすぎる判断です。
実際には、管理画面だけに影響するもの（例：バックアップ系）もあれば、フロント側で重い処理を実行するものもあります。
特に注意が必要なのは、データベースへのアクセスを頻繁に行うプラグインや、ページ全体にわたる複雑な処理を行う機能です。
【重くなりやすい機能の例】
複雑な多言語化プラグイン (全ページで言語データを読み込むため)
予約システムや会員システム (アクセス時にデータベース処理が走るため)
高度なカスタム検索・フィルタリング機能
つまり、“数”よりも“何がどう動いているか”が重要で、見た目では判断できない部分こそパフォーマンスに影響しやすいのです。
（３）Elementorなどのページビルダーは“理由があって重くなる”
ElementorやBrizyといったページビルダーはとても便利ですが、そのぶん生成されるHTML、CSS、JavaScriptのコード量が増える傾向があります。
LPの自由度は上がる一方で、その裏側では「必要以上のコード」が読み込まれ、結果として表示が遅くなることも少なくありません。
↓↓↓コーダーに依頼すべき調整↓↓↓
これはデザインの良し悪しではなく、仕組み上どうしても起こりがちな性質です。だからこそ、「ページビルダーで作成したから、不要なコードやファイルを最適化してほしい」と、コーダーに依頼することが重要になります。
専門家であれば、ビルダー独自の不要な機能を無効化する対応などが可能です。
（４）多すぎるプラグインは“整理しないと判断できない”
プラグインが大量に入っているWordPress環境では、どれが影響しているかをデザイナーさん側で判断するのは非常に困難です。
それぞれのプラグインが「いつ」「どの場面で」動くのかが把握できないため、軽いのか重いのかを見分けられません。
こうしたケースは、コーダーがデバッグツールやログを確認しながら原因を探っていく必要があります。
デザイナーさんが自己判断でプラグインを停止すると、サイトが壊れるリスクがあります。
「原因はプラグインが絡んでいそうです」とコーダーに伝えるだけで、あなたの役割は終わりです。
（５）環境が古いだけでサイトは驚くほど遅くなる
WordPress本体のバージョン、PHPのバージョン、サーバー環境（メモリやCPU）…。これらが古いままだと、どれだけ画像を軽くしても、どれだけプラグインを整理しても、体感速度は上がりにくいことがあります。
↓↓↓クライアントへの確認フレーズ↓↓↓
しかし、これをデザイナーさんが見分けるのはかなり難しく、クライアント自身も環境を把握していないケースがほとんどです。
そんな時は、以下のような丁寧なフレーズでクライアントに情報提供をお願いしましょう。
「〇〇様、技術的な問題の切り分けのため、サーバー会社と現在のPHPのバージョンをお教えいただけますでしょうか？ 最新版ではない場合、それだけで表示が遅くなっている可能性があるため、コーダーに解析をお願いしたいと考えております。」
「PHP 7.4」や「PHP 8.2」といったバージョン名がわかると、コーダーはすぐに判断できます。
（６）“独自テーマや独自処理”はデザイナーが判断できない領域
テーマが市販のものなのか、過去の制作会社がカスタムしたものなのか、内部でどんな処理が行われているのか。
これらは外から見ただけでは絶対に判断ができない領域です。
独自処理が重さの原因になっている場合もあり、ここは専門的な解析が必要になるため、コーダーに相談するのがもっとも安全で確実です。
4. コーダーに相談するときの“伝え方”と安心できる流れ
（１）“ざっくりした説明で迷惑かも”という不安は本当に多い
「どう伝えたらいいかわからない」「的外れなことを言って怒られたらどうしよう」。
こんな不安を抱えたまま相談をためらってしまうデザイナーさんは、本当にたくさんいます。
特に「重さの原因っぽい気がするけど言葉にできない」という状態だと、相談すること自体が怖くなってしまうのも無理はありません。
しかし、その不安こそが、あなたをコーダーとの協業へと向かわせる原動力になると捉えてください。技術的なことは専門家に任せるのが最速かつ最も安全な方法です。
（２）実は“ざっくりでいい”——むしろそのほうが正確に伝わることも
コーダー側から見ると、デザイナーさんが完璧に原因を特定して伝えてくれることは最初から期待していません。
むしろ、「このあたりでモタついた気がする」「スマホで開いたら最初の3秒が遅い」といった“体感ベースの情報”のほうが、原因追跡のヒントになることが多いのです。
↓↓↓デザイナーが使える「報告フレーズ集」↓↓↓
言語化が難しいままで構いません。感じたことをそのまま伝えましょう。
「最初のローディング（真っ白な画面）が少し長いです。」
「スクロールしたときに、下部の画像がカクカクして表示されました。」
「このページだけ、他のページより体感で1〜2秒遅い気がします。」
「PCでは問題ないですが、電車の中で確認したら表示が遅かったです。」
（３）伝えると助かるのは“事実”と“前提条件”
体感を伝えた上で、相談するときに一緒に共有してもらえると、コーダーが非常に助かるのが次のような「事実」と「前提条件」の情報です。
・どの端末で遅かったのか（例：iPhone 14 Pro / Chrome）
・どの部分が重く感じたのか（例：ヒーローエリアの画像、または全体的な遅延）
・外せない要素（例：動画、特定の装飾、必須の動きなど）
・改善対応が必要な期限（デッドライン）
・クライアントに「パフォーマンス改善が追加費用になる可能性」を伝えてあるか
これらをまとめて伝えることで、技術的な判断をとてもスムーズに進められます。
↓↓↓初回相談の具体例↓↓↓
納品直後の〇〇LP（URL：...）について、クライアントから「表示が重い」と指摘を受けました。お忙しいところ恐縮ですが、速度改善についてご相談させていただけないでしょうか。現状の共有事項は以下の通りです。
【事実】
・遅延を感じた端末：iPhone 14 Pro (iOS 17.5)、Chromeで確認。
・遅延の体感：全体的な読み込みが遅く、特に画面中央部の動画エリアで顕著でした。
・PageSpeed Insightsスコア：モバイル 48点
【前提条件】
・必須要素：トップの動画はクライアントの意向で外せません。
・期限：今週末までに初回フィードバックをクライアントへ返したいです。
・費用の前提：クライアントには、原因によっては追加調査費が発生する可能性があることを伝えてあります。まずは調査をお願いしたく、所要日数と概算費用をいただけますでしょうか。
（４）デザイナーとコーダーの“さりげない会話”でズレをなくす
このコミュニケーションは、一方的な依頼ではなく、一緒に解決策を探すための連携です。
↓↓↓会話シミュレーション（調査フェーズ）↓↓↓
――初動――
デザイナー：「スマホで最初の読み込みが遅い気がするんですが、どこを見ればいいかわからなくて…」
コーダー：「大丈夫ですよ。動画の読み込みか、テーマ側のスクリプトが影響しているかもしれません。遅かった端末と、外せない要素を教えてもらえれば調べますね。」
――情報共有後――
デザイナー：（上記メールを共有）
コーダー：「ありがとうございます。情報が整理されていて助かります。ざっと見たところ、プラグインの影響も無視できません。これはコードのログを見ながら検証が必要な案件ですね。〇日程度で原因と対策の概算を出します。」
この数往復だけで、原因調査の方針はかなり明確になります。
大事なのは“技術的に言い当てること”ではなく、“事実を共有し、専門的な判断を仰ぐこと”なんです。
（５）相談することで判断に根拠が持てて、クライアント対応も安心になる
技術的な部分をひとりで抱え込むと、「合っているのかな」「この対応で大丈夫なのかな」という不安が消えません。
コーダーに早めに相談しておけば、改善の可否や優先度が明確になり、クライアントにも「コーダーと連携し、技術的に最適な解決策を策定しました」と根拠を持って説明できるようになります。
結果として、判断のブレが減り、信頼を落とさずに対応できるようになるのです。これは、あなたがプロフェッショナルなチームの一員として機能している証拠でもあります。
5. まとめ
「サイトが重い」と言われた瞬間のあのざわっとした不安は、だれにでも起こる自然なものです。
でも今回の流れを知っておけば、「まず何をすればいいのか」がはっきりして、焦りがぐっと小さくなります。
まずは、自分で確認できるところから軽くチェックしてみる。画像のサイズ、動画の読み込み、スマホでの体感。ここまでの段階で無理に技術を深追いする必要はありません。
WordPressの場合は、見た目では判断できない要素が多くあります。テーマやプラグイン、サーバー環境、ページビルダー…。
ここはデザイナーさんがひとりで抱え込むべき領域ではなく、経験豊富なコーダーと一緒に見ていくほうが、確実で、安全で、早いのです。
そして、相談するときに専門用語を使える必要もありません。
「どの端末で遅いか」「どこでつまずいたか」「外せない要素は何か」。
この“事実の共有”だけで、十分伝わります。
相談することで判断に根拠が生まれ、クライアントの信頼も守れる。
受注前にワイヤーフレームを共有しておけば、パフォーマンスのボトルネックを未然に防ぐこともできます。
あなたのデザインは、ひとりで戦う必要はありません。
次に「重いかも？」と言われても、もう大丈夫です。
順番に確認して、必要なところはコーダーに預けていけば、必ず解決への道が見えてきます。
あなたのデザインが、もっと安心して届けられますように。
