たぶんブラウザじゃないやつでデライトをアレするとアレ。

案の定、(await fetch("https://dlt.kitetu.com/KNo.EDD2")).text()すると途中で途切れている。つまり、初期のHTMLを処理した後に、JavaScriptを実行することで、追加のデータを取りに行っているということだろう。

読み込み中...のクラス名であるomtで検索してみると、描写後略機能というのがあるらしい。コレやわ。ただ、具体的に何をしているかは分からなかった。

JavaScriptを実行することで、追加のデータを取りに行っている コレのAPI的ななにかを直叩き出来ると良いかも？ネットワークタブで観察した感じでは、https://dlt.kitetu.com/KNo.EDD2/B3D0?dln&fmt=HTML&hdg_lvl_bs=1&ran=2からの通信に追加のデータが入っている。アクセスしてみると追加のデータが表示された。コレですねぇ。ただ、投稿内容が完全体で取れたほうが処理的には楽なので、URLをいじってみる。こうじゃ→https://dlt.kitetu.com/KNo.EDD2/B3D0?dln&fmt=HTML。

クローラーの実装を考えると、中略された輪郭のスクレイピングを追加でするほうが処理を使い回せて、実装がかんたんなんだよなぁ……。

うーん。どったもんかな。投稿の輪郭の詳細ページをスクレイピングすれば、全文が取得されるんだけども、負荷が増えるのは避けたい。

いや、負荷つったって、1分に2,3回のスクレイピングは負荷としてはかなり弱いんじゃないだろうか。念の為に1分に2回のスクレイピングを2分に2回ぐらいにしておくと良さそう？

一旦、投稿の輪郭の詳細ページをスクレイピング・スクレイピングを2分に2回に変更 で行ってみよう。

描写の文字数制限についての仕様検討で終了。

現行の10,000字は長文を書くと割と越えられる文字数なので，100,000字に拡張することを考えていたが，これは決定とした。現実的には50,000字でも十分だろうが，中途半端だとケチくさく見える。描写後略機能も上手く機能しているので司組が重くならない程度の制限でいい。デラングの場合，単純に人が読むだけではない文字が多くなるという問題もある。

問題は，描写後略機能のような機能が無い1行あたりの文字数制限だが，これは各記法ごとに仕様を決めていくことにした。一律の文字数制限を考えてみたが，記法によって事情が異なるので難しい。全体の文字数制限が緩和した分，負荷抑制のための柔軟な処理も必要になる。

23日の開発から急速に進展したデライト高速化も一段落した。

テーマ切り替えボタンの用合い検討（4歩），新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活（10歩），全知検索ページャー周りの調整（16歩），こまごまとした領当て・装体調整（17歩）といった雑多ながら充実した作業を片付け，ついに描写後略機能を一段落させた（21歩）。出振るい・手定め済み。

描写後略機能により，デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上，通信量削減，SEO 強化，迷惑行為対策など多大な効果が見込める。

デライト高速化の現状と今後

昨年末の壊衝不具合修正以後，デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが，今回の高速化を経て，明らかにもう一つ壁を越えた感がある。体感として，「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。

一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの，軽いページでは200ms台，重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし，最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に，速さがデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化は一段落とし，今後は機能追加やトラフィックに応じた微調整に留め，別の機能整備に集中することにした。

その先のデライト高速化については，大きなところでは CDN 導入，KNEST による水平拡大，請い手の隠し機能整備，描写 HTML 隠し以外の HTML 隠し実装，そして中途半端な状態で放置しているページ付け求頼改良があるが，どれも現時点での優先順位は低い。

描写後略機能関連の細かい不具合修正で終了。

開発では大豊作だった。

悲願とも言える描写後略機能の実現によってデライトが最初期から抱えてきた吹き描きの課題も解消し，大きな達成感を得た。

夜も明けて寝ようという頃，「よくやった」と何度か呟いてしまった。

（26日の振り返り日記）

デライト高速化，KNEST 隠し整備。描写 HTML 隠し実装とクローラー対策が一段落，出振るいまで漕ぎ着けた（26歩）。意外と描写後略機能と絡み合う部分が多く，描写後略機能ももう一息というところまで実装出来た。

出振るい後の様子は良好。長大な描写が多いページでは100ms以上の応答速度改善が見られることも多く，成功と言っていいだろう。

まとめは描写後略機能実装後一緒にする。

作業過程でいくつか不具合修正も出来，安定性も向上した。

特に危なかったのは，ers_fst() の壊衝不具合（13歩），/mbd 内でサービスから正常な立返が無かった場合の壊衝不具合だった。

こまごまとした領当て・装体調整で終了。未出振るい。

• スマートフォンを横向きにした時，吹き描き鼻部で隠していた境界線がうっすら見えてしまっている問題を修正。
  • とりあえず .knoz の右境界線の太さを2pxにして凌いだ。
• 描写拡縮ボタン用の padding-bottom を16pxから24pxへ。
  • 内容とくっつき過ぎに見えることがしばしばあった。
  • 描写後略機能用の div.omt があっても丁度良い。
• 埋め込み YouTube 動画のサイズを560x315pxから480x270pxへ。
  • YouTube から普通に取ってきた埋め込み交度のサイズだったが，さほど意味は無さそうなのでショート動画のサイズに合わせた。
  • 個人機でも若干大き過ぎて見にくかった。
  • 幅狭領当てにならないスマートフォン横向きでも見やすい。

また想定外の収穫で，描写 HTML 隠しと描写後略機能の実装イメージが急速にまとまった（2歩，8歩）。

時間対効果は高いため，描写 HTML 隠しから描写後略機能までは最優先で実装してしまうことにした。これで新生デライトの完成までにやりたかったデライト高速化の主要当努も大方片付く。描写 HTML 隠しは HTML 隠し問題の部分的解決ではあるが，中心的な問題でもあるので，当面はこれで十分だろう。

希哲17年1月24日，描写後略機能のため追加。

希哲17年1月24日，描写後略機能のため追加。