{開発}{開発記録}{希哲13年}{出振るい}{SySS}{付徴}{握接}{理腑}{デライト高速化}{希哲15年4月8日の日記}(104)

{希哲15年4月8日の開発 K#F85E/E74C-86B0}

3日の開発から6日間に渡って続いたデライト小理腑をいったん終えた。

結果的には主に装体書整理テンプレート整理だったが,これにより,保守性体感表示速度大幅向上が見られた。


装体書テンプレートは, によるデルン初期実装から長いこと継ぎ足しで使ってきたため,古い記述譜類に埋もれて目的のものが探しにくいといった問題慢性的にあった。分割すべき記述が一つの譜類に詰め込まれている,逆に,一つにまとめておくべき記述が複数の離れた譜類に分散している,といったことがよくあった。今回の小理腑ではこの点が大きく改善した。

テンプレートの方は折に触れて整理してきたからまだマシだったが,装体書の方は適当に分割した譜類に大量の記述が詰め込まれている状態だった。そもそも SySS備立すら適当で,.syss 譜類があっても .scss が無いと換配されないなど,多数の譜類を管理出来る状態では無かった。これを機に備立方法から整備した。

装体書整理は当初,HTML の肥大化を恐れて埋め込み装体書見極めに時間をかけ過ぎてしまっていたが,この日,JavaScript や HTML に gzip 圧縮がかかっていなかったことに気付いた。ちょっとした deln.conf間違いだったが,これをきっかけ吹っ切れ作業捗るようになった。結局,転送量を大幅に削減出来た分,多少の冗長性には目を瞑ることにした。

これら作業の結果として,目的の装体テンプレートにすぐ握接出来るようになり,埋め込み装体書調整等も的確に行えるようになった。


表示速度は,ページにもよるが,DOMContentLoaded までの計測値0.5秒近く短縮した。これに装体適用合理化も加わり,体感表示速度ははっきり向上したのが分かる。溶明動き付けをいったん削除したのも大きいかもしれない。デライト初期実装読み込み中途半端遅さ誤魔化すため0.3秒の溶明を入れていた。

現時点でここまで高速化に繋がったことは思わぬ収穫だった。これまで,「デライト高速化」は後縁最適化中心に考えてきた。後縁最適化余地の大きさと負荷軽減重視していたこともあり,前縁最適化期待重視もしていなかった。

希哲13年前縁改革前縁の重要性は分かっていたつもりだったが,まだ認識が甘かったようだ。これに気付いたことも大きな収穫と言えるだろう。


そもそもスクリプト動的読み込みに使っている @icl() とその周辺整理によって生じた描画乱れ解消のために始めた作業で,あまり多くは期待していなかったが,結果的に大収穫となった。

ただし,10日までに盛り込むつもりだった付徴後回しになり,デライト収益目標達成にどう影響するかは不透明だ。

問題が解消するまで出振るい出来ず,他の作業が出来なくなっていたこともあり,作業項目としてのデライト小理腑はここでいったん完了とすることにした。整理が必要な部分はまだまだ残っているが,ほとんどは漸進的作業出来る部分だ。いま出来る範囲でまとまった時間を使ってやる理腑はこれが限度だろう。

{進捗記録}{進捗}{<body>}{<script>}{Aejs}{defer 属性}{希哲15年4月1日の開発}{描画速度}{二度手間}{link rel="preload"}(53)

{希哲15年4月1日17歩 K#F85E/E74C-FE68}

Aejs@icl() とその周辺見直し

いったん終了。

デルン初期実装からか,@icl() では Document.write() 相当の @doc.wr() を使って script 要素を書き出していたが,これは様々な面で好ましくない。こんな実装にした経緯失念したが,装体書で同じようなことをする @apd_ss()@elm.bld..apd()Node.appendChild())を使っているところをみるに,テンプレート上で書き出し位置を指定しやすいといった理由があったのだろう。

特に,昨日まで Aejs にあった干渉不具合を回避するのに有用ではあったが,もはや不要なのでここで周辺とともに整理しておいた。

まず,@icl() を @elm.bld..apd() を利用した実装にし,スクリプト調整を行なった。AdSense より前の位置に配置していたため,これを body 要素末尾のその他ライブラリ前に移動した。非同期になったことで DOMContentLoaded が終わっている可能性があるため,Document.readyState を利用して DOM 構築完了後であれば即実行する処理を @() に加えた。

更に,各スクリプトに defer 属性を付け,直書きしている部分は addEventListener() で DOMContentLoaded を待ってから実行するようにした。ここはスクリプトを通さず捌き手側で直接書き出してもいいかと思ったが,試してみたところ大して速度差が無かったため,現状維持とした。

更に,link rel="preload"導入,ついでに cfg.vs で設定していた隠し破りテンプレート側で設定し,@icl() や @apd_ss() に引数として渡すようにした。テンプレート側で直接記述している URI に利用出来ず,修正作業でよく二度手間が発生していた。

ここまでの作業で体感的描画速度向上が見られた。ただし,速くなった分描画過程が見えてしまうようになったため,明日装体書調整を行うことにした。

未出振るい

{進捗記録}{進捗}{Firefox}{希哲15年4月8日10歩}{希哲15年4月1日の開発}{alt 属性}{ae.img.vs}{希哲15年4月1日の進捗時限}{希哲15年4月1日の進捗}{希哲15年4月1日}(26)

{希哲15年4月1日12歩 K#F85E/E74C-8A77}

Aejs@icl() 見直し

途中で終了。

@img による画像補完は非常に気に入っているが,導入後,唯一気になっていた問題として,読み込みのたびに画像が一瞬消えて見える,ということがあった。この一瞬の長さは舞覧によって差があるが,Firefox ではかなり気になった。また,alt 属性があると一瞬文字が見えてしまうため設定出来ない,という問題もあった。

スクリプト整理しながら,これが単に DOMContentLoaded@img.init() を呼び出していたせいだと気付き,@img 客体の構築後(ae.img.vs)に即実行するように修正した。これで問題は解決した。

もしかしたら画像補完手法そのものに問題があるのか,などと思っていたため安心した。

{進捗記録}{進捗}{src 属性}{<img>}{領当て}{希哲14年10月10日の開発}{画像補完}{nil.png}{遅延読み込み}{2x}(49)

{希哲14年10月10日17歩 K#F85E/5B28-AF96}

デライト用合い改良

途中で終了。

.hl_b.x2_b を使った画像補完(今日から仮命名)について,微妙な欠陥発見試行錯誤していた。

src 属性を元に後から srcset 属性を追加するのは,いくら DOMContentLoaded でも間に合わず,二重読み込みが発生する。

src 属性省略しても事実上問題は無さそうだが,仕様上必須とされているため,どうも気持ち悪い。つまり,何らかの画像を読み込ませることは避けられない。

単純な img 要素noscript 要素で囲んでおき,スクリプト解除するという方法を思いつき,理論的には一番美しい気がしたが,レンダリング領当てが事前確保出来ないという致命的欠点があり断念。スクリプト側では noscript 要素の内容をテキストとしてしか取得出来ないのもすっきりしない。

スクリプト依存はいまさら仕方ないとして,ダミー画像を用意することにしたが,埋め込み画像保守性の観点から使いたくない。/img/nil.png あたりの名前を使うことにした。HTTP/2 も導入したことだし立求負担は軽い。

目的とする画像data-src 属性 に書いておくか,まだブラウザ解釈しやすい srcset 属性にするか少し悩んだ。2x だけを記述しておけば,場合によっては src 属性を無視してくれることも期待出来るが,記述がやや煩雑になる。遅延読み込みにも応用出来る data-src の方を使っておくことにした。

{開発}{開発記録}{Aejs}{νS}{jQuery}{希哲13年2月22日}{_ 接頭子}{_T 接尾子}{querySelectorAll()}{DOMContentLoaded}(11)

{希哲13年2月22日の開発 K#F85E/4686-3C64}

ほぼ Aejs 関連の仕様・実装整理に費した。

まずは jQuery 依存部分を @() から排除した。\(( document ).ready() #F85E/A-4686-463A} は {DOMContentLoaded #F85E/A-4686-D3A0} で,{\)()querySelectorAll() で置き換えた。

機能拡張をどうするか悩んだ。現時点でいくつか標準客体の prototype を書き換えているが,これは少し気持ち悪い。切り分けやすく,見通しを良くするため, でしているような絡包で機能を与えることにした。

とりあえず,@foo() で @_foo() 構築子を呼び出す実装にし,@() は型情報に基いて適合する結果を返すようにするか。@foo() に型の判定機能を兼ねさせれば条件記述が簡略化出来るかもしれない。

にならって使っていた _T 接尾子プロトタイプ=ベースの交度に調和していない気がしたので一旦廃止し,暫定的に _ 接頭子 を採用することにした。

あれこれ模索しているうちに,@ が客体を保護する盾にも見えてきて面白い。

{DOMContentLoaded}

{}