- ハリケーン・ヘレンによる停電と通信の不安定な状況の中で、軽量なWebアクセス性の必要性が明らかになった
- 複雑な画像・スクリプト中心のWebサイトは、モバイル環境ではほとんど動作しなかった
- シンプルなテキストベースのページが、情報伝達とアクセス性の面で最も効率的だった
- Webパフォーマンスの低下は、災害時の情報格差につながりうる
- 危機時にもアクセス可能な軽量Web設計の重要性が強調された
ヘレンの嵐とモバイルWebアクセス性
- ヘレンの嵐で電力とネットワークが不安定な状況となり、Webサイトの読み込みがほぼ不可能になる問題が発生
- 画像、広告、JavaScript など複雑な要素が多いサイトは読み込みに失敗
- シンプルなHTMLテキストだけを提供するページは比較的アクセス可能だった
- この経験を通じて、Webの基本的な目的は情報伝達であることが再確認された
- 視覚的なデザインよりもコンテンツへのアクセス性が優先されるべき
シンプルなWebの価値
- テキスト中心のWebサイトは、低速なネットワーク環境でも高速に動作する
- 不要なリソースを削除すれば、データ使用量と読み込み時間を大幅に減らせる
- 危機的状況だけでなく、モバイルユーザー体験の改善にも有用
- シンプルな構造は保守性とアクセス性の向上にも寄与する
Webパフォーマンスと社会的責任
- 複雑なWeb構造は、情報の不平等を深刻化させる可能性がある
- ネットワークインフラが弱い地域では情報へのアクセスが制限される
- 開発者は、最小限のリソースでも動作するWebを考慮すべき
- 危機対応、アクセス性、持続可能性の観点から不可欠な課題
結論
- ヘレンの嵐の経験は、軽量Web設計の必要性を示す事例である
- シンプルなテキストWebは、危機対応力と普遍的なアクセス性を同時に確保する解決策である
1件のコメント
Hacker Newsの意見
複数のニュースサイトがテキスト専用版を提供している
たとえば lite.cnn.com、text.npr.org、wttr.in などがある
さらに多くの一覧は Greycoderのリストで見られる
こうしたサイトを簡単に見つけられ、地域ニュースサイトでも対応できるような標準化された仕組みがあるとよい
実際に設定されるクッキーはバナーをクリックしたかどうかだけなのに、ページ容量の大半はそのバナーが占めているようだ
関連記事: Hoe werkt het vernieuwde Teletekst
liteサブドメインを使うと購読者限定の記事も読めるCNNが数か月前に攻撃的なA/Bテストをしていたとき、このサイトのことを思い出した
記事のヘッダー画像は2400x1600のPNGで500KBもあり、微細なディザリングのせいで圧縮が効きにくいらしい
同じ画像を .avif（品質90、12ビット）に変換したら15KBまで減った
こういう画像はページの読み込みを遅くし、スクロールを強制し、すぐ忘れられる存在だ
ハリケーンHeleneの際、私が所属するNewspackチームがBlue Ridge Public Radioなどと協力して
低帯域向けのテキスト版ニュースサイトを構築した
text.bpr.orgを通じて数万人に情報を届け、
その成果により OpenNewsの支援を受けて
緊急ニュース向けプレーンテキストWebソリューションを全米の報道機関に展開するプロジェクトを進めている
純粋なHTMLとフォームベースのインタラクションだけでも十分に効果的だ
昔のWebフォーラムはほとんどがJSなしでも完全に動作していた
GitHubもかつてはJSなしでissueの閲覧やコメント投稿ができたが、
今ではほとんど何も表示されない。おそらくトラッキングスクリプトを誘導するためなのだろう
ハリケーンHelene当時の経験をまとめてみる
停電でガソリンスタンドを見つけるのが難しく、近所の人たちと燃料を分け合って使うことになった
太陽光だけを当てにせず、補助電源（車両、プロパン発電機など）を備えておくべきだ
また、緊急サービスのWebサイトはWeb 1.0レベルの単純なフォームと画像でも動作すべきだ
JSの読み込みに5分かかるサイトは災害時には役に立たない
NPRのラジオ更新が唯一の情報源だった
結局、近所の人たちと協力して道路を復旧し、燃料を確保してから脱出した
カード決済ネットワークが麻痺するとPOS端末が動かないからだ
Xfinityアプリは接続が不安定になるたびにエラーを出し、重すぎる
こういう状況でこそ軽量なカスタマーサポートポータルが必要なのに、現実は正反対だ
トリプルSIMのスマホがあればVerizonも追加したい
eSIMはいくつも登録できるが、同時に有効化できるのは1つだけだ
似た経験として、ネパールの土砂崩れのときに数日間孤立したことがあった
情報がまったくなく、電話だけで情報が伝達されており、
道路が開くやいなや車が殺到して混雑と危険が発生した
コロナ時期には地域の規制を簡潔にまとめたテキストページを運営したが、
複雑なブリーフィングよりはるかに有用だった
ウクライナ侵攻の際には難民たちがTelegram、Notion、Google Docsで
24時間以内に自発的な情報ネットワークを構築した
結局、情報伝達の単純化こそが危機対応の核心だ
友人たちにリアルタイムで尋ねながら脱出ルートを確認していた
幸い、ほとんど正確な答えを得られて安全な地域へ移動できた
機密性の高い情報もそこで共有されているようだ
Web業界に長くいる人なら、9/11当時の大規模なWeb障害を覚えているだろう
ほぼすべてのニュースサイトがダウンし、Slashdotだけがかろうじて生き残って情報を提供していた
今ではインフラは大きく変わったが、それでも「もしまた同じことが起きたら？」と考えてしまう
最後のホップがニューヨークのタワー内部サーバーに向かっていた
その後、西海岸へリダイレクトされるまでかなり時間がかかった
最近読んだ記事では、今や1GB RAMでブラウザを動かすのは難しいという話があった
JSは速くなったが、そのぶんWebサイトのコードサイズが不必要に大きくなった
高速ネットワークがかえって非効率を助長したわけだ
関連記事 参照
ほぼ1994年レベルの純粋なHTMLから始めてみるのがよい
<html>、<body>だけでも十分で、必要なら少しだけCSSを足せばよいPico.cssのような外部CSSを使うなら、CDNではなく自前でホストするのが望ましい
npx create-react-appのような複雑なツールはその後の話だCSSはgzip換算で20KB程度に保っている
<meta charset="utf-8">は今でも含めておくのがよい英国政府のGDS Web標準は単純なHTMLで構成されており、
なんとPSPでも動作したという逸話がある
Terence Edenのブログ記事 参照