{進捗記録}{}{}{十分}{}{日本国内}{進捗}{デライト}{希哲17年2月20日の開発}{希哲17年2月20日の進捗}(108)

{希哲17年2月20日5歩 K#F85E/E74C-D898}

進捗時限記録中略

Googleクロール統計平均応答時間異常な値になっている問題についての調査終了

Googlebot稼動している捌き手問題であることが判明したため,しばらく様子見することにした。

1月上旬から平均応答時間クロール頻度不自然に悪化した状態続いていた決して速くない自宅回線からでも大半のページ300ms前後応答しているにもかかわらずクロール統計ではほとんど600ms前後高止まりしている。

1月上旬といえばデライト高速化快調に進み,理論上体感上満足出来るようになってきたなので,明らかにおかしかったGooglebot握接しているページGooglebot用影握接しても遅いということはなく,Applebotbingbotむしろ活発化している。

こうなると Google 側の問題か,と考え始めたGooglebot主に米国内から握接しているので,日本国内からの握接多少の差があってもおかしくはない。ただ,これ以前ここまでの感じたことがなく,クロール統計上で1月上旬から悪化しているので,Google 側何かがあったことになる。

ちょうど Alphabet経営的にごたごたしていた時期でもあり,保守人員不足しているとか設備縮小したということはありそうだ。条件不明ながら米国外捌き手使うこともあるそうなので,これまで近場捌き手使っていたのにデライト高速化し過ぎ米国内からの握接十分判断された,なんて皮肉な考えられなくはない

ここまで考えたところで ping200ms以上かかる GooglebotIP アドレス見つけ原因判明した

こちらではどうしようもないことだが,不気味な現象だったので気分的にはすっきりしたむしろ問題解消した時が楽しみになってきた

{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲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 隠し実装,そして中途半端な状態放置しているページ付け求頼改良があるが,どれも現時点での優先順位低い

読み込み中...
{進捗記録}{十分}{}{描写}{進捗}{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{良いばら成し}{排除した}(206)

{希哲17年1月22日17歩 K#F85E/E74C-EFB2}

進捗時限記録中略

輪郭ページ改良装体調整終了

取り急ぎテンプレート整理して輪郭ページ吊るし輪郭入れていた要素<header> から <main> へ,輪郭ページ輪郭一覧<main> から <div>切り替えた前後景一覧ページでは従来通り

特に急ぎたかった部分上手く片付き残る内部的な問題のみなので,輪郭ページ改良ここで中断することにした。


閲覧専用模動実験をしていた時,輪郭ページ輪郭一覧隠す<header> だけのページになってしまうことに気付いたのが事の発端だった15日14歩

あまり意識してこなかったが,輪郭ページ概念実装大きな不一致生じていた一時凌ぎつもり後景一覧ページ輪郭ページ使うようにしたのはデライト離立補完中の希哲14年8月5日だった。当時とでは輪郭ページ捉え方輪郭充実度全く違う

予てから検索模動輪郭模動内部的な切り分け中途半端なまま進んでいない問題もあったため,抜本的な輪郭ページ改良方針まとめた17日8歩

最近の検索演心そこまで神経質ではないと言っても,<header><main>違い流石に小さくないだろう。何より気付いてしまう表現として気持ち悪いので早く解決したかった

読み込み中...
{開発記録}{}{サービス}{デライト}{デライトはoEmbedに対応している?}{描写下見機能}{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}(243)

{希哲17年1月16日の開発 K#F85E/E74C-6ADB}

作業方針検討4歩閲覧専用模動実装検討5歩デラング整備埋め込み記法処理改良8歩13歩

埋め込み記法処理改良

これまで埋め込み記法処理の中でも oEmbed利用したものについては,Dex 内で埋め込み交度取得直接描写 HTML埋め込んで返していたが,埋め込み交度取得処理専用 API /mbd委ね前縁 Aejs から利用することにした。結果として応答速度改善成功した

埋め込み記法+[URL]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

KNEST 隠し使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{『希哲日記』}{金風}{デライト3周年}{}{日記}{}{輪郭整備}{希哲17年2月}{希哲17年1月}{デライトの完全な成功}(75)

{希哲16年12月27日の日記 K#F85E/E74C-1A25}

{整輪記録}{副日記}{『希哲日記』}{デライト3周年}{日記}{初期}{}{輪郭整備}{希哲16年9月}{希哲16年10月中旬}(153)

{希哲16年11月14日の日記 K#F85E/E74C-87D0}

考え事が多かった。そのせいか,やや脳疲労感があった。

GAFAM の停滞Twitter の混迷中間選挙にも表れた米国政治世界情勢の膠着世界の行き詰まり誰の目にも明らかとなり,その突破口である希哲館事業デライトにとってはこれ以上ない舞台整いつつある

デライトの現状からすると,完全な成功デライト3周年来年2月13日までに果せるかどうかだろう,と考えてみてまだ正式離立から3年経っていないことに愕然とした67年経っているような気分だった。意識先走り過ぎていたのかもしれない。

大輪郭整備では初期ツイスト見直し始めたが,ちょうどデライト構想出来たばかりツイスト群で,何かと感慨深かった当時はデライトの離立全てだった。当然,それでは何も終わらなかった結局,「完全な成功」も通過点一つ過ぎず,また新しい課題立ちはだかるのだろう。これからもずっと,それが私の日常なのだと思うかえって気が楽になった


最近輪郭整備意識しなくても自然と丁寧な描出出来るようになり,良い傾向だと感じている

輪郭整備無計画やっているキリがなく,迷子になりやすいので副日記専用記録加えることにした。「輪郭整備記録」というのも煩わしいので,「整輪」を造語し「整輪記録」とした。傾向進捗の把握中断再開容易になり,開発との釣り合い取りやすくなるだろう。

最近輪郭整備強く意識するようになった現実的な理由一つに,SEE による検索流入伸び悩みがある。検索流入極めて緩やかに増え続けているが,デライト市場戦略補完する役割十分に果せていない

デルンデライト自体前例のない司組である上に変化が激しかったため,SEO 効果測定難しかったが,9月までの開発司組上の課題ほぼ全て解消したことで,献典不足という問題向き合わざるをえなくなった特に9月輪郭情報取得改良による高速化サイトマップ改良後は検索流入にも顕著な好影響見られたものの,10月中旬頃からまた停滞してしまっている。こうなるとページ数対する献典不足以外問題考えられない

読み込み中...
{開発記録}{一段落}{}{デライト}{希哲16年9月26日}{希哲16年9月26日の副日記}{奇数ページ}{付けていなかった}{機能を整えた}{動的挿入}(81)

{希哲16年9月26日の開発 K#F85E/E74C-F544}

新生全知検索整備輪郭一覧動的更新対応

輪郭一覧動的更新対応については一段落

全知検索窓からの検索新規描出更新輪結輪郭一覧動的に更新出来るようになった。これまで通り握接出来る請い手にとっても捌き手にとっても負荷軽減になり,全知検索感触非常に良くなったSafari ではページ遷移発生時動き付け止まるため余計かくかくした感触だったが,これも解消した

デライトでは相振りとしての可使性ウェブサイトとしての可接性両立させた HPA(hybrid paging application)目指してきたが,自動ページ展開機能続いてこれで概ね理想に近いになった。第二次用合い改良新生全知検索整備交差点でもあり,感慨深かった

更新時動き付け多少工夫が必要だった最初は,更新前輪郭一覧完全に溶暗させ,更新後輪郭一覧溶明させるという動き付け試したが,ちかちかして良くなかったopacity: 0.7 まで少し溶暗させて置換してから溶明させるようにしたら良い感じになった。新規描出輪郭一覧上部移動する時はスムーススクロール鬱陶しいのでこの時だけ無効化するようにした。これで概ね満足出来た

ここで広告動的挿入必要になったため機能を整えた。これまで自動ページ展開部分には広告付けていなかったが,これを機に奇数ページ広告表示されるようにした。

{開発記録}{輪括弧}{👀}{👍}{希哲16年8月28日}{希哲16年8月27日}{< おつかれさまです!!!}{想定より}{操作体系}{終えた後}(224)

{希哲16年8月28日の開発 K#F85E/E74C-FC4D}

第二次用合い改良輪郭小窓実装

じっくり調整して満足出来る仕上がりになったため,輪郭小窓実装ここで一段落とすることにした。まだこまごまとした課題残っているため第二次用合い改良継続する

また,次の当努包括的な全知検索整備決めた検索結果改良はもちろん,大幅な高速化望めるまた大工事になるが,一応月内完了目標とする次の全知検索整備も「第〜次〜」と呼ぶことを考えたが,ちょくちょく手を入れているため区切り難しいとりあえず新生全知検索整備」と呼んでおくことにした。

輪郭候補窓輪郭小窓の無番輪符対応については少し迷ったが,どちらも全知検索利用するため作業効率考えて新生全知検索整備後に回すことにした。

輪郭小窓雑感

輪郭小窓については,機能見触れともに十分な完成度達した言える昨日手こずったタッチ事象上手く整理出来るようになった。

装体関しては初回出振るい時には小さめにした前後景部閉じるボタン大きめ修正した輪郭小窓の様子・完成形視覚的な無駄削ったつもりだったが,他要素被るものなので小さい視認操作難がある見た目思ったより良い感じ出来た

アンカーテキスト輪符展開するだけだった従来の用合い比べると劇的な進歩だ。デライトの用合い転換点になるだろう。

第二次用合い改良雑感

読み込み中...
{解消した}

{}