Developers Summit 2020

Webパフォーマンスガチ勢が本当に使っている技術
Pagespeed Insights 100点を獲得する
高速化技術

プライム・ストラテジー株式会社代表取締役 中村けん牛本日お話すること• 自己紹介• モバイルファースト、5G時代の高速化とは？
• Web高速化の仕組み• バックエンドの高速化• ネットワークの高速化• レンダリングの高速化• 高速化の自動化～PageSpeed Insights 100点満点を獲得するWebパ
フォーマンスガチ勢が本当に使っている技術を解説いたします。
2

資料ダウンロード
本日は原理を中心にお話しますが、項目も多いため、あらかじめ資料をダウンロードいただき、詳細を確認しながら聞いていただけるとより理解を深めていただけると思います。
資料ダウンロードはhttps://www.prime-strategy.co.jp /resource/pdf/DevelopersSummit2020.pdf@kusanagi_saya
https://twitter.com/kusanagi_saya

3

論より証拠4

論より証拠～デモンストレーション
https://event.shoeisha.jp /devsumi/20200213

今から高速化してみます5

論より証拠～デモンストレーション
https://event.shoeisha.jp/devsumi/20200213

6

論より証拠～デモンストレーション

7

高速化デモサイト（1週間ほど公開）
https://event_d_shoeisha_d_jp_s_devsumi_s_202
00213.o20.jp/devsumi/20200213?pst=stg

ID : devsumi
Pass： 2020

Microsoft Azure

8

自己紹介

9

自己紹介
代表書籍およびWEB掲載コラム

プライム・ストラテジー
代表取締役

中村 けん牛『詳解 WordPress』@IT（アットマークアイティ）（出版社：株式会社オライリー・ジャパン）「とにかく速いWordPress」
https://www.atmarkit.co.jp/ait/series/2117/

1971年栃木県生まれ。中学1年生で電波新聞社の『マイコンBASICマガジン』にプログラムを寄稿して以来、プログラミング歴38年。早稲田大学法学部を卒
業後、野村證券に入社。公認会計士第二次試験合格。2002年にプライム・スト
ラテジー株式会社を設立、代表取締役に就任する。執筆監訳書籍に『WordPressの教科書』シリーズ（SBクリエイティブ）、『WordPressによるWebアプリケーション開発』（オライリージャパン）、『詳解 WordPress』（オライリージャパン）など多数。
10

KUSANAGIスタックの開発
高速化ソリューションを開発する高速化ガチ勢
高速・セキュアなサーバOS
KUSANAGI
https://kusanagi.tokyo/

高速化エンジンWEXAL® Page Speed Technology
https://www.wexal.jp/（高速化）戦略AI
ONIMARU® David

11

実績

読売新聞社

株式会社松屋フーズ

メルセデス・ベンツ日本株式会社

株式会社ファミリーマート

株式会社ジャパンタイムズ

青山学院（順不同・敬称略）
12

モバイルファースト、5G時代の高速化とは？

13

Webサイト高速化が求められる背景
速度とコンバージョン、収益に関する見解
ユーザーは短時間で求める情報を得ることを欲している
GoogleGoogle3秒以

モバイルサイトの読み込みに上かかると、

ページの読み込み速度が1秒から5秒に増えると、53％が離脱します。

モバイルサイトの訪問者の直帰率は"Top 12 marketing insights from 2017 to carry you
into 2018"(Think with Google) より引用

グーグル / Find out how you stack up to new industry
benchmarks for mobile page speed より引用

訪問者の90％増えます。

14

Webサイト高速化が求められる背景• Google モバイルファーストインデックス（MFI）
モバイル版のページをインデックスやランキングに使用
https://webmaster-ja.googleblog.com/2018/03/rolling-out-mobile-first-indexing.html• Googleスピードアップデート
ページの読み込み速度をモバイル検索のランキング要素に使用
https://webmaster-ja.googleblog.com/2018/01/using-page-speed-in-mobile-search.html

Google PageSpeed Insights
ユーザーエクスペリエンスの指標のひとつ15

モバイルファースト、5G時代の高速化
5Gの時代＝ネットワークの高速化

ソフトバンクニュース「スマートフォンの通信利用に関する実態調査」より

バックエンドとレンダリングの高速化がより大きな差を生む時代

16高速化の目的と効果
高速化の目的UX（ ユーザーエクスペリエンス）を最大化する→ PVの向上→ CVRの向上→回遊率の向上→滞在時間の向上

また、高速化することで・・・
CPUの負荷が減る→インスタンスサイズの削減
転送量が減る→ネットワーク負荷の低減
地球にも優しい17Webの高速化の仕組み

18

Webの高速化とはネットワーク・バックエンド・レンダリングすべてを高速化

ファースト
ビュー
アプリケーション(WordPress)
PHP
通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS①①HTTPリクエスト

②

③

②動的処理

③HTTPレスポンス④④レンダリング

nginx+PHP+MySQL構成のWordPress19

Webの高速化とは現在のGoogle PageSpeed Insightsのおよその配点
15

15

70
ファースト
ビュー

アプリケーション(WordPress)
PHP
通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS①①HTTPリクエスト

②

③

②動的処理

③HTTPレスポンス④④レンダリング

nginx+PHP+MySQL構成のWordPress
20

バックエンドの高速化
nginx(+lua)+PHP+MySQL構成のWordPressアプリケーションを想定

21

バックエンドの高速化
バックエンド高速化の基本はキャッシュ戦略
キャッシュ戦略の要諦
C1. 一度実行した処理は再利用してCPUを動かさないC2. メモリを効率的に利用してネットワークやストレージにアクセスさせない
C3.そもそも高速な処理系を採用する

22

バックエンドの高速化
キャッシュ戦略の類型
A. 最新のデータによるアウトプットが保証されるもの
B. 過去の情報を再利用するもの
1. 直接アプリケーションの修正を要しないもの
2. 直接アプリケーションの修正を要するもの

23インスタンスとOS• 周波数の高いものを選択• ディスク（ページ）キャッシュを利用

ファースト
ビュー
アプリケーション(WordPress)
PHP

通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)OS

24

インスタンス

A1/C3

CPUのコア数より周波数の高いものを選択する
コア数を増やしてもレスポンス時間は変わらない
1コア
クライアント2コア
サーバ

クライアント

サーバ

開始

終了

レスポンス時間25

インスタンス

A1/C3

CPUのコア数より周波数の高いものを選択する
レスポンス時間を短くするには処理速度（周波数）を上げる
1.6GHzクライアント

3.2GHzサーバ

クライアント

サーバ

開始

終了

26

OS

A1/C2

ディスク（ページ）キャッシュを活用する
ディスクキャッシュ
• バッファキャッシュ ディスクブロックをキャッシュ→ブロックI/Oを最適化• ページキャッシュ ファイルのページをキャッシュ→ファイルI/Oを最適化
HDD

メモリ
使用中のメモリ# free -m
Mem:
Swap:

total
7802
2047

used
5782
451

空きメモリ

free
187
1596

shared379

キャッシュ

buff/cache
1833

スワップ

available
1334

27

nginx• FastCGI Cache• Lua• proxy cache• LuaJIT• Expires• PCREJIT• open file cache
ファースト
ビュー
アプリケーション(WordPress)
PHP

通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS28

nginxB1/C1&C2

FastCGI Cacheを利用する
nginxのFastCGIのレスポンスを直接キャッシュする
Miss
ExpireHit
fastcgi cache

nginx

FastCGI(PHP)

fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=wpcache:30m max_size=512M inactive=600m;
fastcgi_ignore_headers "Vary" "Cache-Control" "Expires";fastcgi_cache_valid 200 10m;

29

nginxB1/C1&C2

proxy cacheを利用する
バックエンドのサーバに処理を渡した結果をキャッシュ
プロキシサーバとバックエンド（upstream）のウェブサーバ
Miss
ExpireHit
proxy cachenginx

1つの設定ファイルにフロントエン
ドのプロキシサーバとバックエンドのウェブサーバの設定を記述
Miss
ExpireHit
proxy cache

nginx
nginx

FastCGI(PHP)/​その他処理

FastCGI(PHP)/ その他処理30

nginxB1/C1&C2

Expiresを設定する
Expires ＝ HTTPクライアントにコンテンツのキャッシュ有効期限を返却するためのHTTPレスポンスヘッダ• ブラウザキャッシュを利用するため高速にコンテンツを表示• 通信を削減• リクエストを削減し、サーバ負荷の軽減• 「PageSpeed Insights」では、静的コンテンツに Expires ヘッダが付けられていることを評価}

location ~* ¥.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {expires 60d;
access_log off;31

nginx

B1/C2

open file cacheを設定する
ファイルを閉じる処理を遅らせ、キャッシュすることで次のアクセス時にファイルを開く処理を省略

イベント待ちclose

特定のファイルにアクセスが集中する場合に有効CSSファイルなど

ヘッダ受信
アクセスログ書き出し
ファイル確認ヘッダとデータ送信
open

open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

データ読み込み

ファイルサイズ確認

32

nginx

A1/C1

Luaによるアプリケーション化
lua-nginx-module → nginxの処理フローにフック
nginxをより高度なサーバアプリケーションフレームワークとして利用
set $expire 'off';
set $access_log 1;
rewrite_by_lua_block {local uri = ngx.var.uri
local regex = [=[¥.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff|woff2|webp|jp2|jxr|map)$]=]
local option = 'jo'
if uri and ngx.re.match( uri, regex, option ) thenngx.var.expire = '60d'
ngx.var.access_log = 0
end}
expires $expire;access_log /home/kusanagi/server/log/nginx/ssl_access.log main if=$access_log;

33

nginx

A1/C1

Luaによるアプリケーション化

初期化フェーズ

init_by_lua
set_by_lua

Rewriteフェーズ

rewrite_by_lua
Accessフェーズ

access_by_lua
content_by_lua
body_filter_by_lua
header_filter_by_lua

Content フェーズ
Logフェーズ

log_by_lua

34

nginx

A1/C1

LuaをLuaJITに変更する
LuaJIT＝ Lua の JITコンパイラ(Just-In-Time)
Luaと比べ、 LuaJITは10倍以上高速
lualuajitVersion

コンパイル時間 (s)実行時間 (s)5.2.3

067.669

2.0.2

0

4.962

この頃 流行りの 言語たち（他）でベンチマーク （Dart, Go, Julia, Nim, Python, Rust 他）

35

nginx

A1/C1

PCRE(LuaJIT) を PCRE JITに変更する
ngx_luaの正規表現
Lua
PCRE
PCRE JIT

string.match
re.matchre.match

パス

pcre_jit

かかった時間(sec)string_match

-

2.18

re_match

off

12.86

re_match

on

12.63

re_match_optimize

off

5.55

re_match_optimize

on

4.48

OpenRestyのre.matchとstring.matchの性能差
https://qiita.com/toritori0318/items/0ecb337acd86e276e38e
36

PHP• PHP5系からPHP7系へ• OPCache の導入• APCuの導入• PCRE JITの利用
ファースト
ビュー
アプリケーション(WordPress)
PHP

通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS

37

PHP

A1/C3

PHP5系からPHP7系へ性能向上やメモリ使用量の削減など大きな改善
2.5倍
160

140
120

100
80

60
40
20

0
PHP5.6

PHP7.0

Requests /second

図1 実行速度ベンチマーク結果の例(Zend/bench.php)
https://column.prime-strategy.co.jp/archives/column_3179
38

PHP

A1/C1

OPCacheの導入
中間コード（オペコード）のキャッシュ
コンパイル後のコードをメモリに保存して再利用
PHPスクリプト

パース

コンパイル

実行

中間コード
キャッシュ

2.5倍

PHPのソースコードに変更が加えられていた場合はキャッシュされた中間コードは破棄→ OPCache の有無でPHPの出力結果は変わらない
39

PHP

B1/C2

APCu（ユーザーキャッシュ）の導入
オブジェクトや変数をメモリに保存して、別のリクエス
トから再利用するキーバリュー型（KVS)のキャッシュ//キャッシュに保存
apcu_store($key, $var, $ttl);//キャッシュから取得$var = apcu_fetch($key);

40

PHP

A1/C1

PCRE(PHP) を PCRE JITに変更する• PCRE Perl互換の正規表現• PCRE JIT 正規表現のJITコンパイラ
正規表現のマッチングのパフォーマンスの向上
preg_match関数で10倍のパフォーマンスも41

MySQL• Query Cache• InnoDB• MyIsam

ファーストビュー
アプリケーション(WordPress)
PHP

通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS

42

MySQLA1/C1&C2

Query Cacheの導入
参照系クエリ（SELECT文）の実行結果をメモリに
キャッシュし再利用• パフォーマンスは数％から1000％以上（クエリが増えるほど効果が大きくなる）• データベースの更新でクエリの結果が影響を受けるときにキャッシュを破棄→クエリキャッシュの有効／無効によってクエリの結果は変わらない【設定の目安】想定されるデータベースサイズの10％[mysqld]
query_cache_size = 64M
43

MySQL (InnoDB)

A1/C2

InnoDB Buffer Poolの設定頻繁にアクセスされるデータとインデックスをメモリーにキャッシュ
innodb_buffer_pool_size
メモリにキャッシュするため、大きいほど有利【設定の目安】想定されるデータベースサイズの120％[mysqld]
innodb_buffer_pool_size = 512M

44

MySQL (MyIsam)

A1/C2

OSのディスク（ページ）キャッシュの利用
MyIsam• テーブルデータのキャッシュ→OSのディスク（ページ）キャッシュを利用# free -m
Mem:
Swap:

total
7802
2047

used
5782
451

free
187
1596

shared379

buff/cache
1833

available
1334

45アプリケーション（WordPress）• 翻訳キャッシュ• SQLクエリの削除、変更• ページキャッシュ• wpdbの拡張/クエリ
キャッシュ• 部分キャッシュ
（Transients API）
• オブジェクトキャッシュ• I/Oに基づく最適化処理

ファースト
ビュー
アプリケーション(WordPress)
PHP

通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)OS46

アプリケーション（WordPress）

B1/C1

翻訳キャッシュの導入
WordPressを日本語で表示する場合、辞書ファイル（ ja.mo）をリアルタイムに読み込むため、処理に時間がかかる。

→翻訳ファイルの読み込みをキャッシュし、高速化させる

47

アプリケーション（WordPress）

B1/C1

ページキャッシュの導入生成したHTMLを一定期間再利用する。
WP Super Cacheなどのプラグインを利用することが多い。

• ページの性質により適切な有効期限を設定• HTMLの再利用という性質上、設定に注意が必要
トラブルの例）• 管理画面は対象外→管理画面が外部で閲覧可能に• ログインユーザごとの機能があるサイト→コメントが反映されない• EC サイト（カート） →他のユーザの購入データが表示
48アプリケーション（WordPress）

B2/C1＆C2

部分キャッシュ（Transients API）の導入
WordPressの処理結果を部分的にデータベースにキャッシュ
ページキャッシュと部分キャッシュ

set_transient( $transient, $value,$expiration );6200倍
ページ全体を
キャッシュ

パーツを
キャッシュ
49

アプリケーション（WordPress）

A1/C1＆C2

オブジェクトキャッシュ（WordPress Object Cache）の導入
取得に時間のかかるデータをメモリ上に保存• データベースのクエリ実行時間の削減• ネットワーク経由のデータ転送時間の削減
wp_cache

200倍

PHPプロセスのメモリ内キャッシュ→セッション内のみ

50

アプリケーション（WordPress）

Ｂ1/C1＆C2

オブジェクトキャッシュ（WordPress Object Cache） の永続化
共有メモリAPCu+機能拡張（ドロップイン・プラグイン
WordPress APCu Object Cache Backend）→セッションをまたいだWordPress Object Cacheの保持30倍51アプリケーション（WordPress）

Ａ1/C3

SQLクエリの削除、変更をする■使われてないSQLを発行しているフックを解除
pre_get_posts,queryにフックして条件を変更→get_postやwp_query、postmeta の取得数の制限→ get_postやwp_query、postmetaの先読みを抑制■クエリの書き換え「WHERE」句や「ORDER BY」句を簡素化しても得られる結果に大きな差が発生しない場合、これらの条件自体を変更してクエリの高速化を図る

52

アプリケーション（WordPress）

Ｂ1/C1＆C2

wpdbの拡張/クエリキャッシュ
WordPress Object Cacheでキャッシュできない参照系（SELECT）のクエリをキャッシュ

データベースのクエリキャッシュのパージ、枯渇時にもキャッシュ保持• 性能向上の時間の延長• ネットワーク経由のデータ転送時間の削減

53アプリケーション（WordPress）

Ｂ2/C3

I/Oに基づく最適化処理（同じI/Oを異なるアルゴリズムで代替）
100s

5s

インプット
抽出条件（パラメータ、引数）

インプット
抽出条件（パラメータ、引数）

アウトプット（O/Rマッパーにより生成された）オブジェクトの配列）

アウトプット（必要なSQLを実行してオブジェクトの配列を生成）

54

その他

Ｂ1/C1＆C2

CDN を利用する
エッジサーバからキャッシュしたコンテンツを配信
・画像、CSS/JSなどのリソース
・HTML
キャッシュの範囲と時間、パージの方法の設計• Cloudfront

CDN
エッジサーバ• Cloudflare

CDN
エッジサーバ• Fastly
CDN
エッジサーバ• Akamai
オリジンサーバ55

キャッシュ戦略のまとめ
A1 → A2 → B1 → B2
A （最新のデータによるアウトプットが保証）
1
修
正
不
要

•
•
•
•
•
•
•
•
•
•
•
•

2
修
正
要

•

B （過去の情報を再利用）

ディスク（ページ）キャッシュの活用 (C2)
PHP5系からPHP7系へ(C3)OPcache( PHP 5.4以降 ) (C1)
Query Cache (C1&C2)
InnoDB Buffer Pool (C2)SQLクエリの削除、変更 (C3)
オブジェクトキャッシュ（単一セッション）(C1&C2)
Luaによるアプリケーション化(C1)
LuaをLuaJITに変更
PCRE(LuaJIT) を PCRE JITに変更(C1)PCRE(PHP) を PCRE JITに変更(C1)CPUのコア数よりCPUの周波数の高いものを選
択 (C3)

•
•
•
•
•
•
•

PHP5系からPHP7系へ(C3)

•

•
•

•

•

fastcgi cache (C1&C2)
proxy cache (C1&C2)
expires (C1&C2)
open file cache (C2)
翻訳キャッシュ (C1)
ページキャッシュ (C1&C2)
オブジェクトキャッシュの永続化(C1&C2)
APCu（インメモリのKVS） (C2)
Wpdbの拡張/クエリキャッシュ
(C1&C2)
CDN (C1&C2)

部分キャッシュ（Transients API）
(C1&C2)
I/Oに基づく最適化処理（同じI/Oを異56なるアルゴリズムで代替） (C3)

ネットワークの高速化

57

HTTP/2
HTTP/2による通信の多重化とサーバプッシュ
listen443 ssl http2;
HTTP/2 Server Push

HTTP/2
クライアントサーバ

クライアントサーバ58

ネットワーク帯域の確保
クライアント側が5Gでもバックエンドが100Mbpsでは4G/3Gと変わりません。

10Mbps↓100Mbps
↓
1Gbps

59

画像リソース
同一画像フォーマットによる最適化■JPEG
ライブラリの変更 libjpeg → mozjpeg• サイズの変更• qualityの変更
cjpeg -quality 60• メタ情報の削除（位置情報など）
jpegtran -copy none
• データの内部保持形式の調整
jpegtran -optimize
cjpeg

非可逆圧縮 ファイルの圧縮、Jpegへの変換など

jpegtran

可逆圧縮 メタ情報の削除、加工など「PageSpeed Insights」で推奨
60

画像リソース• 次世代画像フォーマットによる最適化■PNG• サイズの変更• 色数の変更 pngquant
レット）へ

true colorからindex color（減色パpngquant 256 --speed 1• メタ情報の削除（位置情報など）
optipng –strip all• データの内部保持形式の調整optipng

optipng -o7
pngquant

非可逆圧縮 メディアンカット法による画像の減色

optipng

可逆圧縮

最適化、メタ情報の削除、PNG への変換

61

次世代画像フォーマット
次世代画像フォーマット対応に変換し、ブラウザによりだし
分け
■JPEG
■PNG
JPEG2000/JPEGXR
WebP(libwebp)
WebP

JPEG2000

JPEGXR

IE

×

×

〇

Edge

×

×

〇

Firefox〇××

Chrome〇××

Safari×〇×

User Agent, Acceptヘッダなどで判定、map, lua, try filesなど
で出し分け
62

画像リソース
画像最適化の効果

218KB→15.3KB

63

画像リソース
Lazy load
スクロールに応じて、画像データを遅延読込する• jQuery（JavaScript）• WordPressプラグイン

64

CSS/JS/HTMLのミニファイ・最適化
■CSS

■JS

■HTML

• 利用していないCSSの除外• Chromeのcoverageで調査• UnCSS• 利用していないJSの除外• Minify （ホワイトスペースの削除）• Chromeのcoverageで調査• PageSpeed
Module• Minify （ホワイトスペースの削除）• CSSnano• Minify （ホワイトスペースの削除）• terser/Uglify
JSgzip/brotli（通信の圧縮）65

リソース最適化の手法
1. 直接リソースに変更を加える BETTER
2. 最適化したリソースを別に用意して、直接リソース
BESTの変更を行わない
nginx map、try files、lua
・acceptヘッダ
・cookie・user agent
・urlなどをもとにリソース毎、ユーザーごとに出しわける66レンダリングの高速化

67レンダリングプロセスの分解と再構成
②インタラ
クティブ

①ファーストビューレンダリング
DOMツリー形成

レンダリングツリー形成

DOMContent
Loaded③セカンドビュー
レンダリング表示

Load

インタラクティブになるまでの時間

ファーストビューに必要なリソースのみ最短で実行する。
それ以外をloadイベント以降に遅らせること
で、DOMContentLoadedイベントとloadイ
ベントまでの時間を最短にする。

68

レンダリングプロセスの分解と再構成
②インタラ
クティブ

①ファーストビューレンダリング
DOMツリー形成

レンダリングツリー形成

DOMContent
Loaded③セカンドビュー
レンダリング表示

Load

インタラクティブになるまでの時間

Loadイベントからは、ユーザーが操作できる状態を確保する。
ユーザーの操作が始まるか、数秒間はファーストビューに関係しないJS
やwebfontなどのリソースの実行を遅延させる。

69

レンダリングプロセスの分解と再構成
②インタラ
クティブ

①ファーストビューレンダリング
DOMツリー形成

レンダリングツリー形成

DOMContent
Loaded③セカンドビュー
レンダリング表示

Load

インタラクティブになるまでの時間

最後にセカンドビューの交通整理を行ってユーザー操作や時間の経過とともにリソースの直列、並列での実行処理をおこなう。

70

ネットワーク・レンダリングの渋滞の解消
重いリソースを軽量化、渋滞を解消し、ファースト
ビューとインタラクティブを最短にする

重いリソースを軽量化
配信リソース
の最適化

インタラク
ティブ

レンダリングの渋滞

通信の渋滞

ファーストビューに必要なリソースを最優先に
ファーストビュー
レンダリングインタラク
ティブ

セカンドビュー
レンダリング71

ネットワーク・レンダリングの渋滞の解消
重いリソースを軽量化、渋滞を解消し、ファースト
ビューとインタラクティブを最短にする

重いリソースを軽量化

インタラク
ティブ

レンダリングの渋滞

通信の渋滞

ファーストビューに必要なリソースを最優先に

配信リソースの最適化

ファーストビュー
レンダリングインタラク
ティブ

セカンドビュー
レンダリング

高速道路

優先車両

交通規制

交通整理

72

Developers Summit 2020のサイトを見てみましょう
ソースコードや
デベロッパーツールで実際に確認してみてください73https://event.shoeisha.jp/devsumi/20200213
HTML
ファーストビューに不要なCSSやJS
ロゴとタイトル画像

バナーやJSなど
ファースト
ビューの背景画
像が読み込まれていない！？

74https://event.shoeisha.jp/devsumi/20200213
バナー画像
リソースの大渋滞が起きているフッターのSNS画像
計測やSNSのJS

ココ！！
見出し画像など

75

画像の最適化と遅延読み込み
画像の最適化と次世代フォーマットへの変換↓
遅延読み込み（Lazy load)76JS / Webフォント の遅延と交通整理
SNSやGoogleマップはスクロールしてから表示されればよい↓
セカンドビュー以降に遅延させる↓
SNSのウィジェット
Googleマップ
SNS アイコン（交通整理）

77デモページHTMLファーストビューに必要なCSS

ファーストビューに必要なものを最速で表示

ロゴとタイトル画像

背景画像
見出し画像
ファーストビューに不要なCSSやJS
依存関係や表示順で整理整頓

セカンドビュー
以降は順番を制御

78

79

手法
1. 直接アプリケーションを修正する
2. PHP→アウトプットバッファリング

BETTERBEST

WordPress → hooknginxのluaならどのような処理系でも出力される
HTMLなどをオリジナルのシステムに割り込んで（バッファ制御して）書き換えることができる。

80

高速化の自動化

81ここまで紹介した施策を複数のサイトに個別に、継続的に行うのは困難

バックエンド・・構成済みのインスタンス
CDNの導入画像/リソースの最適化・・自動化
レンダリング・・・？

82

KUSANAGI Premium Edition( KUSNAGI, WEXAL Page Speed Technology, David ）

ファースト
ビュー
アプリケーション(WordPress)

PHP
通信

MySQL

通信

インタラ
クティブ

セカンド
ビュー

レンダリングI/O

Webサーバ（nginx)
OS

キャッシュなしで10～15倍、キャッシュありで1000倍～のパフォーマンスを実現する構成済みサーバOS

稼働しているシステムに一切の改変を加えることなく、リアルタイム・動的に、Webのリソースのすべてを最適化

Webサイトを解析し、ファーストビュー高速化の戦略を立案する
戦略AI

83

KUSANAGI Premium Editionの利用で本日お話したことはすべて実現可能ですが・・・ファイルの圧縮などの自動化→gulp（タスクランナー）
・画像の最適化の自動化→inotifywait でファイル監視などで自動化をすることもできます。

84本日のまとめ• Webサイトの高速化をするには、ネットワー
ク・バックエンド・レンダリングを重層的にチューンング• バックエンドの高速化はキャッシュ戦略。効果と性質で使い分ける• ネットワークの高速化はリソースの最適化・軽量化• レンダリングの高速化はファーストビューの高速化戦略• 高速化は自動化、戦略はAIに85

ご清聴ありがとうございました

86