最近のNYTは、どんどんひどくなってるよね。広告をスキップするのも面倒だし、ニュース記事を読む気にもならない。ページが重すぎてイライラするし、努力する価値もないと思う。NYTみたいなニュースサイトは、賢いネットサーフィンをする人たちが「難しい」サイトに出くわしたら、他に行くか、JavaScriptなしでページを読み込むことを理解してるはずだよ。結局、気に入らないサイトから見出しをコピーして検索エンジンに貼り付けて、もっとアクセスしやすい同じような情報を持ってるサイトを探すだけ。今はもう考えることもなく、自動的にそうしてる。重要なストーリーが一つのサイトだけに限定されてることなんてほとんどないし、だいたいは何十ものサイトが同じ話を取り上げてる。しかも、配信の関係で選んだ別のサイトでも同じテキストや画像が使われてることが多い。デフォルトではJavaScriptをオフにしてるから、オンにすることはめったにないよ（ワンクリックでできるけどね）。AndroidのスマホやPCでは広告なんて見ないし、YouTubeも同様。ウェブページでJavaScriptを無効にすると、ほとんどの広告が消えるし、逃げたやつも他の手段で捕まえられる。要するに、広告はオプションなんだよね。（YouTubeはJSなしでは動かないから、広告をスキップするにはNewPipeやPipePipeを使ってね。）JavaScriptを無効にすると、不要なものが読み込まれないからページがめちゃくちゃ速くなるし、プライバシーを侵害されたりデータを売られたりするリスクも減る。こうやって情報をかすめ取ることに罪悪感はある？全然ないよ。もしこれらのサイトがフェアにやってたら話は別だけど、そうじゃないからね。彼らがズルをするなら、こっちもそれに見合った扱いをするべきだと思う。

YouTubeは、代替クライアントの使用を続けられると思う？それとも、最終的にはNetflixみたいにDRMを導入して、強制的に自社のクライアントを使わせて広告を見せるようになるのかな？

この文脈で「フェアにやる」ってどういうことだと思う？お金を払ってるサブスクライバーが「お金を払ってもひどいからやめた」って文句を言ってるならまだ分かるけど、どうやらそうじゃないみたいだね。

> NYTみたいなニュースサイトは、賢いネットサーフィンをする人たちが「難しい」サイトに出くわしたら、他に行くか、JavaScriptなしでページを読み込むことを理解してるはずだよ。いや、「賢い」ネットサーフィンをする人たちは、全体のオーディエンスから見れば誤差みたいなもんだよ。NYTのようなサイトにお金を払ってるかどうかに関わらず、ほとんどのウェブユーザーはメガバイトが何か、JavaScriptが何か、なぜそれを気にする必要があるのかも分かってない。唯一の考慮事項は、そのサイトに自分が見たいコンテンツがあるかどうか、そしてそれが読み込まれるかどうかなんだ。確かに、二桁パーセントの人が広告ブロッカーを使ってるけど、彼らはJavaScriptの複雑さについて深く考えてるわけじゃない。やりたいことをやればいいけど、NYTの人たちは私たちみたいな人たちのことを気にしてないよ。

https://lite.cnn.com と https://text.npr.org はなかなか勝てないね（彼らの社員も使ってるんじゃないかな）それに https://newsminimalist.com も。

> ニューヨークタイムズみたいなニュースサイトは、賢いネットサーファーが「難しい」ニュースサイト、つまりファイアウォールの背後にあったり、メガバイトのJavaScriptが詰まってるサイトに出くわしたら、他のサイトに行くか、JavaScriptなしでページを読み込むことを理解してるはずだよね。彼らはこれを知ってるし、あなたみたいなネットサーファーが実際にサブスクリプションを買うことはないってことも分かってる。広告ブロッカーを使って収益のチャンスを潰してるし、あなたみたいな訪問者は収益に貢献することは絶対ない少数派なんだ。ホスティング料金を少しでも増やす代わりに、離れてくれるのは彼らにとってほんのちょっとした恩恵だね。

> ニューヨークタイムズみたいなニュースサイトは、賢いネットサーファーが「難しい」ニュースサイト、つまりファイアウォールの背後にあったり、メガバイトのJavaScriptが詰まってるサイトに出くわしたら、他のサイトに行くか、JavaScriptなしでページを読み込むことを理解してるはずだよね。人々がコンピュータをどれだけ使いこなせるかを過大評価してる気がするけど、彼らはランダムな記事を読む人を求めてるわけじゃない。アプリを使うサブスクライバーが欲しいんだろうね。

これは氷山の一角に過ぎないよ。航空会社のウェブサイト（特にエアカナダ）については言わないでくれ。製品オーナーやデザイナー、開発者が、無駄なJavaScriptを読み込んでユーザーの体験を何度も中断させるような簡単なワークフローすら整えられないんだから。Amadeusみたいなコマンドライン端末に戻してほしい。それが理想だよ。どうやったら、ウェブがユーザーのためにデザインされたものに戻れるんだろうね？株主のためじゃなくて。

> どうやったら、ウェブがユーザーのためにデザインされたものに戻れるんだろう？株主のためでもなく、開発者が自分の履歴書を膨らませるためでもなく。

残念だけど、広告クリック以外の支払い方法が必要だと思う。何がいいかは全然わからないけどね。

ユーザーのためにデザインされたウェブに戻るにはどうすればいいんだろう？株主のためじゃなくてね。ビッグテックに洗脳されたトレンド追いの開発者たちに反対しよう。「新しいものがいい」って考え方に囚われてるから。株主たちもサーバーや帯域幅のコストを減らしたいと思ってるだろうし、「開発とメンテナンス」にもお金をかけたくないはず。シンプルなHTMLフォームだけでも、使いやすくて安いサイトが作れるのに、開発者の世代は「JSを使わなきゃいけない」っていうプロパガンダを信じ込まされてるんだよね。

> 航空会社のウェブサイトについては話を始めないでくれ。中国南方航空には勝てないよ。今まで見た中で最悪のウェブサイトだ。フライト自体は問題なかったけど、オンラインチェックインは3回試みて諦めた。無駄な情報はさておき： - ラベルが間違ってたり欠けてる必須のテキストフィールド。あるフィールドは「チケット番号」ってラベルがついてたけど、ずっと拒否され続けた。ランダムにパスポート番号を試したら、通った。 - 時々フィールドには完全に読めないプレースホルダーしかなくて、フィールドの幅が足りないから（「正しいものを入力してください...」）って表示されて、入力を始めるとプレースホルダーが消えちゃう。 - 日付ピッカーが突然中国語になってる。 - 多段階の座席選択プロセスを経ないといけないのに、最後に「もう座席選択はできません」って言われる。 - メールでサインアップしたのに、ログアウトして同じログインページに戻ったら、今度は電話番号でのサインアップが必要だって！？

うちの開発者たちは、一度に750MBくらいのデータをウェブサイトごとに開いてたよ。サーバーが遅いってオペレーションにチケットを出して、見てくれって言われたから調べたんだ。そしたら、ページにある長い動画リストのすべての動画が一部を事前に読み込んでた。サイトが彼らにとってひどい状態にならなかった唯一の理由は、オフィスが数ブロック先のデータセンターに直接ファイバーでつながってたから。ウェブ開発者には128kbit以上の接続速度を許可すべきじゃないよ。それ以上だと、ただ無駄なことをするだけだから。

高性能なコンピュータも同じだね。速いのを使って開発するのはいいけど、Chromebookでテストするのが大事だよ。

あの動画がページに載ってるのは、マーケティングの誰かが欲しかったからだと思う。で、QAが動画の読み込みが遅いって文句言ったから、プリロードが追加されたんだろうね。それで、責任者たちは肩をすくめてそのまま出荷したんだよ。ウェブサイトが遅いとか、データが大量に配信されてるって気づいたからって、賢いわけじゃないよ。開発者を責めるのはやめて。責任を押し付けてるだけだよ。ウェブサイトやアプリの詳細は、開発者だけの責任じゃないからね。開発者の視点から見ると、インフラがビジネスの要求に応えられると思ってるんだ。問題があるなら、下に向かってじゃなくて、上に言うべきだよ。

コンテキストに応じたプリフェッチがうまくできてるのを見たいなら、mcmaster.comに行ってみて。小さくて安い開発用のステージングサーバーを持つ理由はちゃんとあるよ。制限された接続が人々に何を含めないべきかを教えてくれるからね。=3

知らない人のためにお知らせ：ChromiumやFirefoxベースのブラウザには、開発者ツールの「ネットワーク」タブがあって、帯域幅を調整して遅い3Gや4G接続をシミュレートできるよ。CPUのスロットリングと組み合わせると、もっと控えめな環境でサイトがどれくらいパフォーマンスを発揮するかを確認するのにいいチェックになる。

Lyxを使って、テキストウェブ（https://text.npr.org みたいな）を使ってたよ。それに、Usenet、Gopher、Gemini、16KBPSのopusストリーム、携帯のデータプランが制限されてたときは2.7KBPS以下のものも使ってた。たくさんのサイトは動いてたけど、Gopher://magical.fishはすごく速かった。Bitlbeeは、IRCを使ってほとんどデータを使わずに接続できるプロトコルがたくさんあって、俺の助けになってくれた。90年代初頭から、どんなIRCクライアントでも接続できるし、ウェブ開発者だけじゃない。Electron好きは、2GBのRAMマシンや古いCeleron/Core DuoマシンでGL 2.1対応のビデオカードを使って制限されるべきだよ。そのマシンでデスクトップ「アプリ」がスムーズに動くなら、プロジェクトは準備完了ってことだ。

> 「ウェブ開発者に128kbit以上を許可するべきじゃないよ。マーケティング部門もね。彼らがトラッキングスクリプトの主な原因だから。」

うちの家族が初めてブロードバンドのインターネットを使ったのは2005年頃で、月400MBのデータ制限があった。ジャーナリズムの根本的な問題は、経済が成り立たなくなってることだよ。歴史的に見ても、新聞のコピーの価格は印刷コストをかろうじてカバーするだけで、残りは広告で賄われてた。広告はすごく多かったし、新聞には何でも載ってた。FacebookマーケットプレイスやCraigslistも新聞の一部だったし、中古車や不動産のリストをチェックするウェブサイトもそうだった。ジャーナリズムは広告に助けられていたんだ。ほとんどの人は、質の高い報道の全コストを払うほどニュースに興味がないからね。今、繁盛してる新聞は、今起こっていることに直接的な経済的関心を持っている人をターゲットにしているところだけ。ファイナンシャル・タイムズやブルームバーグなんかがそうだよ。実際、多くの人にとってニュースは、毎日新しいから面白かったんだ。今はテレビやインターネットで魅力的なエンタメが溢れてるから、ニュース報道はニッチな商品になりつつある。ニュースサイトが読者からデータを引き出してデータブローカーに売るために必死になってるのは、利益を維持するための最後の手段なんだよ。

120MBのWorld of Tanksのアップデートを、メーター制限のある家庭用インターネットでダウンロードして親に怒られたのを覚えてる。月のクォータは250MBだった。2010年のことだよ。

自分もWindows 95のインストール数（約40MB）での比較が好きなんだけど、これも皮肉なことに、Win95はリリース当初はバloatだと広く考えられてたからね。この記事は広告に焦点を当ててるけど、サイトには昔から広告があったことは注目に値するよ。ただ、そのうるささとリソースの使い方が時間とともに激増してるんだ。小さなスポンサーリンクや（アニメーションなしの！）バナーは気にしないけど、記事を読むためにJSを有効にした瞬間、ページ全体にうるさいものが飛び交って注意を引こうとするのを見ると、すぐに離れちゃうね。

この業界の経済について、もっと詳しい人に意見を聞きたいな。ユーザーを敵に回して得られる数セントって、本当に価値があるの？答えはシンプルだと思うし、大抵のユーザーは気にしてないんじゃないかな。これって、成長した時期に関係があると思う。俺は30代後半で、14歳の時に大きな学区のシステム管理者として初めての技術職に就いたけど、知ってる開発者や管理者はみんな無料のインターネットについて話してた。そのせいで、俺は最も合理的な広告以外は耐えられなくなったんだ。広告を本当に排除するためには、そのイデオロギーが必要だと思う。ウェブサイトがどれだけひどいかだけでも十分なのに、ほとんどの人にはそうじゃないんだよね。

現代のウェブ開発は本当にひどい。ほとんどのウェブサイトは広告だらけのトラッキング地獄だよ。HNみたいにJavaScriptの行が真剣に扱われてるサイトを見ると、神の恵みだね。ウェブをもっと軽くしてほしい。

それに同意するよ。ウェブサイトが俺のRAMを全部使えるからって、使うべきだとは限らないよね…

本当に驚くのは、その使いにくさだよ。ウェブサイトにアクセスすると、ページに重なってるゴミが多すぎて、実際のコンテンツがほとんど見えないことがよくある。これが彼らの収益に良くないわけがないのに、なぜか続けるんだよね。

ウェブサイトでスクリプトを許可するっていうのは（90年代半ばに）完全に間違った決断だったよね。ほんとに腹立たしい。プログラムが俺のコンピュータにダウンロードされて、事前にレビューすることも、信頼できる人の監査に頼ることもできずに実行されるなんて、全く受け入れられない。根本的に欠陥がある。もちろん、ウェブサイトではスクリプトを無効にするけど、開発者たちが混乱してるせいで、JavaScriptが有効じゃないとページが正常に動かないサイトもある。90年代に実行可能なプログラムとHTMLは一緒にすべきじゃないって決めておけば、今の世界はもっと良くなってたと思う。

一歩引いて考えると、ただの読み取り専用コンテンツを見るために、膨大な実行可能コードをダウンロードしなきゃいけないのは、ほんとに馬鹿げてる。バックエンドで処理して、クライアントに送信すればいいのに。

ウェブサイトでのスクリプトには明らかに大きな需要があるよね。ウェブ上で何が許可されるかの権威は誰もいないし、既存の組織がそれを実装しなかったら、誰かがやってたはず。ユーザーは新しい、よりインタラクティブなページにアクセスできるようになったら、そっちに移ってたと思う。49MBのウェブページは、私たちの優先順位を示してるよ。ターゲットオーディエンスは、これを問題なく読み込める速いインターネットを持ってるってことだ。オーストラリアの普通の家庭用接続では、49MBのページを0.3秒でダウンロードできるし、エンドユーザーにとって重要なことを最適化するために時間を使ってる。

この記事がネット全体のDNSブロックリストをこの問題の明らかな解決策として言及してないのは、ほとんど犯罪的だと思う。Hageziの究極リストを使えば、ほぼ100%の広告を止められるし、デスクトップではuBlockを使って見た目のフィルタリングやYouTubeもやってる。フィルターのおかげで、リンクの負荷がどれだけ軽くなってるかを調べるために、テストをやってみるべきだな。あと、負荷を減らしてプライバシーを向上させるために、いくつかの追加ドメイン（主にGoogleやAdobeのフォント）も手動で追加した。

「…フィルターのおかげで、リンクの負荷がどれだけ軽くなってるか。」厳密なテストはしてないけど、体感では十分の一以下になることもあるよ。

実験としてnytimes.comのページを読み込んでみたけど、トラッキングピクセルやその他の広告関連の無駄がほんとに恐ろしい。とはいえ、帯域幅の観点からは、少しはマシだった。広告ブロッカーをオフにした状態でFirefoxは44.47MBのデータを転送した。そのうち36.30MBはmp4動画だった。これらの動画はジャーナリスティックな内容で、広告ではなかった。だから、全体的には、これはウェブページのヒンデンブルクみたいなもんだ。でも、80%が動画っていうのは、そのサイトのコンテンツの一部に過ぎないってことも言っておきたい。動画が多すぎるって意見もあるかもしれないけど、それは編集の問題であって、エンジニアリングの問題じゃない。

その状況への批判が、無駄なサードパーティリソース（例えば、Cloudflare Insights）を読み込むウェブサイトに投稿されてるのは、ちょっと偽善的だよね。幸い、俺はちゃんとしたコンテンツブロッカー（uBlock Originのハードモード）を使ってるから。