たった1KBが驚きの差に！ウェブページの読み込み速度、14KBと15KBでこれほど違う

悪い奴になって、MTUを1000パケットに設定しちゃえよ…。
ダイヤルアップ接続でバッファブロート起こしてる人を詰まらせる以外、特にデメリットはないはず。

これってひどいアイデアに聞こえるけど、具体的に何がダメなのか誰か教えてくれない？

標準外の設定は、ミドルボックスを壊したり、セキュリティ脅威としてブロックされたりする可能性があるよ。
携帯キャリアの変なプロキシ（特に4G未満）もモバイル接続をダメにするかも。
遅い回線だと再送地獄で接続が止まるし、ISPルーターのバッファを埋めて他の接続まで遅くしたり切ったりする可能性もあるね。

TCPの輻輳制御、特にスロースタートは、80年代のダイヤルアップ時代からの遺物だね。
ISPのリンクが50KBのバーストトラフィックを処理できないなら、アップグレードすべきだ。輻輳を前提とするのはおかしい。
スロースタートを無効にして、パケットロスに依存しないBBR輻輳制御を使えば、TCPスループットが劇的に変わるよ。

スロースタートって、ウェブサイトの肥大化と戦うのに良い動機付けになるかもね。
「ページサイズを300KB以下にすれば、1往復で読み込めるよ」みたいに簡単な成功体験を与えられたら、もっと多くのフロントエンド開発者が考えてくれるんじゃないかな。（まあ、大して変わらないだろうけどね。）

そうすると、接続開始時の輻輳制御を無効にするようなもんだね。
遅い接続だと、それがちょっと困るんだよ。
バッファの問題が起きるか、パケットが落ちるかのどっちかになるだろうね。

ソフトウェア開発者はメディア層をもっと意識すべきだ。
3G/5Gの信頼性やレイテンシの話は重要だよ。
HTTPではパケット順序が大事で、RESTリクエストが1パケットになるのは1400バイト未満の時だけ。それ以上だと複数パケットになり、再送などでUI更新が遅れる。
Chrome Dev Toolsで3Gモード＋パケットロスを試せば、小さな最適化でもUI応答性が改善するよ。
だからAPIやUIはできるだけ小さくすべきだね。

同感。記事には良い情報もあるけど、14KBのウェブページを例にするのはイマイチだね。
APIリクエストの方が良い例になると思う。

極端な話だけど、UIにも当てはまるよ。最初の画面表示に必要な要素を14KB以下にするのは大事だね。例えば、CSSを含んだindex.htmlとかさ。

14KBは厳しい目標だけど、最初の10パケットに収めるって考えは面白いね。ページサイズに力を入れてる512kb.club [1] は、サイトのサイズをゴルフみたいに競うんだ。俺のサイト [2] は全アセットで71KBちょっとだったよ。このプロジェクトのおかげでCloudflare Radar [3] も知ったけど、これ、サイト分析にめちゃくちゃ使えるツールだよ。

ユーザーじゃないんだけど質問。残りの500KBで俺らユーザーに何してくれてるの？
90%はテキストに興味あるし、残りはほとんどベクターグラフィックで十分でしょ。14KBでもかなり多くのテキストとグラフィックの量だよ。他の500KBは何に使ってるの？

テキストはそうだけど、グラフィックはね…。SVGは、基本的な図形より複雑だと、みんなが思ってるほど小さくないし、ベクターグラフィックで表現できないものも多いんだ。テキストだけのページが良いってのは分かるけど、『グラフィックも』ってのは、俺はかなり非現実的だと思うな。

SVGがどれくらい得になるかはコンテンツ次第だよ。複雑なSVGでもめちゃくちゃ効率良い時もあれば、残念な時もある。ただ、生のSVGは冗長だけど、HTTP転送ではラスタ形式画像（圧縮済み）とSVG（未圧縮）を比べるのは不公平だね。SVGはBrotliみたいな高性能圧縮とも相性抜群だし、事前に圧縮されたファイルを使えばサーバーの負担も減らせるよ。

ベクターグラフィックってのは、シンプルなグラフィックのことだよ。YouTubeとかTwitter以外で、凝ったものなんていらないし。俺にとってHacker Newsはウェブの理想なんだ。選択肢があれば、ほとんどのユーザーもそう思うんじゃないかな。

いや、君は間違ってるよ。俺も含めて、ほとんどのユーザーはHacker Newsより凝ったものが好きなんだ。

もしウェブサイトで、複数の言語に対応した凝ったコードブロックのシンタックスハイライターを使いたいなら、それだけでそのくらいのサイズになるよ。正規表現のルールとか、正規表現エンジンとかね。

エンドユーザーとしては、バックエンドで一度だけハイライトしてくれるウェブサイトが良いな。

俺はフォントに使ってるよ。俺のウェブサイト [0] は、圧縮されたHTMLとCSSが約15KBで、フォントが200KBもあるんだ。

フォントの読み込みなんて気にならないな。正直、ブラウザにフォントを読み込まない設定があって、デフォルトのフォントを使うオプションがあったら、20回中19回はそれを選ぶね。

Firefoxにはそのオプションがあるよ。一番困るのは、一部のウェブサイトがシンボルにカスタムフォントを使ってることだね。

15kBの圧縮HTML + CSSかあ。クラスがCSSを重複させてなければ、14kBより少なくできたはずなのに。

個人サイトなら512kbは十分達成可能だよ。次の目標は99kb（上限100kb）にすること。数週末あれば結構簡単にできるはず。俺のサイトは512kbでオレンジ色ゾーンって感じ。

これ、わかるわ。俺も512kbがもっと現実的なベンチマークだと思うし、自分のサイトもそうしてる。現代のウェブは、14kbのウェブサイトなんてとっくに昔に超えちゃってるからね。

これ、別の理由かもね: https://blog.cloudflare.com/russian-internet-users-are-unabl…
Cloudflareの分析によると、ロシアのISPはインターネットユーザーがWebアセットの最初の16KBしか読み込めないようにスロットリングしてるらしくて、ほとんどのウェブナビゲーションが不可能になってるんだって。

うーん、Cloudflareはロシア向けのトラフィックのために、パケットサイズとか初期ウィンドウとか、なんか他の設定を増やせないのかな？

TCP Slow Startを知らない人と、ウェブサイトの読み込み速度が数ミリ秒速くなるのを気にする人が重なることは、ものすごく少ないよ。スタートアップは、まず「始めること」に集中すべきで、パフォーマンスじゃない。そのレベルで速度を最適化するような大企業には、経験豊富なSREのチームがいるから、どの詳細にこだわるべきか分かってるはずだよ。

パフォーマンスがどうでもいいっていう考え方、ほんとイラつくんだよね。そうやってDockerやKubernetesとか、触るもの全てをぶっ壊してる絶対的なクソスタックができちゃったんだ。パフォーマンスは大事なんだよ。何十年もKnuthの最適化に関する名言を誤解し続けて、ハードウェアの性能が5～6桁も上がったのに、未だに遅くて肥大化した欠陥だらけのソフトウェア製品を作り続けてる。パフォーマンスは実際に重要で、他の条件が同じなら速い製品の方が気持ちいいでしょ。幸い、Figmaの連中みたいにリスクを取ってそれを証明してくれた人もいる。たとえ難しい技術的問題を革新してる時でも（ほとんどの人はそうじゃないけどね）、パフォーマンスはやっぱり大事だよ。

だよね。だから、例えばMicrosoftのソフトウェアは完璧に動作して、最高の効率を出してるんだよね。

俺が言ったのはさ、担当エンジニアはどんなトレードオフをしてるかちゃんと分かってて、その能力もあるってことだけだよ。

コンテナってさ、VMがコールドスタート遅くてメモリ食いすぎだったから生まれたんだぜ。性能が最優先ってことだよな。

スタートメニューにReactを使ったのは能力じゃなくてさ、担当者がTwitterで『知ってるから使っただけ』って言ってたんだよ。何も考えてないってことだよね。
https://x.com/philtrem22/status/1927161666732523596

『もっと大事なことあるから気にしない』ってスタンスだと、結局何も気にしなくなるんだよな。企業的にはTCPウィンドウサイズに合わせた最適化より、いつだって他の優先事項があるんだ。だから最近のアプリやサイトはどれもこれも遅くて最悪なんだよ。

VMみたいにコンテナってライブフォークできるの？VMのクローンはメモリコピーやめればめっちゃ速いんだぜ。あとはNICを排出して新しいの起動するだけだしな。

これな。まさにMicrosoftが何十億人も使うStart MenuにReact Nativeみたいなモダンなフレームワークを使う理由だよ。

ま、0.5秒って小さい差じゃん。だからサイト専属の人ができるまでは、もっと優先すべきことあるだろうな。『今のアプリやサイトはどれもこれも遅くて最悪』って言うけど、過剰最適化不足よりもっとウェブには問題があるんだよ。

クラウドプロバイダーが代わりにやってるのかも。OpsからAWSがホストOSのセキュリティアップデートを適用すると聞いて、クラスター再デプロイ要るか聞いたら、もう終わってたって。うちのクラスターはプロセスの起動時間を記録してて、その朝は再起動なかったんだ。テーブルクロス引き抜き術みたいな感じだったよ。TIL。

パフォーマンスは重要だけど、コードを複雑にしすぎない範囲でね。だからシンプルな静的サイトが最新フレームワークのサイトに勝つことも多いんだ。維持が大変だし、アクセシビリティやプライバシー、倫理面で犠牲を払うこともあるから。不合理な性能低下は避けるべきだけど、使い物にならなくなったり、やることに対して複雑になりすぎたりするほど性能にこだわりすぎるのは良くないよ。

このTweetは本気じゃないし、Start Menuの開発者でもなさそうだよ。もし違う証拠があるなら教えてほしいな。

コンテナのライブフォークとか、俺には全然魅力ないな。クラウドホスティング会社じゃないし、もしそうでもコンテナじゃなくてVMでVPSを提供したいよ。

コンテナは本来速く簡単にするはずなのに、仮想化の魅力で作業がめちゃくちゃ遅く悪くなった。Googleみたいな大企業ならわかるけど、中小企業には100％無駄で破壊だよ。両方経験したけど、コンテナが役立つ場面なんて、ごくわずかだよ。

「十分大きな企業には経験豊富なSREチームがいる」って言うけど、そうだと良いんだけどね。最近の大企業のアプリ見たことある？って感じだよ。

注意しとくけど、Xは4chanより荒らしが多いんだからね。

これがSteamOSがハンドヘルド機でWindowsを完全に圧倒してる理由なんだよ。

Dockerって、実はいい感じなんだよ。

なんで？ネイティブ原理主義者たちが言うように、RNより酷いウェブベースのUIを使ってるからなの？

待ってくれ…これって、すごく変なジョークだって言ってくれよ、頼むからさ。

いやー、Dockerは、今みんながOOでの失敗を振り返ってるみたいに、後で「あれはまずかったな」って後悔する時が来るんじゃないかな。

パフォーマンス向上は問題どころか、コードをシンプルにして理解しやすくするんだ。高パフォーマンスなソフトウェアは、コード量を減らし、概念を単純化し、実行時間を短縮する。これはトレードオフじゃなくて、どこまでも価値があること。長年パフォーマンスを無視してきたせいで、今のひどいソフトウェアが生まれたんだ。

この動画を見つけたよ: https://www.youtube.com/watch?v=kMJNEFHj8b8&t=287s
話してる人たちはMicrosoftのソフトウェアエンジニアだから、彼らの話を疑う理由はないね。スタートメニュー全体がReact Nativeってわけじゃないけど、一部はそうみたいだよ。

機能を自分で使うか、ベンダーに使ってもらうか、その価値を否定するかのどれかだよ。それ以外の考え方は矛盾してるね。

＞0.5秒は小さな違い
どこから手をつけていいか分からないよ。ほとんどの人は合計レスポンスタイムで0.5秒以下を目指してるんだ。そもそもウェブアプリケーション開発してるの？

前のと全く同じコンテナを新しく作るってこと？それは可能だけど、そんなコマンドがあるツールは多分ないんじゃないかな…だって何のためにやるの？コンテナ内でプロセスをフォークするのと、大体同じ結果になるよ。

”10年以上前、Amazonは100ミリ秒の遅延が売上の1%減につながると発見した。2006年には、Googleが検索ページの生成時間で0.5秒余分にかかると、トラフィックが20%減少することを見出した。”

なんてこった…俺のホームページ、17.2KBだよ！依存関係抜きでね。ちなみに個人的なホームページをめちゃくちゃ最適化したら、Lighthouseスコアが全部100/100になったんだ。Railsで構築したのに、以前はこんなの不可能だと思ってたよ笑。自分のサイトを最適化するのは、本当に価値がある。体感できる遅延なしでページが読み込まれるのは、本当に気持ちいい体験だからね！

うん、news.ycombinator.comが即座に読み込まれるの、俺の脳みそがめっちゃ喜んで、休憩中についつい自動的に開いちゃうんだ。