ハクソク

世界を動かす技術を、日本語で。

「ヘレーヌ」の間、私はただシンプルなテキストウェブサイトが欲しかった

102日前原文(sparkbox.com)

概要

  • Hurricane Heleneによる被害とモバイルWeb体験の課題を振り返り
  • 災害時の通信障害と情報取得の困難さを体験
  • シンプルなテキスト情報の有効性と重要性を実感
  • Webサイトのパフォーマンスとコンテンツ設計の基本に立ち返る必要性
  • ユーザー視点での改善とアクセシビリティの重要性を提言

ハリケーン被害時のモバイルWeb体験

  • Hurricane Heleneの影響による西ノースカロライナでの大規模な停電と通信障害
  • 多くの携帯基地局が損傷し、緊急情報へのアクセス困難を経験
  • Web開発者として、災害翌日から一週間のモバイルWeb利用体験を振り返り
  • 情報取得のためのページ読み込み失敗やタイムアウトの頻発
  • 僅かな電波を求めて車で移動し、ファーストフード店駐車場でようやく通信確保

緊急情報サイトの課題

  • 政府や緊急サイトの読み込み速度とコンテンツ設計の問題を痛感
  • インタラクティブマップの読み込み失敗やAPIエラーの発生
  • 主要道路閉鎖情報がシンプルなリストで表示されていればと痛感
  • 画像スライダーなど不要なメディアの多用によるページ遅延
  • サイト間でのループ遷移や情報の分散による混乱
  • 「高速表示」モードの設置が後手に回る現状

シンプルな情報提供の効果

  • 災害時の完璧な情報提供は困難だが、ローカルラジオや議員のメールニュースレターが有効
  • 毎日の簡潔な箇条書きリストによる食料・水・電力・避難所・道路・通信状況の伝達
  • テキスト主体のシンプルな情報が最大の効果を発揮
  • スタイルや画像を最小限に抑えたサイトの必要性を再認識

Webパフォーマンスの基本回帰

  • 災害時以外でも、読み込み速度とパフォーマンスは重要
  • モバイル利用率増加にも関わらず、Webの肥大化が進行
  • 速度テストツールや軽量フレームワークの活用可能性
  • 5MB超のアセットや100件超のリクエストが必要か再考
  • 飲食店メニューのPDF配布よりもテキスト化の利便性
  • WordPressの過剰なプラグイン利用やパフォーマンス無視の設計
  • 通信不安定な地域や屋外作業でも情報取得困難

公共・民間Webサイトの現状と課題

  • 政府・公共サービス・金融・医療サイトのパフォーマンス格差
  • Google Page Speed Insightsでの低評価例（40/100, 26/100）
  • 情報設計や基本機能の見直し必要性
  • 利用案内のPDF配布や特定ブラウザ依存の不便さ
  • モバイル非対応サイトや使いにくい検索機能の存在
  • 大規模企業でも基本対応が不十分な現実

Web開発の原点回帰と最適化

  • 過剰なスクリプトや巨大メディアの削減による読み込み速度向上
  • JavaScriptバンドルの最適化や**「First Contentful Paint」短縮**の重要性
  • Semantic HTMLやネイティブ要素の活用によるアクセシビリティ向上
  • キーボード操作やスクリーンリーダー対応の徹底
  • モバイル対応の必須化とCSSツールの活用
  • 情報設計とコンテンツ見直しの継続的な実施
  • ユーザーや開発者との対話による改善ポイントの発見
  • 必要な情報を簡潔に提供する箇条書きやテキストの活用

まとめ：ユーザー本位のWebづくり

  • 災害時や通信障害下でも役立つWebの設計思想
  • シンプルで高速な情報提供の価値
  • アクセシビリティとユーザー体験の両立
  • 日常的なパフォーマンス最適化の必要性
  • 本当に必要な情報を、最短で届ける工夫

Hackerたちの意見

いくつかのニュースサイトはテキストのみのバージョンを提供してるよ。 https://lite.cnn.com/ https://text.npr.org/ https://wttr.in/ 他にもリストがあるよ。 https://greycoder.com/a-list-of-text-only-new-sites こういうのが簡単に見つけられる標準があったらいいのにね。地元のニュースサイトでもサポートしてくれたら最高だな。
└
RSSが恋しい。
└
シェアしてくれてありがとう。最後の部分が皮肉かどうか、ちょっと迷ったよ。HTML自体が標準だったけど、膨れ上がってRSSが出てきたんだよね。これは標準がない問題じゃなくて、企業がプロモーションしないってことだと思う。
└
liteサブドメインを使うのは、すべてのサブスクライバー記事を読むのにいい方法だよ。数ヶ月前にCNNがやってたイライラするA/Bテストの時に、liteサイトを思い出した。
└
CNNの「ライト」記事を見たんだけど、実際の記事コンテンツの11KBに加えて、560KBもあるんだよね（CSSの宣言がめっちゃ多い）。
└
もしかしたら、どんなウェブサイトもテキストだけの簡略版に翻訳するサービスがあればいいかもね。
└
オランダでは、公共放送局が今でもテレテキストを通じてニュースを発信してるよね。
└
> https://wttr.in/ は私の方では読み込まれなかった。
└
Googleも昔は「Go」アプリを持ってたけど、後に廃止されたんだよね。今考えると、検索結果に出てくるウェブサイトが遅いネットワークに最適化されてないのに「Go」アプリを持つ意味って何だろうって思う。
ヘレネに関して気づいたこと: - AT&Tは完全にダメだったけど、VerizonとそのMVNOは使えた - ハリケーンが来るまで使ってなかったVerizonのMVNOのeSIMが、ホームインターネットプランについてきた - 意外とちゃんと動いた！ - Verizonの災害用インターネットトラックが町の警察署に来た日、私のVerizon MVNOのインターネットがダウンした 非インターネットの教訓: - 大きな嵐の前に車の燃料やバッテリーを満タンにしておくこと。私たちは、ガソリンスタンドを探すのにどれだけ時間がかかるかわからなかったから、燃料を集めたりして大変だったよ。
└
AT&TとT-Mobileの回線が入ったデュアルSIMのスマホ（Google Pixel）を使ってる。トリプルSIMのスマホがあったら、Verizonも追加できるのにな。考えてみると、複数のeSIMを持てるみたいだけど、同時にアクティブにできるのは1つだけなんだよね。
└
> ガソリンスタンドを探すのにどれだけ遠くまで行かなきゃいけないかわからなかった 付随する教訓: 現金を持っておけ、そうすればPOSシステムが動いていて、決済カードネットワークと通信できるかに依存せずに物が買える。私の好きな近くのATMは100ドル札を出してくれるから、財布に何百ドルも入れても場所を取らないんだ。
└
数年前のパイナップルエクスプレスから（80マイル以上の突風とたくさんの土砂崩れ）: - 農村や郊外にソーラーを設置する時は、家のバッテリー用にセカンダリーの充電源を用意しておくこと。車かプロパン発電機が使えるけど、買う前に互換性を確認してね。ソーラーだけじゃダメ（嵐で曇ってるし）、プロパンもダメ（道がないし、供給不足やトラックも問題だと思う）。 - どの携帯ネットワークに頼るかは、実際にはダウンしてるだろう（Verizonの件を見ればわかるよね） - すべての緊急サービスのウェブサイトは、5〜10秒以上かかるならWeb 1.0のフォームや静的画像に戻るべきだと思う。5分かけて2Gの速度でコンテンツを隠す偽モーダルを読み込むためにJSやCSSの山を読み込むのはカウントしないよ（PG&Eを見てるよ）。
昨日読んだ関連の記事では、1GBのRAMじゃもうグラフィカルなブラウザを動かすのは厳しいって嘆いてたよ。確かにJavaScriptは今は速いけど、そのせいで平均的なウェブサイトのコードサイズが無駄に大きくなってるんだ。速いJSとネット接続があれば、もっとコードやネットワークリクエストが増えるからね。これってウィルスの法則の一例だよ。2019年末に1GBのRAMを搭載したRaspberry Pi 4を手に入れたときもそうだった。Chromeのタブを1つ開くことはできたけど、それ以上は無理だった。(1) https://log.schemescape.com/posts/hardware/farewell-to-a-net...
記事のヘッダー画像は2400x1600のPNGで、500KBもあるらしい。微妙なディザリングのせいで圧縮が難しいみたい。これを視覚的に同じ.avif（品質90、12ビットカラー深度）に変換すると、15KBまで減るんだ。
└
確かに、そのウェブサイトは6.7KBのテキストを届けるために1.18MB（圧縮済み）を転送してる。ちょっと皮肉だよね。
プレーンHTMLとインタラクティブなフォームはすごく効果的だよ。実際、長い間ウェブフォーラムはJSなしでもほとんど使えたしね。GitHubの劣化がいい例だよ。昔はJSなしでも大体の機能を使えたし、コードリポジトリをブラウズしたり、イシューを読んだり返信したりできたんだ。今はJSがないとほとんど何も表示されない。もちろん、あれは意図的だと思うけど、もう少しトラッキングや分析のスクリプトを動かさせるためにね…
ウェブ業界にいる私たちの中で、十分に年齢を重ねた人は、9/11に起きた「大規模障害」に影響を受けたと思う。あの時、ほとんどのニュースサイトがダウンして、情報を探してたからね。Slashdotは必死に頑張ってて、事件に関する情報を見つけられる数少ないサイトの一つだった（ケーブルテレビにアクセスできない場所にいたら、ほんとに何もわからなかった）。ウェブやインフラは25年前とは大きく変わったけど、今でも「もしも」の考えが頭の片隅に残ってるよ（もちろん、そんな重要なレベルのことには関わってないけど）。
└
Yahooニュースのウェブサイトが反応しなかったとき、私の反射的な行動はトレースルートをすることだった。最後のホップが解決できなくて、NYのどこかに到達してた。なんと、彼らはタワーにホスティングされてたんだ。西海岸にリダイレクトされるまでちょっと時間がかかったよ。
> シンプルなテキストコンテンツがこんなに大きな影響を与えるとは思わなかった。彼がこんな明白な真実に驚いたってことは、彼が（願わくば「だった」）問題の一部だったってことだよね。
ジェレミー・キースのレジリエントなウェブサイトの構築についての良いトークがあるよ。1. コア機能を特定する。2. その機能を最もシンプルな技術で提供する。3. 拡張する！
なんとなく関連するエピソードをいくつか： - ネパールで土砂崩れに巻き込まれて、数日間山の中に閉じ込められたことがある。唯一の情報は地元の人たちの間で電話でやり取りされてた。人々は何が起こっているのか全く分からず、道路が再開した日が彼らの休暇の終わりだった。数日前に道路が崩れたところで車が渋滞してたし、いくつかの場所ではまだ岩が崖から落ちてきてた。通りかかった車を止めて、WhatsAppで情報を更新してもらうよう頼んだ。もしその情報があれば、みんなその場に留まっていられたかもしれない。 - コロナの時期には、簡略化した地域の制限と新しい制限の変更履歴をまとめたページを維持してた。代わりにプレスカンファレンスを追ったり、次の日に規制を全部読み直したり、新聞をチェックし続ける必要があったから、私のは常に固定された場所にある箇条書きだった。 - ウクライナ侵攻の際には、難民たちが今まで見た中で最も印象的なアドホックな情報ネットワークを構築した。24時間で稼働し、数週間にわたって改善され続けた。人々はルート、輸送、国境問題、宿泊、翻訳、物資をTelegramやNotion、Google Docsで整理してた。緊急時には情報の伝達が重要で、人々はそれが苦手なんだよね。シンプルなウェブサイトと双方向のコミュニケーションチャネルを設けるだけで大きな違いが生まれる。
今はテキスト専用のCLIユーティリティを使ってBBCニュースを読んでる。私にとっては、すごく改善された体験だよ。[1]