<view>
}{希哲17年5月6日の進捗時限}(48)SVG スプライトの手法を取り入れ,SVG アイコンの定義は icn.svg
に集約することにした。
SVG 出与えも Aejs に組み込んで直接挿入してしまうことを考えていたが,舞覧隠しの適切な分離が出来なくなる,要素の再利用に必要な id
属性が使いにくい,といった問題があった。外部 SVG を <use>
で利用すれば Shadow DOM になるので,id 属性の衝突などを気にせず要素を整理しやすくなる。
スプライト画像として background-image
で利用しやすいというのも大きい。:target
とフラグメント識別子を利用して表示要素を変化させる技術があることを知ったが,舞覧によっては効率的に隠し出来ないことがあるらしく,今回は見送った。<view>
が使えればいいが,Safari の対応に難がある。当面は古典的な座標指定で行くことにした。
アイコン制作では,アイコンを並べて全体のばら成しを見ながら調整することが多いため,見本を兼ねられるのも便利だ。
SVG スプライトだけで十分かもしれないと思いかけたが,<use>
1つでも若干冗長な上に,1つのアイコンの要素を細かく制御したい場合に <use>
が複数必要になるため,やはりスクリプトでの補完は欲しい。
埋め込み記法で埋め込まれている輪郭を描き直しても埋め込んでいる輪郭を描き直さなければ反映されない問題の修正,および一部機能で削除済み輪郭が取得出来てしまう問題の修正で終了。
前者の原因は単純に描写 HTML 隠しによるものだったが,報告を受け気付いた。
埋め込み記法処理も Dex_T
の外に出すかと考えたが,隠しの利用効率を考えると好ましくない。そこで,KNEST_T
に埋め込み関係の情報を持たせ,再描出時と輪郭削除時に描写 HTML 隠しを消去するようにした。これなら効率性と柔軟性を両立出来る。
作業中,削除済み輪郭が描写埋め込みや輪郭小窓から参照出来てしまう問題に気付き,これも修正しておいた。
dg_oln()
が b_del
を無視して輪郭情報を返すようになっていた上,一連の函数がそれを前提に実装されていた。これを機に違了処理も見直し,信頼性が向上した。
テーマ切り替えボタンの用合い検討(4歩),新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活(10歩),全知検索ページャー周りの調整(16歩),こまごまとした領当て・装体調整(17歩)といった雑多ながら充実した作業を片付け,ついに描写後略機能を一段落させた(21歩)。出振るい・手定め済み。
描写後略機能により,デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上,通信量削減,SEO 強化,迷惑行為対策など多大な効果が見込める。
昨年末の壊衝不具合修正以後,デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが,今回の高速化を経て,明らかにもう一つ壁を越えた感がある。体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。
一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの,軽いページでは200ms台,重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし,最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に,速さがデライトの武器になってきた。
ここで新生デライト開発におけるデライト高速化は一段落とし,今後は機能追加やトラフィックに応じた微調整に留め,別の機能整備に集中することにした。
その先のデライト高速化については,大きなところでは CDN 導入,KNEST による水平拡大,請い手の隠し機能整備,描写 HTML 隠し以外の HTML 隠し実装,そして中途半端な状態で放置しているページ付け求頼改良があるが,どれも現時点での優先順位は低い。
垂直拡大の余地も十分にあるので,当面は捌き手増強で対応出来るだろう。
23日の開発から始まった一連の高速化で終えた作業は,描写 HTML 隠し実装,KNEST 隠しのクローラー対策,描写後略機能実装の3つ。
全体として,実装コストは最小限に抑えつつ効果は最大化するような落とし所を見つけられた。
これまで Dex_T
には完成した HTML を返す道手しか無かったため隠し化出来なかったが,共通バッファを返す道手(Dex_T::buf()
)とそれを閲覧条件によって仕上げる函数(Dex::fin()
)に分離し,外部で共通バッファを共有出来るようにした上で KNEST 隠し化した。
実装は oln_T
に描写 HTML を持たせることも検討したが肥大化の懸念が大きいため,分離して専用の KNEST 隠し客体を用意した。
これにより,切り分けが難しく進まなかった HTML 隠し実装が部分的にではあるが初めて実現した。デラング処理は特に大きな部分なので,その他 HTML 隠し実装の優先順位が下がった。
24日の開発で出振るい・手定め済み。長大な描写が含まれるページでは体感速度向上が見られた。
KNEST 隠しは一定の成果を上げてきたが,足枷となっていた問題として,ボット,主にクローラーに反応してしまうというものがあった。特に輪郭隠しではほとんど活用出来ない隠しに記憶領域が圧迫され,無駄な設定処理とロックが発生していた。当然,描写 HTML 隠しでも問題になる。
そこで,ボット判定用の KNEST::req_I::b_bot()
を追加し,隠し設定用の函数群(輪数隠し以外)がボットと判定された握接で機能しないようにした。これにより,原則としてボットは KNEST 隠しを取得出来るが設定出来ないようになった。
ただし,ボット判定対象はとりあえず現時点で必要性の高い Googlebot, bingbot, Applebot のみ。迷惑クローラーの類は元々 nginx で弾くようにしているため問題ではない。適宜調整していく。
描写 HTML 隠しとともに24日の開発で出振るい・手定め済み。
昨年5月30日の開発までに実装イメージが概ねまとまっていた描写後略機能だが,描写 HTML 隠しのために共通バッファと仕上げ処理を分離するという方針から,切り分けが容易になり,一気に実装コストが下がった。
これまで,Dex_T
内部でデラング処理を中断・再開する機能としてイメージしていたため,複雑化の懸念が拭えなかった。複雑化は保守性の低下を招き,結果的に高速化にもならないということも考えられたが,Dex_T
では適当な間隔で区切り文字を挿入するだけに留め,仕上げ処理(Dex::fin()
)で切り出すという方式に単純化出来ることに気付いた。
Dex_T
が全体の行数・現在の行番号を設定する。Dex::bl_fdn_T
が部区間の境界で20行以上かつ残り行数10行以上の場合に越化参照 &_omt;
を挿入する。Dex::fin()
では全体・&_omt;
前後の3種類で出力を切り替える。div.omt
を検知し追加読み込みを行う。当初想像していたよりずっと単純化出来た上に,導入前後で使い勝手が全くと言っていいほど変わらなかったのは嬉しい結果だった。もう少し用者が意識するものになるかと思ったが,よく観察しないと気付かないほど透過的に導入出来た。輪郭小窓でも問題なく機能している。
高速化効果は言うまでもなく,長大な描写が多いページでは飛躍的に表示速度が改善した。
当初のデラング処理中断・再開機能はいったん断念し,請い手の負荷軽減を重視した格好だが,実際には捌き手側の負荷軽減もそれなりに見込めることが分かり,万々歳の結果となった。描写 HTML 隠しが活用出来る場面が想定以上に多かったこと,閲覧条件による置換処理の範囲を限定出来ることが効いている。
強いて描写後略機能の課題を挙げれば,ページ内検索の直感性を損うこと,スクロールバーで内容量が分かりにくくなることがあるが,いずれもそこまで気にする人は少ないだろうし,対策は出来る。
ページ内検索については, Ctrl + F に強制追加読み込みの省割キーを兼ねさせることが考えられる。内容量の目安としてのスクロールバーは厳密さよりも少なそうか多そうかがざっくり分かることが重要なので,例えば実際の内容量よりも少なく見えないように後略条件なり下余白を調整すれば実用上の問題は無いだろう。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
9日の SlideShare 対応後,意外にもすぐに若干の応答速度低下を感じるようになり,作業の優先順位が上がった。スライドの埋め込み自体はデライト公式での紹介輪郭でしか使われておらず,因果関係は不明だったものの,時期があまりにも一致していた。Google のクロール統計でも,9日以後はそれ以前と比べて100ms以上の平均応答時間増加が連日見られ,体感とも一致していた。
ざっと Aejs で oEmbed を利用する交度を書いて実行してみると,CORS の違了が発生し,一気に記憶が蘇ってきた。
元々前縁でやろうとしていたのを,CORS 問題が面倒で後縁完結にしたのだった。よほど高尚な理由がないとこの実装はありえないだろうと深読みしていたが,なるほど,単なる一時凌ぎという線があった。当時の記録も残っていた。
仕方ないので,当時面倒臭がってやらなかった専用 API を作ることにし,/mbd
を追加した。Aejs には埋め込み記法処理を集約する @mbd
を追加した。
中継サービスを利用するのが一番簡単な方法だが,信頼性や使い勝手などで不確実性が高い。
出振るい後,すぐに明らかな体感速度向上が見られた。もう少し様子見は必要だが,見込みは正しかったか。だとしても,応答速度低下の原因ははっきりしていない。原因究明にかけられる時間も無い。
一つの輪郭中の一つの oEmbed 通信がサービス全体の応答速度低下を招いたとは考えにくい。考えられるとすれば,握接集中で立求処理が詰まった,あたりか。SlideShare 対応によって気付かない内に何らかの問題を持ち込み,埋め込み記法処理改良によって解消したか,全く別の問題が偶然同時期に発生していただけ,という可能性もなくはない。
いずれにせよ,今回の埋め込み記法処理改良によってデライトの安定性・効率性が大きく向上したのは間違いない。従来の方式では,ページ内で oEmbed を利用する回数×通信時間の応答速度低下があった上に,描写 HTML のタグ削除をしている RSS でも無駄な通信が発生していた。
これは方式によらず発生しうる問題だが,下見機能などで頻繁に更新する場合,その都度 oEmbed 通信が発生していたことに気付き,@mbd
に客体変数を使った隠しを持たせておいた。役割分担が進んだことで今後はこうした最適化もやりやすくなる。/mbd
に隠しを持たせることも検討しておくことにした。
少し懸念していたのが埋め込み献典の描画速度だったが,これも全く気にならなかった。そもそもこの手の埋め込み献典の描画は遅いものなので,多少の変化では分からない。