{希哲15年4月8日の日記}{HTML の肥大化}{動的読み込み}{認識が甘い}{前縁の重要性}{前縁最適化}{思わぬ収穫}{装体適用}{計測値}{6日間}...=}(104)

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

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

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


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

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

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

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


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

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

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


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

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

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

{外部}{スクリプト}=}(2)
{希哲15年4月8日の開発}{修正済み}{希哲15年4月8日の進捗時限}{希哲15年4月8日}{希哲15年4月8日の進捗}{埋め込み装体書}{進捗記録}{進捗時限記録}{進捗時限}{gzip 圧縮}...=}(16)
{スクリプト}{Perl}=}(2)
{defer 属性}{希哲15年4月1日の開発}{描画速度}{二度手間}{link rel="preload"}{速度差}{DOM 構築}{Document.readyState}{Node.appendChild()}{デルン初期実装}...=}(53)

{希哲15年4月1日17歩 K#F85E/A-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 に利用出来ず,修正作業でよく二度手間が発生していた。

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

未出振るい

=}
{希哲15年4月8日10歩}{希哲15年4月1日の開発}{alt 属性}{ae.img.vs}{希哲15年4月1日の進捗時限}{希哲15年4月1日の進捗}{希哲15年4月1日}{@img.init()}{@img}{画像補完}...=}(26)

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

Aejs@icl() 見直し

途中で終了。

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

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

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

{共有用 URI}{埋め込み交度}{注意表示}{希哲15年3月14日の進捗時限}{希哲15年3月14日の進捗}{希哲15年3月14日}{Dex}{allow-scripts}{スクリプト禁止}{自輪郭}...=}(49)

{希哲15年3月14日4歩 K#F85E/A-E74C-7B1F}

デラング整備HTML タグ切り替えについて再検討

iframe 要素sandbox 属性を使い,自輪郭については allow-scripts を加えてスクリプトもある程度使えるようにし,他輪郭についてはスクリプト禁止しつつ注意表示をした上でタグを有効化出来る,という方向で考えていた。

ただ,自輪郭はこれでいいとして,他輪郭については用合いとして少し煩雑かという気もしていた。例えば,ちょっとしたタグが1つ使われているだけでも切り替えて見なければならない。読み手にとってはもちろん,柔軟表現のためにタグを使いたい書き手にとっても好ましい用合いではない。

そもそも HTML安全性についていちいち検査したくない,というのが動機だったが,Dex によってそれも大した問題ではなくなってきた。

他輪郭についても,ある程度制限はした上で安全なタグは普通に利用出来るように軌道修正することにした。


YouTubeTwitter 等の埋め込み交度にもある程度対応することにした。

これも検査が面倒という点で避けていたが,よく考えると,それらしい入力から最小限パラメーターだけ拾って,予め用意しておいたテンプレート置換して出力すれば安全性は容易に担保出来る。

共有用 URI の先頭に + を付けるだけという渡括記法もあった方が良いが,慣れない人は埋め込み交度を貼り付けてくる可能性が高い。

可読性を考えると,描出時に渡括記法に置換してしまうのが良さそうだ。

=}
{希哲15年3月11日の開発}{位置調整}{iOS 13}{mask-image}{スクロール可能}{諸場ブラウザ}{-webkit-scrollbar}{デライト装体調整}{希哲15年3月11日の進捗時限}{希哲15年3月11日の進捗}...=}(43)

{希哲15年3月11日9歩 K#F85E/A-E74C-21E2}

デライト装体調整

諸場ブラウザではスクロールバーが常時表示されないため,描写部スクロール可能なことが分かりにくいという問題があったが,これは続きがある方向に内容溶暗するような効果を付けることで上手く解決しそうだ。線を引く,印を付けるなどよりもさりげなく直感的分かりやすい

諸場でなくても,内容が途中で切れるのが美観的に気になっていたので丁度良い。

これなら描写後略機能透過的実現出来る。用者は普通にスクロールを続ける感覚で続きを取得することが出来る。

最初は -webkit-scrollbar 等を適当に設定して済ませるつもりだったが,iOS 13 以降の Safari では無効らしく,代替手段を探していた。結果的にはより洗練された手段が見つかった。

mask-image を使えばこの手の効果を付けるのは簡単だが,スクロールバーにまでマスクがかかってしまうのが気に入らなかった。

linear-gradient()背景にした独自のマスク要素を作り,位置調整スクリプトで行うことにした。

急ぐことではないため装体のみ作っておいて終了。

{希哲15年3月7日の開発}{0.05秒}{0.3秒}{判定処理}{希哲15年3月7日の進捗時限}{希哲15年3月7日の進捗}{希哲15年3月7日}{通注}{@trap()}{デライト文書構造最適化}...=}(35)

{希哲15年3月7日7歩 K#F85E/A-E74C-F9B8}

デライト文書構造最適化事象関連のスクリプト整理,細かい不具合修正

途中で終了。

最低限の形を整えていったん出振るい

色々試してみると,通注は気付きやすく邪魔になりにくい線で0.3秒要素展開0.05秒,その他選択化などは遅来無し,で丁度良い。よく触れる機能は0.1秒でも遅来があると意外にもたつきを感じる。

@trap()タイマー保持重複しないようにする,という修正はいったん差し戻し

干渉で上手く動かない場合があり,これを回避しようと込み入った判定処理を加えると本末転倒なので,タイマー生成しっぱなしの最初実装様子見

=}