私は Wirewiki.com を運営しています。これはドメイン名のようなインターネットインフラストラクチャを検査するサイトです。人々は（歴史的な）DNS レコード、DNS 委譲、電子メール配信可能性の設定などを確認するのに役立ちます。これを提供するサイトはたくさんあります（vibe coding のおかげで、これまで以上に速く成長しています）、なので目立つ方法が必要です。私はツールの品質 / 有用性と UX を選びました。オートコンプリートは Wirewiki を閲覧する主な方法なので、可能な限り完全で正確で高速である必要があります。私はそれが即時であることを望んでいます。次のフレームで即時のようにです。私はほぼそれを達成しました。キーを押したとき（ユーザーがキーを押し始めたとき）、入力された文字 + 次の任意の文字の提案を事前に取得します。そしてキーを離したとき（ユーザーがキーを離したとき）、提案をレンダリングします。これにより、キー押下1の持続時間 + キー押下の間の間隔 + キー押下2の持続時間という時間予算が与えられます。API が 2 番目のキー押下が終わる前に戻れば、結果を時間通りに準備できます。（60 Hz ディスプレイは 16.7 ミリ秒ごとにレンダリングします。したがって、技術的には p50 で 8.33 ミリ秒の追加時間予算がありますが、p99 ではほぼ 0 ミリ秒です。）キーが離された キーが押された wik GET /autocomplete?q=wi 'wik' の補完をレンダリングする API の時間予算 API のラウンドトリップ時間 q=wi のリクエストは、i が押された瞬間に発火します。その応答が k が離される前に到着すれば、wik の補完は、まったく遅延なくレンダリングされます。したがって、この記事の目的のために、遅延をキーを離してから結果がレンダリングの準備ができた時刻まで定義します。p99 0 ミリ秒は、99% の時間、結果はユーザーがキーを離す前に準備ができていることを意味します。これを実現するには 2 つのことが必要です。クライアント側での提案のプリフェッチとキャッシング、および十分に高速な API。予算はどれくらい大きいですか？今度は、2 つのキー押下の持続時間と 1 つの間隔の持続時間を費やすことができることがわかりましたが、これはミリ秒でどれくらいですか？ 100 個のドメイン名を比較的速く入力しながらこれを測定しました。そして p99 は私にとって 121 ミリ秒であることがわかりました。