先に

• Cocoonの親テーマがバージョン2.7.0だと表示速度が遅くなる件
• Cloudflareの無料プランの場合、Wordpress管理画面にログインした状態のページがキャッシュされることがある件

について書いておきます。

本題に入ります。

WordPressのテーマ『Cocoon』内蔵のWebフォントを使ってる状態 ＆ 一通りの高速化設定・キャッシュ設定をした段階での PageSpeed Insights のスコアは

• 携帯電話(モバイル)は91点
• デスクトップ(パソコン)は100点

で、Webフォントを使わなければ携帯電話のスコアも95点以上にできると思いますが、できれば

• Webフォントは使いたい
• テーマ『Cocoon』のまま

で携帯電話のスコアを95点以上にしたくて悪あがきをした記録がこの記事です笑

以下長文に思われる方もいるかもしれませんが、これでもかなり端折りました。

WordPressサイトを可能な限り高速化します。 の記事にも書いてありますが、PageSpeed Insights のスコアは計測する時間帯・タイミングで30～40点乱高下するので、正直ほんと自己満足の意味しかありません。
特に携帯電話のスコアは激しく乱高下し携帯電話のスコア95点の1分後に再計測して50点になったりすることが日常的な頻度で発生しますので、何度か計測して90点以上取れれば良いかな、程度に考えていたほうが精神衛生上無難です。

SEOにおいてPageSpeed Insightsのスコアは最優先すべきものではありません！

では、備忘録スタートです。

以下、色々試したことの抜粋です。

テーマ変更(※すぐに元に戻しました)

WordPressサイトを可能な限り高速化します。 の記事に書いた、

これ以上のスコアUPは

• テーマ内蔵のフォントをやめる※1
• テーマを変更する※2
• CDN(コンテンツデリバリーネットワーク)を導入する※3
• 超高性能・超高速なサーバーに移行する※4

くらいしか改善策がないです、と思います。。。

の※2　について、無料テーマでも有料テーマでもPageSpeed Insightsのスコアが携帯電話・デスクトップともに100点とれそうなテーマがありましたので、試しにテーマ変更してそれぞれ基本的な高速化の設定をしてみました。

・
・
・
なんですが、今使っているテーマ『Cocoon』は今まで色々な調整・設定をして今に至っているので、上記別の無料テーマ・有料テーマに関して

• 今のCocoonと同様な、高速化MAX ＆ SEOの調整をするのが面倒くさい
• そこまで手間かけるほど今のCocoonのスコアは悪くない

ので、別の無料テーマ・有料テーマに関してはそのうち色々調整して今のCocoonと同じレベルにしたらテーマ変更するかもです。

それまではCocoonのままにします。

■追記■

※2　に関して上記Cocoonとは別の無料テーマでPageSpeed Insightsのスコアが携帯電話・デスクトップともに100点になるよう色々微調整をしたところで気づきましたが、使うのは無料なんですけど『フッターの提供元へのリンク』を消すのに『提供元表示消去プラグイン』なるものが約5,000円と有料らしく

PageSpeed Insightsのスコア

を

にするのに5,000円出す価値があるか、しばらく5年くらい考えてみます笑

と言いますか正直なところ、今のCocoonで、端末の画面の幅・向きでヘッダーの幅・ヘッダー画像・問い合わせボタン等色々変わるようにしているので、Cocoon以外のテーマでそれらを色々設定・調整するのが面倒です。。。

ということで、Cocoonのままで良いかな。
暇ができたら＆気が向いたら、趣味がてら5,000円課金して試してみるかもしれません笑

サーバーをLiteSpeed Webサーバーに変更 ＆ それに伴いキャッシュプラグインも変更(※元サーバーに戻しました)

当ページの作業開始当時のキャッシュ系プラグインのメイン(※3)は W3 Total Cache でしたが、契約している他のサーバーでLiteSpeed Webサーバーがあるのでプラグイン LiteSpeed Cache に変更したら表示速度が改善できるか試してみました。
・
・
・
かなり色々調整してみたものの W3 Total Cache の時より速くならない、というより、WordPressに関してはLiteSpeed WebサーバーよりもNginxなサーバーのほうが速いという結果な気がします。
この時の私の設定が足りてなかった可能性もあります。

※3 今はプラグイン LiteSpeed Cache は使っていません ＆ 有効化してあるキャッシュ系プラグインは1つではなく複数のキャッシュ系プラグインが有効化してありますが、機能がかぶる箇所は(たいていの場合)どれか1つだけ有効にしてあります。

補足しておきますが、LiteSpeed Webサーバーにある別のWordpressサイトではプラグイン LiteSpeed Cache にて携帯電話・デスクトップともに95点以上です。

＆
私が使っているこのLiteSpeed WebサーバーはLaravelに関しては(色々ちゃんと設定すれば)この上なく高速です。
素のLaravelではなく、ちゃんと最適化・高速化・キャッシュ設定してあるLaravelでの話です。

CDN(Cloudflare無料プラン)での設定を細かく調整

Cloudflareを無料プランで使うことにしたわけですが、Cloudflare用のWordpressプラグインの筆頭は Cloudflare だと思いますがこのプラグインだとほとんど設定できないでので、私は Super Page Cache for Cloudflare を使用しています。

Cloudflare無料プランではWordpress管理画面にログインした状態のページがキャッシュされることがありますが、『Super Page Cache for Cloudflare』を使用(※) ＆ Cloudflareの管理画面で適切な設定をすれば、Cloudflare無料プランでもWordpress管理画面にログインした状態のページはキャッシュ除外できます。

※Cloudflareの管理画面で適切な設定さえしてあれば、『Super Page Cache for Cloudflare』や『Cloudflare』などのプラグインは(この件に関しては)関係ないかもです。

以下、Cloudflareの管理画面での私の設定です。

(http.host eq "www.kaimonojyoz.jp" and not starts_with(http.request.uri.path, "/wp-admin") and not starts_with(http.request.uri.path, "/wp-login") and not starts_with(http.request.uri.path, "/wp-json/") and not starts_with(http.request.uri.path, "/wc-api/") and not starts_with(http.request.uri.path, "/edd-api/") and not starts_with(http.request.uri.path, "/mepr/") and not http.request.uri.path contains "/register/" and not http.request.uri.path contains "/dashboard/" and not http.request.uri.path contains "/members-area/" and not http.request.uri.path contains "/wishlist-member/" and not http.request.uri.path contains "phs_downloads-mbr" and not http.request.uri.path contains "/checkout/" and not http.request.uri.path contains ".xsl" and not http.request.uri.path contains ".xml" and not http.request.uri.path contains ".php" and not starts_with(http.request.uri.query, "s=") and not starts_with(http.request.uri.query, "p=") and not http.request.uri.query contains "nocache" and not http.request.uri.query contains "nowprocket" and not http.cookie contains "wordpress_logged_in_" and http.cookie ne "comment_" and not http.cookie contains "woocommerce_" and not http.cookie contains "wordpressuser_" and not http.cookie contains "wordpresspass_" and not http.cookie contains "wordpress_sec_" and not http.cookie contains "yith_wcwl_products" and not http.cookie contains "edd_items_in_cart" and not http.cookie contains "it_exchange_session_" and not http.cookie contains "comment_author" and not http.cookie contains "dshack_level" and not http.cookie contains "auth_" and not http.cookie contains "noaffiliate_" and not http.cookie contains "mp_session" and not http.cookie contains "xf_" and not http.cookie contains "mp_globalcart_" and not http.cookie contains "wp-resetpass-" and not http.cookie contains "upsell_customer" and not http.cookie contains "wlmapi" and not http.cookie contains "wishlist_reg")

以上がCloudflareの管理画面での私の設定ですが、有料プランにすることで

• APO(Automatic Platform Optimization) for WordPress(※5)
• トラフィック → 負荷分散

が使えるようになるので、ある程度のPVがあるサイト・収益に直結しているサイトであればCloudflareの有料プランのほうが簡単に高速化できるかと思います。

※5 Cloudflareの管理画面にてSpeed → 最適化 →コンテンツの最適化にある『Automatic Platform Optimization for WordPress』がそうです。

https://zenn.dev/kameoncloud/articles/106fcc5c7cdc55 の説明では

クラウドフレアのデフォルトではHTMLをキャッシュしませんが、APOを有効化すると、HTMLファイルもキャッシュされます。

とのことですが、上記私の設定の通りであれば無料プランでもhtmlファイルをキャッシュします。

『Automatic Platform Optimization for WordPress』だけであれば月額5ドルでこの機能だけサブスクリプション購入するか、Pro以上の有料プランであれば含まれています。

ですが、どうぜ有料にするなら上記サブスクリプションではなくPro以上の有料プランにしたほうが、

• イメージの最適化(画像に関して色々高速化できる)
• コンテンツの最適化(フォントを高速化＆その他色々高速化)

の機能も使えるるようになりお得な気がします。

私は無料プランのままでいきますけど笑

Webフォントの読み込み改善

Cocoon内蔵のWebフォントは色々ありますが私は 小杉丸 を使っています。
Cocoon内蔵といってもテーマ内にフォントファイルがあるわけではなく単に外部フォントファイルを読みに行く設定があるだけです。

Cocoon内蔵フォントはJavaScriptでdisplay=swapしてるみたいですがこの処理方法だとページを読み込むたびにCLSが発生して少しうざいです。

これを避けるため ＆ できるだけ高速化するために、色々何度も試しました。

テーマ内蔵のWebフォント『小杉丸』は使わずに、
　1.【やり方-1】Googleフォントの『小杉丸』を適切なpreconnect・preload等で読み込む
Googleフォントの『小杉丸』をパソコンにダウンロードした上で
　2.【やり方-2】120ファイルに分割して、使用している文字があるフォントファイルのみ読み込む
　3.【やり方-3】サブセット化・軽量化して子テーマ内に保存
　4.【やり方-4】Web Font Loaderでフォントを遅延読み込み
　5.【やり方-5】Font Loading APIで動的にフォント変更する
の5つの方法を試してみました。

なお、フォント系のプラグイン Custom Fonts や OMGF はWebフォントをサーバー上に保存してpreconnect・preload等で読み込んでいるのでちょっと試してみましたが、後述のやり方-3より遅かったです。

【やり方-1】Googleフォントの『小杉丸』を適切なpreconnect・preload等で読み込む

この場合は

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Kosugi+Maru&display=swap" rel="preload" as="style" />
<link href="https://fonts.googleapis.com/css2?family=Kosugi+Maru&display=swap" rel="stylesheet" media="print" onload="this.media='all'">
<noscript>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Kosugi+Maru&display=swap" />
</noscript>

という感じに記述することで、display=swap;で読み込みます。

これをパソコンにダウンロードして自分のサーバー上にUploadしたフォントのURLにします。

何度も言いますが、テーマ内蔵のWebフォントは使いません。

Webフォント・サーバー上にUploadしたフォントを使う場合でdisplay=swap;の場合は
　　代替フォントで表示
　　↓
　　フォントを読み込み終えたらそのフォントで再度表示
の流れなのでどのやり方でも必ずCLS(Cumulative Layout Shift)が発生しますが、

Cocoon内蔵のWebフォントを使用する場合・・・JavaScriptでフォントの切り替え・書き換えをしてるらしく、ページを読み込む度に必ずけっこうなチラつきが発生して見ずらいです。。。

やり方1・2・3の場合・・・サイトキャッシュがない状態でページを初めて読み込むその1ページのみ若干FOUT(Webフォントによるちらつき)が発生しますが、その後別のページに遷移した場合はキャッシュされたフォントを使うので、Cocoon内蔵のWebフォントを使用した時のようなチラつきは発生しません。

やり方-4の場合もちらつきを防止することが可能なはずですが、やり方-4を試して表示速度がやり方-3より遅かったのですぐに元に戻してしまい、ちらつかなかったのか覚えてないです、すみません。
やり方-4のCSSを見る限りではちらつかないはずです。

なお、
https://fonts.googleapis.com/css2?family=Kosugi+Maru&display=swap
ではなくフォントのCDN
https://www.jsdelivr.com/package/npm/@fontsource/kosugi-maru
も試してみましたがたいして速くないというかGoogleフォントのほうが速い印象でした。

また、フォントの読み込みを100ミリ秒以内になるよう目指した上でどのやり方でもfont-display:optionalも試しましたがフォント適用が不安定になるので、display=swapに落ち着きました。

【やり方-2】120ファイルに分割して、使用している文字があるフォントファイルのみ読み込む

https://fonts.googleapis.com/css2?family=Kosugi+Maru
の中身を見ればわかりますが、これはフォントファイル1ファイルではなく約120ファイルに分割されたフォントURLが書いてあるCSSです。
しかもこの120分割は適当に上から区切って分割したわけではなく、Googleの膨大なデータを元に優先順位で持って分割した120個のフォントファイル一覧です。

/* [2] */
@font-face {  font-family: 'Kosugi Maru'; 
 font-style: normal; 
 font-weight: 400; 
 src: url(https://fonts.gstatic.com/s/kosugimaru/v14/0nksC9PgP_wGh21A2KeqGiTv4ur_mWjfXWdNMtg65zwIiCccFzPAsA.2.woff2) format('woff2'); 
 unicode-range: U+ffd7, U+ffda-ffdc, U+ffe0-ffe2, U+ffe4, U+ffe6, U+ffe8-ffee, U+1f100-1f10c, U+1f110-1f16c, U+1f170-1f1ac, U+1f200-1f202, U+1f210-1f234;}
/* [3] */
@font-face {  font-family: 'Kosugi Maru'; 
 font-style: normal; 
 font-weight: 400; 
 src: url(https://fonts.gstatic.com/s/kosugimaru/v14/0nksC9PgP_wGh21A2KeqGiTv4ur_mWjfXWdNMtg65zwIiCccFzPAsA.3.woff2) format('woff2'); 
 unicode-range: U+fa10, U+fa12-fa6d, U+fb00-fb04, U+fe10-fe19, U+fe30-fe42, U+fe44-fe52, U+fe54-fe66, U+fe68-fe6b, U+ff02, U+ff04, U+ff07, U+ff51, U+ff5b, U+ff5d, U+ff5f-ff60, U+ff66, U+ff69, U+ff87, U+ffa1-ffbe, U+ffc2-ffc7, U+ffca-ffcf, U+ffd2-ffd6;}
・
・
・
これが約120個ぶん続きます。

例えば
https://fonts.gstatic.com/s/kosugimaru/v14/0nksC9PgP_wGh21A2KeqGiTv4ur_mWjfXWdNMtg65zwIiCccFzPAsA.2.woff2
に含まれる文字は、unicode-rangeによって指定された文字のみが
https://fonts.gstatic.com/s/kosugimaru/v14/0nksC9PgP_wGh21A2KeqGiTv4ur_mWjfXWdNMtg65zwIiCccFzPAsA.2.woff2
にありファイルサイズがすごく小さい上、約120個のフォントファイルが毎回必ず読み込まれるのではなく、そのページで使われている文字があるフォントファイルだけが読み込まれるので無駄な読み込みを抑えることが可能です。

ただし、上記CSSを子テーマのheader.phpあるいはstyle.cssに記述したやり方の場合はそのページで使われている文字があるフォントファイルだけを読み込むので確かに無駄な読み込みを抑えてはいますが(デベロッパーツールで確認済み)、preconnect・preloadしたとしてもたぶん余計な処理が入り込むのが原因なのか、決して遅くはないですが(当サイトの場合は)後述の 【やり方-3】のほうが速い印象でした。

【やり方-1】も同様です。

ですので、
src: url(https://fonts.gstatic.com/s/kosugimaru/v14/0nksC9PgP_wGh21A2KeqGiTv4ur_mWjfXWdNMtg65zwIiCccFzPAsA.2.woff2) format('woff2');
の部分を約120フォントファイル全てをダウンロードして子テーマ内等に入れて、上記CSSを当サイトのURLに書き換えた上で子テーマのheader.phpあるいはstyle.cssに記述して試してみたのが【やり方-2】ですが、先ほど書いちゃいましたが【やり方-3】のほうが速い印象でした。

【やり方-3】サブセット化・軽量化して子テーマ内に保存

サブセット化のやり方はググれば見つかりますので難しくないと思います。

サブセットフォントメーカー
WOFFコンバータ

KosugiMaru-Regular.ttfは3,483kbありますが自分でサブセット化したKosugiMaru-Regular-subset.woff2は677kbとなり、元の19.4％のファイルサイズです。

あとはheader.phpに<style>で

• KosugiMaru-Regular-subset.woff2
• KosugiMaru-Regular-subset.woff
• KosugiMaru-Regular-subset.ttf
• KosugiMaru-Regular-subset.eot

を読み込むだけですが、preloadしてもしなくてもあまり変わらない気がします。
※自ドメインなのでpreconnectは不要です。

この時点でページの表示速度は体感的にはかなり速いのですが、PageSpeed Insightsの携帯電話のスコアはたまに90点を超えますが、ちょくちょく50点とかになります。。。

デスクトップはほぼ常に90～100点です。

【やり方-4】Web Font Loaderでフォントを遅延読み込み

Web Font Loader とはGoogleとTypekitが共同開発したフォントの読み込みを制御できるJavaScriptライブラリのことで、Gogoleフォント等のWebフォントを遅延読み込みすることができます。

試してみましたがサーバー上にUploadしたフォントかつサブセット化した【やり方-3】より遅かったです。

小杉丸を例にしたやり方を書いておきますと、最初にテーマのheader.phpで

<html class="kosugi-maru">
<!--●class名はお好みでもOKです。●-->

というように、htmlタグに　kosugi-maru　のclassを追加して、次にstyle.cssに

.kosugi-maru {
  font-family: 'Kosugi Maru'; 
 opacity: 0;
}
.wf-active .kosugi-maru, .wf-inactive .kosugi-maru {
  opacity: 1;
}

を追加して(※1)、最後にfooter.phpの </body>の直前に

<script>
//●Web Font Loaderによる非同期での読み込み
window.WebFontConfig = {
google: {
families: ['Kosugi+Maru']
},
active: function () {
sessionStorage.fonts = true;
}
};

(function () {
var wf = document.createElement('script');
wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})();
</script>

を記述します。

※1 の件ですが、Web Font Loaderはhtmlタグに

• .wf-loading：フォントの読み込み中
• .wf-active：フォントの読み込み完了
• .wf-inactive：フォントが読み込めなかった場合

のclassが付与されるので、

という感じにすることでFOUT(Webフォントによるちらつき)を防止することが可能です・・・となるはずですが、やり方-4を試して表示速度がやり方-3より遅かったのですぐに元に戻してしまい、ちらつかなかったのか覚えてないです、すみません。

上記CSSを見る限りではちらつかないはずです。

ただし先ほども書きましたが、当サイトの場合、PageSpeed Insightsの携帯電話のスコアはやり方-4よりやり方-3のほうが良かったです。
デスクトップのスコアはどちらもほぼ100点なので違いがわかりません、というか、あまり深くチェックしていません。

【やり方-5】Font Loading APIで動的にフォント変更する

Font Loading API(CSS font loading API／CSS フォント読み込み API)は、JavaScriptでフォントの読み込みを制御して動的にフォント書き換えをします。

『IE と Microsoft Edge では動かない』と書いてあるサイトが多いですが、実際はChrome・Edge・Firefox・Opera・Safari・Android・iOSのどれでもちゃんと動くみたいです。
参考： CSS フォント読み込み API の ブラウザーの互換性

実装は簡単でheader.phpの上のほうで

<link rel="preload" as="font/woff2" href="●woff2のフォントのURL●" crossorigin>

と

<script>const font = new FontFace("myFonts", "url(●woff2のフォントのURL●)", 

{
style: 'normal',
weight:'400'
});

// DOMツリーのレンダリングを待たずにフォントをダウンロードする
font.load();

// font.load() はPromiseを返す
font.load().then(function() {
// フォントがロードされたらフォントを適用する
document.fonts.add(font);
document.body.style.fontFamily = "myFonts";
});

// フォントのダウンロード状況を監視
// font.statusは状況に応じて
// "unloaded", "loading", "loaded", "error"
// のうちのどれかを返す
const fontLoadingStatus = font.status

console.log(fontLoadingStatus);
</script>

を記述するだけです。
※細かい記述はググって調整・変更してみてください。

試してみたところ、表示速度は(当サイトの場合は)たぶんやり方-5が1番速い気がしましたが、JavaScriptで動的にフォント上書きしているため、各ページほぼ必ずチラつきが発生するのが個人的にはいただけませんでした。

サイト訪問初回に若干チラつきが発生するのはやり方-1・2・3・4・5のどれも同じです。

やり方-3の場合は、Cloudflareのキャッシュがある限り、サイトに初めて訪問した時だけ(ブラウザキャッシュが一切ないので)その1ページのみCLSが発生しますが、その後は(キャッシュがある限り)どのページを読み込んでも小杉丸のフォントはキャッシュされているのでチラつきません。

やり方-5の場合は(たぶん当サイトの場合のみ)各ページほぼ毎回けっこうな頻度でチラつきが発生します。
※100％ではないみたいですが、発生条件がいまいちわかりません。(同一サーバーの別のWordpressサイトではやり方-5はなぜか初回以外はチラつきません、たぶんですけど。

ということで、当サイトの場合は【やり方-3】です。

■追記■

初期の輻輳ウィンドウを考慮した結果、色々設定を見直し・調整して【やり方-2】に変更しました。

PageSpeed Insightsがモバイルだけ遅い理由(続・当サイトの高速化)

PageSpeed Insightsで何故モバイルだけ遅くなるのか、その理由を説明します。

www.kaimonojyoz.jp

■参考■静的サブセット・動的サブセットについて

フォントのサブセット化といっても色々やり方があり、Webフォントの現状とその仕組み - 動的サブセッティングと静的サブセッティングを読むと違いが理解できまると思います。

ということになります。

静的サブセットのメリット・デメリット

unicode-rangeありの場合は、ページ内の文字数が多くなればなるほどPageSpeed Insightsのスコア(特に携帯電話のスコア)が低下します。
↑
当サイトのトップページ(コンテンツ内約6,000文字)・保守のページ(同約1,500文字)・保守のカテゴリーページ(同約60文字)にてPageSpeed Insightsのスコアの違いを確認しました。

動的サブセットの場合も同様に、文字数に比例したageSpeed Insightsのスコアになるかと思います。

動的サブセットのメリット・デメリット

どのやり方にもメリット・デメリットがあるので、『どこを妥協するか』になります。。。

静的HTML化

残された対応可能な施策もほとんどないので、仕方なく お問い合わせページ 以外をプラグインにて静的HTML化しました。

使ったプラグインは Simply Static ですが若干クセがあり ＆ 一応コード縮小化・難読化も兼ねて、少し手間ですが、当サイトはページ数が少ないので記事追加・更新したら毎回以下の手順をやることにしました。

これもでもまだPageSpeed Insightsの携帯電話のスコアは90点未満のことが多々ありますが、たまに90点超える ＆ 体感的にはこの上なく速いので、この辺で当サイトの高速化についての作業は終了とします。
・
・
・
と思いましたが、もう1つだけありました。

Critical CSS(Critical Path CSS)を再作成

Cocoonの子テーマは今まで長い年月改良してきたためCSSが継ぎ接ぎ(つぎはぎ)になってる可能性もあり、Critical CSSを再作成しました。
今までのCritical CSSとたいして変わりませんでしたが、Media Queryその他いくつかのセレクターが重複して記述してあったり、やはり継ぎ接ぎ(つぎはぎ)になってましたので、Critical CSSの箇所だけですがある程度整理しました。

あとは、子テーマのstyle.css約58,000文字のうち独自デザインのCSSが53,500文字あり、これを除去すればcssに関してかなり縮小できますが、表示速度で足を引っ張ってるのはWebフォントの小杉丸(サブセット化済み)なので、ひとまずCSSには残したままにしました。

●まとめ

これ以上の表示速度改善は

• Webフォントをやめる
• WordPressをヘッドレスCMS化してフロントをNode.jsで作成してフォントをサーバーサイドレンダリングする

以外には思いつかないので作業終了です。

参考までに書いておきますと、Webフォント使用のまま手持ちの他のテーマに変更して色々試したりもしましたが、いまいち微妙でした。

当サイトの現状は

• テーマは Cocoon
• テーマ付属のフォントは使わず、Webフォントをサブセット化して使用 ※色々設定を見直し・調整して、120分割する【やり方-2】に変更しました。
• 使用中のプラグインは41個(停止中は5個)
• CDNはCloudflare無料プランを使用※色々設定してあります
• お問い合わせページ以外静的HTML化

という状況です。

今回当サイトの表示速度改善の作業に着手した最初の段階でのPageSpeed Insightsのスコアは

• 携帯電話(モバイル)は91点
• デスクトップ(パソコン)は100点

で、約1ヶ月近く色々調査・修正・調整した割に、最終的なPageSpeed Insightsのスコアは

• 携帯電話(モバイル)は97点
• デスクトップ(パソコン)は100点

と改善はしましたが、何度も書いてますがPageSpeed Insights のスコアは計測する時間帯・タイミングで30～40点乱高下します。
※上記97点のスコアの1分後に再計測すると62点でした。。。

GTmetrixのスコアです。
無料版なのでPCのスコアです。
↓

体感的には過去20年のWordpress歴で最速なサイトになっていますので、当サイトの表示速度改善に関しては作業終了とします。

Webフォントに関してはCloudflareのPro以上の有料プランにすればフォントもキャッシュして高速化できる可能性があり、若干心が引かれますが当面は無料プランのままでいきます。

まあこんな苦労するくらいなら、Webフォントさえ諦めれば携帯電話・デスクトップのスコアはほぼ常に90点以上になるんですが・・・

静的HTML化って必要？

結論を先に書くと、ほとんどのWordpressサイトは静的HTML化する必要はありません。

静的HTML化してない普通のWordpressサイトでも、Webフォントさえ使わなければ、ちゃんと各種高速化設定されていればPageSpeed Insightsにて携帯電話90点以上・デスクトップ95点以上は可能で、静的HTML化したサイトと比べても表示速度は0.5秒以内の差しかありません。
※当サイトで確認済み

ただし、セキュリティ目的で静的HTML化するケースもあります。

過去にSEOコンサルをお引き受けしたクライアント様のサイトで Shifter をご利用されていたケースがありました。
大手企業様で、Shifterを使うのはセキュリティが目的でした。
Shifterを使えばWordpress管理画面はフロントページのURLとは別になりますので、ハッキングのしようがありません。

上記の例を当サイトが今回静的HTML化するにあたって使用したプラグイン Simply Static で説明しますと、例えば

• 公開URL(サイトURL)：https://www.kaimonojyoz.jp/
• WordPressのログインURL：https://www.kaimonojyoz.jp/huinjidscho.php

とかにして、Simply Staticでちゃんと設定した上デプロイ(静的ファイル等一式を生成)すれば、ソース上にもWordpressのログインURLの痕跡は一切ありませんし、さらに上記ログインURLにBasic認証をかければこの上なくセキュリティが強固です。
・
・
・
とかしなくてもプラグイン Login rebuilder あるいは SiteGuard WP Plugin を使えばWordpressのログインURLは変更可能です。

私は今まで20年近くのWordpress歴の中で一度もハッキングの被害に遭ったことがなく、当然WordPressログインURLは
https://www.kaimonojyoz.jp/wp-admin/
でも
https://www.kaimonojyoz.jp/wp-login.php
でもありません。

https://www.kaimonojyoz.jp/?author=1
も覗けません。

WordPressログインURLの変更はプラグイン『Login rebuilder』あるいは『SiteGuard WP Plugin』でOKなので、結局のところ一般的なWordpressサイトで言えば静的HTML化する必要はないということになります。

CDNの導入は必要？

結論を先に書くと、CDNを導入する必要はありませんがそれなりに効果はあるので、導入できるなら導入しても良い気がします。

CDNを導入しなくても、色々対策すればPageSpeed Insightsにて携帯電話90点以上・デスクトップ95点以上のスコアは可能です。

Cloudflareの無料プランであれば、ちゃんと設定すれば効果はあります。
ただし、プラグインの設定・Cloudflareの設定を間違えるとWordpressにログインしたページがキャッシュされるという、致命的なことになります。

Cloudflare有料プランなら、たぶん適当な設定でも問題なく、かなり効果があります。

あるいは、Cloudflareその他の有料CDNじゃなくても WP Rocket のような優れた有料のキャッシュ系プラグイン・サービスもあります。

普通に考えれば余計なコストはかけたくないので、高速化するにあたって自社・自分で対応できればそれに越したことはないです。

自社・自分で対応するのが難しい場合は、高速化についてお問い合わせ頂きご依頼くださいませ♪
Cloudflareは月額・WP Rocketは年額のコストが掛かり続けますが、当サイトの下記パッケージであれば1回のみのコストです。

Wordpressサイトを可能な限り高速化します。

WordPressサイトの高速化で驚きの成果！PageSpeed Insightsスコア100点達成の実績を活かし、3秒以下の表示速度で顧客離脱率を30%以上削減可能＆収益アップも可能です。無料相談受付中！

www.kaimonojyoz.jp

なお、御社内・ご自身にWordpressの知識があまりない場合は、高速化のご依頼・作業完了後に保守契約もご依頼されることをオススメします。