{『t_wの輪郭』}{omt}{読み込み中...}{描写後略機能}(4)

{長文の投稿を『t_wの輪郭』で表示すると、「読み込み中...」と表示される K#EDD2/F6F1}

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

案の定、(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回に変更 で行ってみよう。

{KNEST}{開発}{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲17年1月25日の副日記}(402)

{希哲17年1月25日の開発 K#F85E/E74C-7E8A}

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

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

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

デライト高速化現状今後

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

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

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

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

読み込み中...
{描写後略機能}

{}