【22年9月版】LP制作者なら絶対に学んでおくべき「LPの表示速度」の基礎が学べるNote
こんにちは、エスイチです。先日、『ランディングページの表示速度』についてこんなツイートをしました。
とある著名なWeb制作会社の方も「顧客にLPを納品してるのに表示速度を気にしないとか二流以下」とおっしゃっていました。
みんな大好きGoogleやAmazonも、ランディングページにとって表示速度はかなりの重要指標だと言ってますね。
私自身、以前これを知らないまま納品して「PageSpeed Insightsの評価が悪いんだけど」という問い合わせが多発。
とっさに改善策を調べて対応しましたため悪評は広まりませんでしたが、かなり時間を取られてデスマーチ化しました。
それ以来、表示速度の知識がないのにLP制作のプロを名乗ることはできないなくらいに思っています。
しかし、表示速度に関する知識は一般的なWeb制作スクールで教えてくれない内容。
そこで、(一応)LPクリエイターと名乗っている私が考える『ランディングページを高速表示させる方法』をまとめました。
細かいことはいいんだよ!とりあえず何すればいいの?
とりあえず、これやっとけば早くなります。
jpg/png画像をwebp画像に変換して圧縮
HTML/CSS/JSファイルを圧縮する
WordPressではなくHTMLで作る
外部CSS/JSはCDNを利用使う
imgタグにloading="lazy"をつける
さらに、ロリポップやエックスサーバー、さくらレンタルサーバー等を活用している方は↓もやりましょう。
.htaccessファイルに↓を追記してgzipを有効化する
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE image/vnd.microsoft.icon
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
Header append Vary Accept-Encoding env=!dont-vary
</IfModule>
検証画像を用意するのが面倒くさいので画像はありませんが、PageSpeed Insightsの評価でいえば8%→98%くらい変化すると思います。
理屈を知りたい人は、読み進めてみてください。
表示速度を上げる基本的な考え方
そもそもなぜ『ランディングページには表示速度が重要なのか?』と疑問に思われる方もいるかもしれません。
LP制作はランディングページを「デザイン・コーディングして納品する」仕事。
そこに「表示速度が◯秒以内でないといけない…」などという契約も義務も発生しません。
しかし、現実問題として作ったランディングページから売上が発生しなければ次はありません。
どれだけ優れたデザインを作っても、表示されないランディングページではデザインの力を100%発揮することもできません。
そして、後述しますが表示速度は広告費の増減にも関係します。(と伝えると案件も増えます)
「LP制作者にとって表示速度は大切なのか?」
冒頭でお伝えした通り、ランディングページを納品する人にとって表示速度の知識は必修科目です。
具体的に言えば、下記のメリットがあります。
「PageSpeed Insights」のスコアをクライアントから指摘される
クライアントに対して「専門家アピール」ができる
高品質なランディングページ制作に繋がる
もちろん「デザイン業務だけ」や「制作会社経由」のような形式で受託している場合は別です。コントロール出来ないので。
「ソースファイルを納品する」「公開まで面倒見る」のであれば、プロとして覚えておくべき基礎知識だと思っておいて良いでしょう。
「表示速度は広告費・売上に影響する」
FacebookやGoogle等の運用型広告を利用している場合、広告品質スコアに影響すると言われています。
この広告品質スコアが下がることで広告費が上がったり表示順位が下がったりというデメリット(要するに広告費💳が高くなる)が発生する原因になります。
「3秒以内に表示させることが最低目標」
ランディングページの表示速度は一般的にリンクをクリックしてから「3秒以内」が目標のひとつになっています。
Googleが発表している指標によると、モバイル端末において3秒以上の読み込みが発生すると53%の訪問者が離脱するとされているそうです。
ページが読まれないまま離脱される=売上に繋がらないのは当然。
特にクリック課金型広告において、ページが読み込まれずに離脱することは大きな損害になります。
「表示速度を上げるためには"データ量を減らす"のが基本」
ランディングページは結局のところデータの塊です。量が多ければ運ぶのは遅くなりますし、距離が離れれば時間がかかります。
つまるところ、「ランディングページのデータ量が小さければ小さいほど」表示速度はアップします。
画像を最適化する
ランディングページの中で最も表示速度の敵となる要素は「画像」です。画像のサイズを小さくすることは表示速度に大きく影響します。
しかも、この画像の最適化はコーダーの方だけでなく、画像を納品するデザイナーにも関わる問題です。
画像の圧縮には大きく分けて「①圧縮形式のファイルを利用する」「②画像サイズを小さくする」の二通りで対応することになります。
圧縮形式の画像ファイルを利用する
ツイート内では「jpg/pngの画像を使わない」と記載した部分です。
この「画像の圧縮」は22年9月現在、Webp形式やSVG形式のファイルを使うのが手っ取り早くカンタンです。
「アイコン等の単純図形ではSVG形式を使う」
メニューやSNSボタン等に使うアイコンはできる限りSVG形式の画像(またはアイコンフォント)を利用しましょう。
SVG形式は主にアイコンのような線と点で描かれる画像(いわゆるベクタ画像)で使われ、テキストファイルで構成されています。
「写真ではWebp形式を使う」
問題になるのは写真のような複雑な画像。こちらはWebp(ウェッピー)形式の画像ファイルを使うと良いでしょう。
Webp形式は「次世代画像フォーマット」とも知られていて、高い圧縮率を誇る画像形式です。
(要するに普通のjpg/png画像よりファイルサイズが小さい)
実際に.jpg→.webpに圧縮してみると…
ご覧いただけた通り、画質はほぼ変わることないまま-67%もサイズダウンしているのが分かります。
「Webp形式の対応ブラウザ問題」
見出しから察せる通り、Webp形式に対応してないブラウザがあったことがWebp形式が主流になっていない理由のひとつでした。
しかし22年現在、この問題は解決しつつあります。
カンタンに言えばIEと旧バージョンのSafari以外はほぼ対応済みです。2~3年間くらいアップデートしていない端末でなければ表示されるでしょう。
「webp形式に変換する方法」
最も手っ取り早いのはGoogleが提供する「Squoosh(スクーシュ)」を利用する方法です。
「webpファイルの使い方」
WebpファイルをHTMLファイル内で使うためには『<picture>タグ』または『<img>タグ』を使用します。
webpファイルの使い方を調べると、jpgやpngファイルを表示させる<img>タグではなく<picture>タグが推奨されている説明が多く見かけられます。
これはwebp形式のファイルに未対応だったブラウザが多かった時代の対策で、未対応ブラウザを考慮しないのであればimgタグでも表示可能です。
<!-- imgタグで使う場合 -->
<img src="sample.webp" alt="imgタグでもWebp画像を使えるよ" />
<!-- pictureタグで使う場合 -->
<picture>
<!-- ①まずは↓を表示できるか試す -->
<source type="image/webp" srcset="Webpが表示できる場合.webp">
<!-- ①が表示できなければを↓表示させる -->
<img src="Webp非対応ブラウザの場合.jpg" alt="画像">
</picture>
<picture>タグは「<source>タグ内にある画像が表示できる場合は上から順に表示させ、どれも表示できない場合は<img>タグを表示させる」という意味。
上記の例の場合、sample.webpが表示できれば表示、対応してないブラウザの場合はsample.jpgを表示させるという流れです。
画像サイズを最適化する
画像の縦横サイズを小さくすることでも画像サイズを減らすことが可能です。
上記を見てもらえれば分かる通り、「画像の大きさ(画像の縦横サイズ)」が小さければデータ量も小さくなります。
この画像の大きさは主に「PC・SPでの読み込み時」に大きな影響があります。
当たり前ですが、PC用の高画質な画像をスマホで読み込んでも意味はありません。
ちなみに現行iPhoneの中で最も大きいiPhone 12 pro maxのビューポートサイズ(横幅)は428pxだそうです。
解像度が高い場合でも1,284pxなため、これ以上の大きい画像を使うと無駄になってしまいます。
「端末ごとに画像サイズを切り替えるには<picture>を使う」
先程ご紹介した<picture>タグは初回表示時点でどの画像を表示すればよいかを判断してくれます。
<picture>
<source media="(min-width: 960px)" srcset="PC用画像.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="タブレット用画像.webp" type="image/webp">
<source srcset="スマホ用画像.webp" type="image/webp">
<img src="Webp対応してない用画像.jpg">
</picture>
上記のように設定した場合、まずPC用画像.webp(大きい画像)が表示できる場合はPC用画像、次にタブレット用、スマホ用と続きます。
上記のように表示させることで、スマホで大きい画像を読み込むことがない=表示速度が早くなる…という仕組みです。
圧縮形式のソースファイルを使う
「HTML/CSS/JSファイルの圧縮」をすることでもページのデータ量を減らすことが可能です。
画像の次に削減できるのはHTML/CSS/JSファイルの無駄を削減することです。
これらのファイルは記述(コーディング)する際、人間が読みやすいように改行やインデント(字下げ)をすることが一般的です。
しかし、改行やインデントもページを読み込む際には無駄になりますから、これらを削除することでページのデータ量を減らすことに繋がります。
もちろん、そもそもの対策として「使っていないCSSやJSファイルを減らす」ことも有効です。
圧縮前のコード(144バイト)
.sample {
position:relative;
width:280px;
height:130px;
background-color:#ccecf4;
border:solid 10px blue;
border-radius: 1em;
}
圧縮後のコード(117バイト)
.sample{width:280px;height:130px;background-color:#ccecf4;border:solid 10px blue;border-radius:1em}
前者は改行やインデントがされていて非常に読みやすいですが、その改行やインデントの分だけファイルサイズが大きくなります。
逆に後者は読みづらさMAXな代わりに、改行やインデント分のファイルサイズが少なくなります。
もちろん上記のような小さなコードでは大した影響はありませんが、コード量が増えれば増えるほど恩恵は大きくなります。
「ソースファイルを圧縮する方法」
オンラインで手軽に圧縮する方法をご紹介します。
素のCSSやJSファイルの場合は下記のような圧縮サイトを使うのが手軽でしょう。
SASSのようなコンパイルが必要な言語を利用している場合、コンパイル時に.minファイルを書き出す設定を入れ込むと良いでしょう。
コンパイラーによって使い方は変わるので、「コンパイラー名 SASS .min」とかで調べてみてください。(「webpack sass min」等)
他にも「ファイル名 圧縮」で検索すると様々な手段が出てきます。
gzipは有効にしておく
「良うわからん…」なままで問題ありません。要するに色んなファイルを圧縮してくれる機能で、主にテキストファイルの圧縮に影響します。
Google PageSpeed Insightsで「圧縮を有効にしてください」と出てくるケースがこのgzip圧縮です。
レンタルサーバー等を利用している場合、サーバー側で変換する機能(mod_deflate)がついている場合があります。
.htaccessファイルに下記をコピペすればgzip圧縮が利用可能です。(mod_deflateモジュールが使える場合)
// .htaccessファイルに下記を追記
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE image/vnd.microsoft.icon
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
Header append Vary Accept-Encoding env=!dont-vary
</IfModule>
他にも書き方はありますので、「gzip htaccess 書き方」でお調べください。
「圧縮されているかどうか確認するためには?」
最も手軽に圧縮されているかどうか確認する方法はHTTP Compression Testです。
URL入れて「test」ボタン押すだけ、圧縮されていれば「https://~is Compressed」と出てきます。
WordPressを使わない
結論から言いますが、ランディングページをWordPressで表示させるのはできる限りやめましょう。
時折「WordPressでランディングページ作成」というワードを見かけます。
しかし、表示速度の一面で見た場合、WordPressとランディングページの相性は悪いです。
仮に「ランディングページをWordPressで作って欲しい」というオーダーがあった場合にもしっかり回答できるよう、基礎知識を身に着けておきましょう。
「なぜWordPressの表示速度が遅いのか」
WordPressの仕組み上、残念ながらWordPressを使うだけで表示速度が遅くなってしまいます。
というのも、WordPressはサーバー側に「HTMLファイルを作って」という命令を出してHTMLファイルを生成して表示させるという仕組みでページを表示します。
WordPressは「リンクを踏んでからHTMLファイルを作って表示させる」
HTMLサイトは「既に作ってあるHTMLファイルを表示させるだけ」
HTMLファイルを作るまでの時間分だけ表示が遅くなるため、最初からHTMLファイルで作ったページよりも表示速度は確実に遅くなります。
「そもそもWordPressでLPを管理する必要がない」
WordPressはコンテンツマネジメントシステム(CMS)です。
そして、CMSはすごくカンタンに言えば同一レイアウトのコンテンツを量産・管理するためのシステムです。
対してランディングページは基本的に「1ページ」で完結するものであり、同一レイアウトを使い回すことがないため、CMSそのものが不要なのです。
「WordPressで作成したほうが良いケースもある」
もちろん、WordPressでランディングページを作ったほうが良いパターンも存在します。
例えば…
HTML/CSSを習得しておらず、ノーコードでLPを作る必要がある
記事LPのように他記事と違和感なく表示させたい
WordPress独特の機能やプラグインを利用したい
このようなケースでは、WordPressでランディングページを作ることも選択肢に入ってきます。
とはいえ、ほとんどのケースで表示速度を落としてまでWordPressでランディングページを作る意味はないと考えて構いません。
基本的にCDNを利用する
冒頭でお伝えした「物理的に距離を縮める」方法が『CDN』です。
CDNとは「コンテンツデリバリーネットワーク」の略で「自分と物理的に近いサーバーから情報を取得する仕組み」です。
使うだけで表示速度が早くなる魔法の手段みたいな感じに覚えておけばOKです。
「CDNの利用方法①:外部CSS/JS」
最も手軽なCDNの利用方法は「外部リソースの使用」でしょう。
例えばランディングページ制作でよく使う「jQuery」を実装したい時に下記のようなタグをHTMLに入れることあると思います。
このような場合、CDNを利用しています。
<script src="https://cdn.jsdelivr.net/npm/jquery@3.2.1/dist/jquery.min.js"></script>
多くの場合、ダウンロードして利用するよりもCDNを使う方が表示速度は早くなります。
実装方法もほとんどの場合タグを挿入するだけで手軽なので、積極的にCDNを利用していきましょう。
「CDNの利用方法②:サイトのCDN化」
公開するランディングページそのものをCDNを利用して配信することでも表示速度をアップさせることが可能です。
この場合、副次効果として「大規模な接続にも耐えやすい」というメリットもあります。
ただし、CDNサービスは利用コストがかかるので注意してください。
「CDNを利用しない方が良いケース」
一見メリットばかりのCDN利用ですが、デメリットもあります。最も頻出するのは「ソースファイルが編集できない」という課題でしょう。
先程の「jQueryの中身そのものをいじりたい」みたいなケースが当てはまります。
例えばCSSフレームワークとして有名な「Uikit」の場合、SCSSやLESSで編集したい時にはダウンロードが必須です。
このように外部ファイルをダウンロードする必要がある場合はCDNを利用できません。諦めましょう。
誤差を受け入れる
表示速度は使用端末・環境・電波強度etc…様々な要因に左右されます。そのため、常に一定ではないことを覚えておきましょう。
3秒以上の読み込みが多発する場合やPageSpeed Insightsの評価があまりにも悪い場合を除いて、体感1秒くらいの誤差は気にしない心を育む方が健全です。
例えばCDN化しても即時全てのサーバーに配置されるわけではないので、むしろ最初は表示速度が遅いこともあります。
多少の誤差は受け入れましょう。そして、受託制作している場合はクライアント側にきちんと説明しましょう。
もっと改善するためには?
「ファーストビューの表示速度を上げる」
ランディングページ(Webページ)の「表示速度」にはいくつかの指標があります。
一般的に言われる表示速度とは「そのページに遷移した際、最初のコンテンツが表示されるまで」であることが多いです。(厳密には異なります)
そのため…
「とにかく早く表示させることが重要なら、とりあえずなんか適当に表示させてから必要な時に読み込めばいいんじゃね?」
という考え方が浸透し始めました。これもひとつの表示速度対策です。
代表的な対策は「画像の遅延読み込み」。ページ表示にはダミー画像を表示させ、画面内に入ったらちゃんとした画像を表示させるという手法です。
22年9月現在、この機能は<img>タグにloading="lazy"を記載すれば使用可能です。
<!-- loading属性を追加することで画面内に入ったらダミー画像から切り替えてくれる -->
<img src="****.webp" width="400" height="300" alt="" loading="lazy">
<picture>タグ利用時も<img>タグ内にloading="lazy"を追加すれば遅延表示されます。(<source>タグには記載しなくてOK)
「ランディングページに到達するまでの導線を最適化する」
はい。こちらは表示速度と関係ありません。
しかし、そもそもランディングページの表示速度をアップさせる目的は「購入率の増加」です。
例えば広告では「1ヶ月で髪がフサフサに!」と謳いながら、アクセスした先のLPが「髪をツヤツヤにします」だったら買う人はいないでしょう。
仮に表示速度が0.000001秒でも、広告内容と一致していなければ購入率は落ちます。むしろ表示速度なんて小さな問題です。
一般的なスクールで教えてくれないWeb制作・LP制作の情報をTwitterで発信しています
最後にちょっとした宣伝をさせてください。
一般的なスクールでは学ぶことができない「Web制作・LP制作の差別化」に特化したスクール『Creators School 4.0』を運営しています。
この度Web向けに一般公開をしましたので、気になる方はTwitterプロフィールからご参加ください😆
この記事が気に入ったらサポートをしてみませんか?