作業方針検討（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 に隠しを持たせることも検討しておくことにした。
少し懸念していたのが埋め込み献典の描画速度だったが，これも全く気にならなかった。そもそもこの手の埋め込み献典の描画は遅いものなので，多少の変化では分からない。