2014年にブログを、今は亡きSONY系ブログから移籍し、WordPressとして再出発してから７年を経過して、やっと今、全く新しい発想で、ブログ記事の表示方法を改訂できます。ずっと頭の裏で考え続けてきました。 今回の記事は、どのブログシステムでも機能する汎用型の「遅延読み込み(Lazy loading)」についてです。 もっと早くに認識するべきことでした。
JavaScript
筆者のブログは複数の公開サーバー上のブログシステムから記事を配信しており、その記事の中身は完全にミラーリングされています。 つまり「一文字の訂正」は一か所のデーターを編集するだけで、実際に８公開サーバー上のWordPress、２公開サーバー上のMovableType、その他日本のプロバイダー等が提供中の無料ブログで配信している記事で完全に連動します。 さて、記事として各ブログに埋め込まれているのは、JavaScriptファイルの呼び出し構文だけです。 WordPress ・ MovableType ・ プロバイダー提供の無料ブログには、JavaScriptファイルの呼び出し構文のみが保存されている訳です。
記事のミラーリング状態は、下段のDISQUSコメントにあります。あなたへのクイズです
筆者のブログ記事については、今までも画像を記事内に積極的に埋め込んできましたが、そろそろブラウザーのスクロールに追従して、ブラウザーの表示範囲に入った画像のみを順次表示させようと思います。 つまり、人間が行動して初めて通信のリクエストが発生する。 この記事にも従来の通りに複数の画像を埋め込んでいます。 さて、どこに画像がありますでしょうか？ そうです、いつものところです。 プリ・プロセッサーとポスト・プロセッサーが機能する次世代記事では、実験を兼ねて、多くの画像と動画を扱う予定です。 フリッカーにおける筆者のアカウントで管理中の「Ujiki’s favorites | Flickr」
から、最古参から逆ソートして並べるつもりです。 あえてシークレット・ウィンドーで表示が叶うモノだけです。（微笑） 筆者Ujiki.oOのブログにアクセスする数が極端に多いとは言えませんので、ブラックリストに載ってアクセスを拒否されると言うトラブルが起きていないのは事実です。 筆者は外部URLを埋め込む形式で画像をEMBEDしてきました。 筆者Ujiki.oOのブログは分散配信していると言っても、結局は記事内の外部URLを参照する画像のアクセスが短時間に増え過ぎると、外部URL先において、「悪意あるアタック」と認知されてしまっては、以後、２度と外部URLを参照した画像が表示されなくなる可能性があります。 「先手を打つことは良いこと」で、訪問者の手動操作によってブラウザーをスクロールしなければ、外部URLへのアクセスが起きないデーター作りこそは、きっとAIによって「悪意あるアタック」と認知される危険性から逃れるシステムと言えます。 もっと以前に対処するべき事だったと筆者は反省しています！
画像の遅延読み込み
この記事もJavaScriptファイル化し、YUICOMPRESSORで一時圧縮し、gzipで二次圧縮したJavaScriptデーターを配信しています。 みなさんのスマートフォンやタブレットやパソコンのブラウザーが、各ブログ公開サーバーから受信したHTMLデーターを解釈し、ブログ公開サーバーとは無縁な通信によって、DNSラウンドロビン分散機能を経て、圧縮済のJavaScriptデーターを受信します。 みなさんのブラウザーは独立した仕事として記事本文を受信しています。 WordPressなどのブログシステム自身には記事用の文章データーが一文字も存在しません！？ よって、WordPressなどの「遅延読み込み(Lazy loading)」用のプラグインでは、残念ながら全く機能しません！ WikiPedia - Lazy loading
過去記事：「プロキシーサーバーを利用することは馬鹿なことか？！」を読まれたなら、あなたが知らぬ間に地球温暖化に加担していることを認知するかも知れません。 会社ぐるみで、学校ぐるみで、政府ぐるみで、地球温暖化に加担していることを認知するかも知れません。 間接的に市民が知らぬまに地域の停電被害を引き起こしているのかも知れません？！
手順
既に、過去記事の大半が同じルールでJavaScript書式による情報として扱ってきました。 基本的なルールは以下の通りです。 筆者Ujiki.oOのブログは実際に実践し、その解説を行ってきました。 昔からの読者の方なら既知なることでしょう。 新しい訪問者の方の為に、おさらいをしましょう。
- MovableType形式の単独記事用のインポート用ファイルを下書きとして自分のパソコンで作成します。
- STATUS: Draft
BODY: 記事用のJavaScript呼び出しURLを自由に変更します。
EXTENDED BODY: 追記記事用のJavaScript呼び出しURLを自由に変更します。 - STATUS: Draft
- MovableType形式の単独記事用のインポート用ファイルに、ブログ記事として記事本文と追記記事用の２つのJavaScriptファイルのURLを指定します。 例えば本記事の場合なら：
- BODY:
<script type="text/javascript" src="//mydomain.com/2021/getElementsByTagName_T-min.js" charset="UTF-8"></script> - EXTENDED BODY:
<script type="text/javascript" src="//mydomain.com/2021/getElementsByTagName_B-min.js" charset="UTF-8"></script>
- BODY:
- MovableType形式の単独記事用のインポート用ファイルをブログに読み込ませます。
- 記事本文と追記記事用の２つのJavaScriptファイルを自分のパソコンで準備します。
例えば本記事の場合なら：- ・・・\2021\getElementsByTagName_T.js
- ・・・\2021\getElementsByTagName_B.js
Junk2020を、好きなだけ積み木のように構築します。 例： Junk2020 += 'HTML文章'- 情報が少ない場合は無名のローカル関数呼び出し可能ですが、筆者の経験では、文字数の多い追記の場合は、ユニークな名前を冠した関数呼び出しで達成しています。
- 記事本文と追記記事用の２つのJavaScriptファイルを自分のパソコンで必ずYUICOMPRESSORで一時圧縮し、gzip二次圧縮します。
- 最新のJavaをインストールしたWindows10で、拡張子
.jsファイルを右クリックして送るだけで、自動的にYUICOMPRESSOR処理とgzip超圧縮を行っています。 - 最新のJavaをインストールしたWindows10で、拡張子
- DNSラウンドロビン化された静的データー専用サーバーに、WinSCPで暗号化ログインし、暗号化通信によってミラーリング・アップロード処理を行います。
- DNSラウンドロビン化された静的データー専用サーバー領域は、ユニークな
.htaccessの定義によって、盗用とアクセス被害から護られています。 - DNSラウンドロビン化された静的データー専用サーバー領域は、訪問者のブラウザーに対して、30日間のキャッシュ保存を指令しています。
Pre-Processor
従来の通りに作成したJavaScriptソースファイルに対して、新たにプリプロセッサーを埋め込みます。 この記事で以下のプリプロセッサーによって、次の記事で実現させるポストプロセッサーによる二次処理を追加することによって、独自の画像の遅延読み込みが完了します。 この記事では二次処理ポストプロセッサーの為の前処理プリプロセッサーだけを行います。 既に、過去記事の大半が同じルールでJavaScript書式によるブログ記事文章を扱っています。 一次処理プリプロセッサーはきっと標準化されるものですけど、二次処理ポストプロセッサーは様々な種類があっても良いに違いないですよね。 二次処理ポストプロセッサーについては、次に滔々と続く記事を参照願います。
element.innerHTML = Junk2020
- var arr_imgsrc2021 = new Array()
- 空の新しいローカル配列変数を宣言します。
- , element = document.createElement("span")
- 新しいエレメントを生成します。
- , Rep2021 = "//mydomain.com/image%20data/Savior.gif"
- 代替えとして埋め込む縦横３ピクセルの透過型GIFファイルのURLを変数に設定します。
- element.innerHTML = Junk2020
- SPANタグの内側にHTML文章を流し込みます。
- Junk2020 = null
- 指定しない方が高速かも知れませんけど、筆者の気持ちとして、実メモリーを積極的に開放します。
- var Junk2021 = element.getElementsByTagName("img")
- イメージタグを絞り込みます。 みなさんは iFrame タグも追加するかも知れません。 筆者としては今回はIMGタグに絞ります。
- arr_imgsrc2021[ i ] = ""
- 空の配列に空白を定義します。
- ALT要素が未定義の場合は空白で追加します。
- ALT要素のデーターが空白文字の場合は、処理をスキップします。
- 代替え用URLが設定されている場合も、処理をスキップします。
- WIDTH要素が「１」の場合も、処理をスキップします。
- ALT要素がlocation.hash値と同じなら、処理をスキップします。
- arr_imgsrc2021[ i ] = Junk2021[ i ].src
- ローカル配列変数に、退避させます。
- src要素に、縦横３ピクセルの透過GIFファイルを埋め込みます。
- document.write( element.innerHTML )
- 結果を出力します。
- Junk2021 = element = null
- ポストプロセッサーで利用する気がするのです。指定しない方が高速かも知れませんけど、筆者の気持ちとして、この記事ではここで実メモリーを積極的に開放しました。
FACEBOOK(Meta)
FACEBOOK(Meta)には画像をアップロードしていません！ WordPressにも画像は一切アップロードしていません！ FACEBOOK(Meta)の画像を変更する場合は、WordPressのカスタムフィールド内のURL値を変更し、FACEBOOK(Meta)で更新するだけです。 つまりFACEBOOK(Meta)の画像をリプレースするのは簡単です。この項目はFacebook(Meta)が公開している共有機能を、そのまま利用しています。 であるにも関わらず、表示できない有名ブラウザーがあります。 それらブラウザーとは、表示できないのではなくて、表示させない処理を故意に行っている有名ブラウザーがあると言う意味です。 ことはFaceboookに限定しません。 様々なオープンな情報をブラウザーが、あなたに対して見えなくしている事実が問題です。 みなさんが、どのブラウザーを利用することについて、それは自由です！ 著者は決してブラウザーについての選択について推奨はしませんが、このFacebookが表示されない現象を確認できたのなら、他のブラウザーを是非、試用してみてください！ 気になる方は、過去記事「レスポンスを崩さない広告の埋め込みを考えない？」の項目「Facebookの EMBED」に移動してみてください。移動先には、WikiPediaが公開している有名ブラウザーの使用者数の推移グラフもあります。 きっと、あなたはブラウザーが抱える闇を知るでしょうか？！以下が Facebookの </>埋め込み機能を利用したコンテンツです。 あなたを含めて、訪問者がアクションを起こさない限り、 Facebookサーバーとの通信は一切起きません。 この記事に訪問しただけではFacebookサーバーとの通信は一切起きませんので、Facebookサーバーと、あなたの端末のブラウザーまでのネットワーク上の、あらゆる無駄な電力を消費しません！ FACEBOOK(Meta)には画像をアップロードしていません！ WordPressにも画像は一切 アップロードしていません！ FACEBOOK(Meta)の画像を変更する場合は、WordPressのカスタムフィールド内のURL値を変更し、FACEBOOK(Meta)で更新するだけです。 つまりFACEBOOK(Meta)の画像をリプレースするのは簡単です。 記事の改訂の 告知について
DISQUSコメントで 案内します。DISQUSコメントにログインし、DISQUSコメント枠の一番下段の左端のメール・シンボルをクリックすれば、DISQUSコメントがあれば自動的にメールで知らせてくれます。 再度クリックすれば、メール通知を停止できます。 記事末尾のDISQUSコメントの表示が小さくてスレッドのデザインが狭過ぎると思うなら、DISQUSコメント本尊に接続
してみてください。
サポートが必要ですか？
「無料サポート」に興味があれば
上の丸ボタンをクリック願います。
サーバーから9kbを受信しますのでお待ち願います。
※ DISQUSについては別管理ですので、毎回、最新のDISQUSを表示できています。 但し、ご自分のDISQUSコメントを編集した直後に編集後の内容に至らない場合がありますが、DISQUS表示の上部にある「あなたの言語でDISQUSメニューを再表示する！」をクリックしますと最新の状況を表示致します。 宜しくご理解願います。
Google Translator.
良いブログと利用できないブログ
CLICK!
location.hash :
3 Pingbacks