Bloggerで外部ファイル化している構成要素の「DNS lookup」と「query strings」の問題についての考察

概要

GTmetrix

此処のところ…リッチコンテンツを使用している…

Blogger でも…ページ読み込み速度を維持しつつ…

「Page Speed」や「YSlow」で高スコアを叩き出す

…をコンセプトに…様々なチュートリアルを書いてきました…

重要度の高いであろうものを幾つか置いておきます…

 Blogger用の外部ファイル保存場所として「GitHub」の「GitHub Pages」を活用しよう

 「js」「css」を「GitHub」で外部ファイル化した場合のキャッシュ問題を「RawGit」の「CDN」で解決

 「HTML」の問題点「inline css」「comment out」「未使用の条件分岐」

 外部「css」によるレンダリングブロックを回避するために「js」と非同期読み込みさせるコード


しかしながら…「Blogspot」ドメインでも…ここまで出来るのか

…などという賞賛を浴びる事はありませんし…勿論…

先生から…是非とも公式テンプレートに採用したい

…などと打診があるわけでもありません…　(￣ー￣) 邪笑®

あくまでも…テンプレートのカスタマイズは趣味の一環…

…的なスタンスで…楽しみながらやりましょう…

趣味なのですから…こだわりを持って徹底的に…ってな訳で…今回は…

全くもって地味な…「query strings」と「DNS lookup」の問題に関する考察です…

当然ながら…過去記事で書いてきた…PageSpeed Insights…

…の「Caution」の方が優先順位は上ですから…

PageSpeed Insights

少なくとも…7個程度のルールに合格して…

こんな感じで表示されるようになってからの…

オマケ的な話です…

先ずは… Blogger の画像ポップアップの問題点を手がかりに検証してみましょう…

Blogger の画像ポップアップの問題点

画像を「左」…サイズを「小」…で選択すると…

<div class="separator" style="clear: both; text-align: center;"><a href="オリジナルサイズの画像「URL」" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="サムネイルサイズの画像「URL」" /></a></div>

…ってなかんじの「HTML」が出力されます…画像「URL」はそれぞれ…

　//ドメイン名/画像の固有「ID」/s1600/画像名.画像の拡張子
　//ドメイン名/画像の固有「ID」/s200/画像名.画像の拡張子

…で…ドメイン名は同じで「s1600」「s200」が画像サイズです…

問題は…サムネイル画像のサイズ「s200」ですね…

コレね…例えばオリジナルサイズの画像が「800 x 400」だとすると…

サムネイル画像を「100 x 50」にする場合「s100」に変更する訳ですね…

「height="…"」「width="…"」の記述は任意ですが…

各種…読み込み速度の計測ツールでは…記述を推奨されたりもするので…

「height="50"」「width="100"」を記述して「s200」の部分を変更し忘れると…

「200px」の画像を読み込んだ後に「100px」の画像を読み込んでしまう…

「地味」なリダイレクトが発生してしまうので注意が必要です…　σ(^_^;)

超レアケースはさておき……複数の画像をアップロードすると…

　1.bp.blogspot.com
　2.bp.blogspot.com
　3.bp.blogspot.com……などなど…

複数のドメイン名が割り当てられたりして「DNS lookup」に関わってくるので…

これが…語られることは皆無ですが…本質的な大問題です…

「DNS lookup」に関する考察

画像が多いチュートリアルなどのページでは…

上記のように…ドメイン名は選べませんから…

■YSlow

Reduce DNS lookups
The components are split over more than 4 domains

…などと叱られる事になります…どういう事かというと…

4個を超えるドメイン名があるので「DNS lookup」的にダメだよ

…ってな感じです…しかしながら一方で…

「css」「js」はスプリットして外部ファイル化しないと高スコアは望めません…

つまり…実質的には…「2」「3」「4」個の範囲に収めなさい

…と言っているのと同義なのです…全くもって理不尽な言い分なのですが…

Blogger が対処するとは到底思えませんね……私の場合は…

• Blogger の「blogspot」
• 「Webフォント」のアイコン用の「Font Awesome」
• 「css」「js」をホストしている「GitHub」用の「RawGit」の「CDN」

…で…リダイレクトが発生する「.com」アドレスだと…4個ですし…

「.jp」アドレスでアクセスしたとしても…3個のドメイン名はマストです…

なので…削除してはいますが　<b:include name='quickedit'/>　で呼び出される…

ガジェット編集用のレンチアイコン「」に代表される…

テンプレート内は勿論ですが…外部ファイル化した「css」も…

イメージ画像は全て「base64」変換か「CSS Sprites」で記述しています…

因みに…「CSS Sprites」の画像も…勿論…「base64」変換です…

つまり…徹底的に「HTTP リクエスト」を排除する必要がある訳です…

記事ページはどうする…ってな疑問もあるでしょう…

上記「Blogger の画像ポップアップの問題点」での…

サムネイル画像は…全てページレンダリング時に読み込まれる訳ですから…

それぞれで「HTTP リクエスト」が発生し…レンダリングをブロックします…

なので…当然ながら…全て…「base64」変換すべきです

特に…チュートリアルでのサムネイル画像は判読出来なくても無問題です…

記事を書き終えてから「base64」の生データに書き換えれば…

記事作成の邪魔にもならない事でしょう…

「query strings」に関する考察

コレね…重要度は高いんですが…結論は出ていません…

■Page Speed

Remove query strings from static resources
Resources with a "?" in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL for the following resources:

所謂…「URL」に「?」が入っているとキャッシュが使えない場合があるよ

…ってヤツです…サードパーティ製のスクリプトでよく見かける…

　…feeds/posts/default?…
　…feeds/posts/summary?…　などなど…に続くパラメータ…

…が…典型例です…私が…「Related Posts」「Recent Posts」を…

微塵の躊躇いも無く…削除してしまった事由でもあります…

しかしながら…リッチコンテンツ好きですから…

リッチコンテンツを維持するためのアイテムには…目をつぶっています…

「Font Awesome」の「css」の「……woff?v=4.1.0」です…

「概要」に置いてある前記事の非同期読み込みさせるコードの不具合なのか

一般的な「URL」の記述…つまり…

「Font Awesome」
　//maxcdn.bootstrapcdn.com/……
「RawGit」
　//cdn.rawgit.com/……

…と…「」や「https:」を記述していませんが…

「RawGit」で吐き出される「URL」は「https:」を付与されていますので…

　https://cdn.rawgit.com/……　と記述すると…

何故か…「Font Awesome」の「?」に対する「Caution」が解決されます…

意味が解らん……ただし…読み込み速度は低下しますので…

保留 …ってな感じで…一般的な「URL」の記述を継続しています…

「GitHub」にホストして「RawGit」で呼び出す事も出来ますが…

「MaxCDN」の方が速いので…むにゃむにゃむにゃむにゃ…

まぁ…浅い知識でやっていますから…たぶん…解決しません…（￣＾￣) ｴｯﾍﾝ

おわりに…

「 WordPress」や「独自ドメイン」に目が眩み…

迷走を続けるサイト管理者の…なんと多い事か…

コラム系ならいざ知らず…モッサリなサイトというだけで…

チュートリアルの整合性すら怪しくなりますね…

そもそも…サイト高速化の記事自体が…ほぼ…いい加減な記事だらけですね…

速度測定サイトが…○○○と言っていますから改善すれば速くなります…的な…

アホウかと疑いたくなる記事とも呼べない代物ばかりです…

「 WordPress」では…更に意味不明で…

プラグインで重たくなったサイトを高速化するプラグイン…的な…

魔法か魔法なのか …と叫びたくなりますね…　(￣- ￣) 冷笑®

具体的な解決策が皆無だったり…根本的な解決じゃなかったり…

そのくせ…上位に表示されようと血眼になっているのが透けて見えますね…

先生に高速化について尋ねると「 WordPress」ばかりゾロゾロと…

裏を返せば…「 WordPress」は遅いと言っているようなものです…

安直な近道など存在しませんよ……せめて…

数少ない購読者の方々は…惑わされませんように…

以上です…最後までお読みいただきましてありがとうございます…

Tips Header Sidebar Main Footer Current-Label : Universal