2018年9月29日に都内で開催したCSS Nite LP58「Coder’s High 2018」のフォローアップとして、佐藤 あゆみさん（ism／PentaPROgram）の『フロントエンドでサイトスピードUP！』セッションのスライドなどを公開します。
メッセージ、補足など
たくさんのご意見、ご質問をいただき、本当に参考になりました。ありがとうございます。
フロントエンドの高速化は取り扱う範囲が広く、環境差による例外も多く発生します。
すべてを網羅して説明しようとすると「※ただし?の場合は○○」という注釈だらけになって本文の量以上になってしまいます。
何か違和感を持ったり、うまくいかないことがありましたら、お調べいただくか（図解入りで丁寧に説明された素晴らしいサイトがたくさん存在します）、ご質問をいただければ幸いです。
私は、常に世界は移り変わり、そして人間が改善のための試行錯誤を繰り返す限り、永遠に完成しないものだと捉えています。
そして、ウェブ制作に関するすべてを「完璧」に行う必要はないと考えています。
バリデーターで100点を出せなくても、運用してみて、成果が出ればよし。
結果よければすべてよし、です。その時点でのベストを探ります。
作る側としては完璧な状態というのは気持ちがよいものですが、「ベスト（最良）」と「パーフェクト（完璧）」は異なります。
最終的に人間にみてもらうために制作しているものですから、制作過程で機械的に割り切れなくとも仕方がありません。
高速で表示したい、というのも元をたどればSEOではなく人のため。
サーチエンジンは、人間の後を追って成長しています。
人間を大事にしていれば、サーチエンジンにも評価される（であろう）時代がやっとめぐってきました！
Twitter(@PentaPROgram)
ismでの紹介ページ
セミナー内容への補足
スライド中では直接触れていない内容について補足します。
「消したいけど消せない」への対処はGitで
｢大切にしていたものを失うこと｣は、脳では、体で感じる痛みと同じように処理されている
引用：なぜ僕らはムダなものを買ってしまうのか：部屋も頭も整理するために私が作った4つのルール
という研究もあるそうです。
…さまざまな事情があるかと思いますが、もし周囲の反対にあってコンテンツを消せない場合、こう提案してみてはいかがでしょうか。
「少し外して様子をみてみませんか？ 戻すのは、いつでも戻せますから」
消すのではない、少し外して、様子をみてみるだけ。
これなら失うものは何もありませんので、少し和らぐのではないでしょうか。
※ちなみに個人的には削除後に「戻して」といわれたことはありません。消したら消したで忘れていくようです。
そして、（この件に限らず）もちろんきちんと常にバックアップを取って、必要であれば戻せる状態にしておくことが必要です。
そういった場合に便利なのがGit等のバージョン管理システムです。
いつ、誰が、何をしたのかを、HTMLソースを汚すことなく記録に残していけます。
Gitを使えば、例えば「2017年9月29日の状態のWebサイト（静的コンテンツ）をまるごと復元」することも可能です。
また、「去年やってた○○キャンペーン、今年もやるから今からサイトに載せ直して！」という依頼が来たときも、過去メールログやフォルダを漁る必要はありません。
Gitの履歴（コミットメッセージ）をめぐって「…○○キャンペーンは…あった、これだ、この日に削除したこのソースをコピペしよう！」という風に復活させることも可能です。
便利そうだなと思ったら、ぜひ一度、お試しください。
アンケートでいただいたご質問への回答（サーバー編）
以下のサーバー編の回答にあたりまして、同日に「Webサイト表示速度改善手法」セッションで登壇いただいた阿部 正幸（モチヤ）さんにご協力いただきました。アドバイスいただき誠にありがとうございました。
.htaccessですべてのキャッシュを無効にする
テスト・ステージング段階で、クライアントに「リロードしてくださいね」という手間を省くために.htaccessですべてのキャッシュを無効にしたい場合は、下記のような記述にします。
# キャッシュ設定<IfModule mod_headers.c>Header set Pragma no-cacheHeader set Cache-Control no-cache</IfModule>ただし、以前同じサーバーのファイルにアクセスしたことがある場合、前回の配信時にExpires、Last-Modified や ETag などの指定があった場合は、指定の時間までローカルキャッシュはクリアされません。
また、過去に検証した際に各ブラウザによって動きが異なることがあり、一部ブラウザではキャッシュがクリアされない可能性もあります。
deflateで圧縮してからレスポンスで返す場合、サーバーへの負荷はどの程度？
負荷を測定したことがなく、ご質問への直接的なご返答はできかねます。申し訳ございません。
ただし、gzip圧縮が入っていないサーバーは昨今はほぼないと認識しており、そしてモジュールが入ってるサーバーはデフォルトでonになっていますので、こちらに関しては気にする必要はないと考えます。
.htaccessはフロントエンドエンジニアでも扱えないとまずい？
キャッシュの制御や、リライトルールなど、書けた方がもちろんよいと思います。
アンケートでいただいたご質問への回答（フロント編）
CSS配信の最適化って大変じゃないですか？
- CSSを非同期にした場合の運用・更新が難しそう
- 他ページから流入してくる場合は、そのページのFMPのインラインを出しておくという話でしょうか？（全ページ対応！？）
- 作りにもよると思うが、パーツをincludeの場合もFMPはOKか？
とても多くいただいた質問でした。
無理そうであれば行う必要はない、と前置きした上で、回答させてください。
全ページ同じCSSインライン化しちゃってもよい、と考える
まず、私は
- FMPの範囲は同じサイトであれば異なるページでもおおむね同じCSSが適用されている
- FMPの範囲内のCSSは、運用開始して以降はそう頻繁に変わるものではないと考えています。
トップページは特殊なレイアウトになることが多いですが、ヘッダーのデザインやページの背景色、見出しのスタイル等は、サイト内でパターンとして統一されていることが多いのではないでしょうか。
厳密にやろうとすれば、1ページずつ、それぞれのファーストビュー内のCSSを探っていくのが理想的だと思います。
ですが、そもそも端末ごとに異なるのがファーストビューですし、人力で厳密にすべてに対応しようとするとかなりの労力を使います。
そこで、まず、サイト内で統一されているデザイン部分のCSSをすべてのページ内のheadタグ内に書き込んでしまうことで、大体のページのファーストビューは網羅できます。
除外しなくてもよい、と考える
厳密にやろうとすれば、headタグ内に書き込んであるスタイルは、後から読み込む外部CSSからは消しておくべきですが、それも「被っててもいいんじゃない」とおおらかにそのままで対応してもよいと考えています。
まずテスト環境で試して、実際のレンダリングを比較して、それから取り入れるか考えてもよいと思います。
「いやー、取り入れるほどでもないわ」と思えば、元に戻せばよいのです。
gulp等の自動化ツールを使っているとインライン化したCSSの管理が面倒そう
私はgulpを使用したことがありませんが、gulpにはcriticalというライブラリがあるそうです。
※癖があるのでまったくお勧めはしないのですが、私はJekyllというRuby製のテンプレートエンジンをカスタムしたものをコッソリ好んで使っています。
CSSの非同期部分でnoscriptで読み込んでいる部分は？
JavaScriptが動作しないブラウザでもCSSを読み込めるようにしています。
CSSを複数読み込んでいる場合にインライン化するには？
Critical Path CSS Generatorを使用する場合、読み込んでいるCSSをすべて2の「FULL CSS」の入力欄にぺたぺたコピペすればOKです。
PageSpeed Insightsの判定が99点でしたが、100点にするにはどうすればよかったのでしょうか？
事例で出したサイトが99点だった理由は「外部サーバーのファイルを読み込んでいるから」でした。
解析タグなどの外部サーバーのファイルをページ内に読み込む場合、外部サーバーの設定は変更できないため、外部サーバーの設定内容で検査項目に引っかかると減点されます。
ただ、100点でなくても気にしなくてよいと思います。
PageSpeed Insightsはページが遅い理由を示しているわけではないですよね？
はい、PageSpeed Insightsでは、速度の計測や「こうすると速くなるかも」という提案はしてくれますが、未実行の提案がページが遅い原因になっているとは限りません。
何がボトルネックになっているかは、先の阿部さんのセッションで触れられている調査方法で調べられます。
では、なぜPageSpeed Insightsを出したかといいますと、私自身が、クライアントからPageSpeed Insightsの結果を見せられ「うちって遅いんじゃない？」と相談されたエピソードにあります。
URLを入力するだけで簡単に実行できるツールのため、誰でも分かりやすく「採点」できます。
ウェブ制作について学習する前の段階でも、速度を意識するきっかけのツールとして一つの指標になるものと捉えています。
画像はどこまで圧縮すべき？
- ファッション系のECサイトの場合、画質が重要なので、どこまで圧縮するか悩みます。
- 圧縮NGの場合、バレない圧縮方法はありますか…
悩みどころですね。
効果が目にみるような容量削減を目的とする場合、バレない圧縮方法というのは、申し訳ありませんが、思いつきません。
ツールによって圧縮精度は異なるものの、JPEGもPNGも「非可逆圧縮」することになり、画質が劣化します。
わざわざ圧縮NGと明確に指示されている場合、チェックの目も相当厳しいと思われます。
ただ、例えば買う気満々100%で商品の詳細ページをじっくりみている場合や、アーティストのファン専用サイト等では、たとえ表示に時間がかかったとしても、待ってくれるとは思います。
何がなんでも圧縮しなければということではありません。
もし私だったら、デザイン優先であれば、それはそういった戦略として受け止めてコーディングします。
その代わりに表示が遅くなることはあらかじめ断りを入れます。
縦長ページであればlazyloadで画像を遅延読み込みさせて読み込み速度を意識させないというのが現実的な落としどころになってしまいそうです。
その上で、私はキービジュアルのような大きな画像の場合は200KB前後を目安にしています。
経験上は下記のようなJPEG画像は劣化が目立ちやすいです。
- 彩度が高い、クッキリした印象の画像
- 明朝体など細いフォントで書き込んである
文字入り画像で、特殊なフォントを使用している場合は「背景画像(JPG)＋文字(PNG)」に分離してからそれぞれ圧縮した後にCSSで重ねる対応をしたことがあります。
ビデオ圧縮ノイズを目立たなくさせる話、気になります
背景に動画を使う場合、きつく圧縮すると動画の画質が汚くなってしまいます。
そこで、圧縮してあることを目立たなくさせるために、背景動画に網掛をして目をだまそう！というテクニックのお話でした。
当フォローアップページ下部、「その他」の「鷹野さんのいっていた『動画の市松模様…』」をご参照ください。
商材の関係で動画がトップにあり、遅いのですが、どうにかなりますか？
※サイト名の記載がありましたが、私の判断で伏せました。
実際に拝見しましたが、確かに表示されるまでに間がありました。動画部分で計3MB位でしょうか、特にケータイ回線では瞬時には表示できないでしょう。
一つ上でお応えしているような「高圧縮にして網掛でごまかす」テクニックも使えるとは思います…が、そもそもこんなにたくさんの動画を再生しなくてもよいように思いました。
特にスマホでは、動画が現れる前に、ただの白背景だと思って動画が表示される前にさっと下にスクロールしてしまいそうです。
- 勝負の動画一つに絞って表示する
- もっと短くカットした動画を繋いで一つの動画にする
- 画像に変更し、CSSを使って少し動いているように見せる
個人的には動かさずとも美しく商材が伝わる「勝負画像」1枚でよいなと思ってしまいます。
正確には横長のPC用と縦長のスマホ用の2枚ですね。
その上で、「サンプル動画ギャラリー」のページを設けて、興味がある方にはそちらでじっくりみてもらうという形はいかがでしょうか。
そもそも画像を使用しないという選択肢があるのではないでしょうか？
そうですね。
画像を使用する必要がない、もしくはCSSで表現できる、アイコンフォントを使用するなどの代替手段がある場合は、画像を使用しなくてよいと思います。
asyncとdeferの違いは？
asyncは非同期、deferは延期です。
asyncの場合は、記述した順序に関わらず、読み込みが完了したスクリプトからすぐに実行されます。
deferの場合は、ページの読み込みが完了した後に順次実行されます。
asyncで非同期読み込みをするとブラウザレンタリングがブロックされないという認識でいいでしょうか？
はい、そうです。
どんなJSでも非同期にしてしまってよい？
表示を開始した時点で実行される必要があるスクリプト、また、主にファーストビュー内で直接的にレンダリングに影響するスクリプトは、非同期にしない方がよいです。
解析系のタグは、原則として記述をいじることなく指示された通りに設置しましょう。
FMPはどこで確認できるのでしょうか、ChromeのDevToolsのAudit (Lighthouse)でしたっけ
はい、ChromeのDevTools内のPerformanceやLighthouseにて、どのようにレンダリングされているかを確認できます。
ベストセッション2019
2019年、CSS Niteでは49回の関連イベントを通して123セッションが行われました。その中からベスト・セッション＋αを選びました。
