低速なデバイスを使うユーザーに及ぶWeb肥大化の影響
(danluu.com)- 2017年以降、帯域幅の増加は一般的なサイトの転送サイズ増加をある程度上回ったが、WebアプリのCPU要求量は低価格デバイスの性能より速く増え、速いインターネット環境でもWebアクセシビリティが悪化している
1Gbps接続でもTecno Spark 8Cでは Discourse フォーラムでブラウザクラッシュが発生し、Itel P32では Discourse、Reddit、Shopify、Substack、Wix、Mastodon、Bluesky のようなサイトが FAIL、または事実上使用不能になる- 計測は
M3 Max、M1 Pro、Chrome の10xCPU スロットリング、Tecno Spark 8C、Itel P32でLCP*と メインスレッドCPU時間を比較し、PageSpeed Insights のスコアは実際の体感速度との相関が弱かった - MyBB、phpBB、旧式の WordPress、HN、danluu.com のような単純または古いサイトは低価格モバイルでも比較的よく動作した一方、Discourse、Medium、Reddit、Substack のように動的読み込みが多いサイトでは スクロール・検索・タップ遅延が目立った
- Nigeria、India、Latin America のような地域で低価格デバイスを使う人々は現実のWebユーザーであり、iOS と高速インターネットだけを基準にWebを作ると、裕福でないユーザーや低スペックなデスクトップユーザーまで排除することになる
帯域幅よりCPUがボトルネックになったWeb
- 2017年には遅い接続環境でのWeb肥大化がユーザビリティを大きく損ねており、その後ハイエンド回線の帯域幅は Nielsen の基準で年
50%程度のペースで急速に増加した - 遅いインターネットを使うユーザーは今でも多く、現代のWebのかなりの部分は低速回線では使いにくいが、一般的なサイトでは帯域幅の増加が転送サイズの増加をある程度上回っている
- その一方で WebアプリのCPU性能要求 は帯域幅ほど速く改善しておらず、良いインターネット接続があっても低スペックなデバイスではWebの利用が難しくなっている
- Discourse ベースの「現代的」フォーラムは
Tecno Spark 8Cでブラウザクラッシュを引き起こすことさえあり、クラッシュの合間の応答性も8 MHz 286と1200 baudモデムで BBS を使う場合より悪いと計測された - Discourse でメッセージタイトルを取得する圧縮ペイロードは
2.6 MBで、過去と比べて転送量が1000x増えた水準だが、1Gbps接続では比較的軽い - CPU の観点では
8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)を搭載したTecno Spark 8Cでも Discourse を処理できず、このCPUは286よりおよそ100000x高速な水準にある
計測対象と指標
- テストデバイスは
M3 Max Macbook (14-core)、M1 Pro Macbook (8-core)、Chrome DevTools で10xスロットリングしたM3 Max、Tecno Spark 8C、Itel P32 - ネットワークはデバイスに有利になるよう
1Gbpsのインターネット接続と、高負荷時の遅延が低いとベンチマークされた WiFi ルーターを使用した - 比較対象にはブログ・マイクロブログ、フォーラム、小規模ビジネス向けプラットフォームを含む
- ブログ・マイクロブログ: danluu.com、Substack、Medium、Ghost、Hugo、Tumblr、Mastodon、Twitter、Threads、Bluesky、Patreon
- フォーラム: Discourse、Reddit、Quora、vBulletin、XenForo、phpBB、MyBB
- 小規模ビジネス向けプラットフォーム: Wix、Squarespace、Shopify、WordPress
- 主な指標は転送圧縮サイズ（
wire）、展開後サイズ（raw）、LCP*、メインスレッド CPU時間 LCP*は Chrome が測定する Largest Contentful Paint ではなく、大きな画面更新がユーザーにとって無意味な場合には、実際に有用なコンテンツが見える時点を基準にしている- CPU時間は Core Web Vitals ではないが、遅いデバイスでユーザーが体感する使い勝手と強く結びつく単純な指標として使われた
表から見えるユーザビリティ格差
- danluu.com と HN はすべてのテストデバイスで高速に動作した
- danluu.com は
6kB wire / 18kB raw、Tecno Spark 8Cで0.4s LCP* / 0.3s CPU - HN は
11kB wire / 50kB raw、Tecno Spark 8Cで0.5s LCP* / 0.5s CPU
- danluu.com は
- 古い PHP ベースのフォーラムは、現代的なフォーラムより遅いデバイスで大幅に良好だった
- MyBB は
Tecno Spark 8Cで0.8s LCP* / 0.8s CPU - phpBB は
1.7s LCP* / 1.5s CPU - vBulletin は
4.4s LCP* / 4.8s CPU - Discourse は
15s LCP* / 26s CPUで、Itel P32ではFAIL
- MyBB は
- ブログプラットフォームでも、古い WordPress テーマは Medium や Substack より低スペックなデバイスで大幅に高速だった
- WordPress(old) は
Tecno Spark 8Cで0.7s LCP* / 1.7s CPU - Medium は
2.8s LCP* / 33s CPU - Substack は
14s LCP* / 14s CPU
- WordPress(old) は
- 多くの現代的なサイトは
Itel P32で失敗するか、事実上利用不能だった- XenForo、Mastodon、Bluesky、Wix、Substack、Shopify、Discourse、Reddit は
FAIL - Threads は
28s LCP* / 66s CPU、Twitter は24s LCP* / 43s CPU、Medium は3.2s LCP* / 63s CPU
- XenForo、Mastodon、Bluesky、Wix、Substack、Shopify、Discourse、Reddit は
10s+ CPUを使うページは、読み込み後も悪い体験を生む- スクロールは数FPSまで落ち込み、タップ遅延が長く、ユーザーはタップが登録されたかどうか分かりにくい
- もう一度タップすると、最初のタップが遅れて登録された後に2回目のタップが意図しない動作を引き起こすことがある
実機とCPUスロットリングの差
- Chrome DevTools の CPU スロットリングは便利だが、実際の低速デバイスの結果を一貫して近似できない
M3/10とTecno Spark 8Cの比較では、サイトごとの差が大きかった- danluu.com と Ghost はある程度近似していた
- Medium、Substack、Twitter は
Tecno Spark 8Cの CPU 時間が約3x遅かった - Reddit と Discourse は約
4x遅かった - Shopify は
Tecno Spark 8CがM3/10より1桁以上速い結果を示した
- 遅いページは、デバイスが遅くなるほど 超線形的 にさらに遅くなることがあり、あるページの遅さが別のページの遅さをうまく予測しない
- Discourse、Medium、Reddit は
M3とM1では CPU をあまり使っていないように見えるが、Tecno Spark 8Cでは最も遅い部類に入る - Reddit は何も操作せず待っているだけでも
~90% CPUを使い、CPU が∞と表示された
古いサイトと単純なページの強み
- 古いサイトは概して最新のサイトより速く、10〜20年間見た目がほとんど変わっていないサイトが最速の部類に入っていた
- MyBB は Discourse より
M3で3.6x / 5x、Tecno Spark 8Cで19x / 33x速い - WordPress(old) は Medium より
M3 Maxで17.5x / 10x、Tecno Spark 8Cで4x / 19x速く計測された - Ghost は Medium の1年後に公開された現代的なプラットフォームだが、古いプラットフォームと競える性能を示す例外だった
- NodeBB も付録のテストでは現代的フォーラムの中で例外に近い
M1で0.3s / 0.4sTecno Spark 8Cで3.4s / 7.2s- Discourse より大幅に速く、読み込み後のスクロールやタップも基本的に機能した
動的読み込みと指標最適化の落とし穴
- Discourse、Reddit、Substack のようにページの一部を先に読み込み、残りを動的に取得するサイトは、表のスコア以上に実際の使い勝手が悪い
- 遅いデバイスではスクロール距離を予測しにくく、遠くまでスクロールしすぎると追加読み込みがトリガーされてページが止まることがある
- スクロール済みの過去内容を削除するページは、遅いデバイスでは事実上利用できない
- 動的読み込みページでは、ブラウザの高速な
Ctrl/Command+F検索をそのまま使いにくく、自前の検索実装が必要になる- Google Docs の検索は、ここ数か月あるいは約1年の間、文書読み込み直後には使えないほど読み込みが遅い
- Discourse の検索は、遅いデバイスやそれほど速くないデバイスでうまく動作したことがない
- 理論上は、初期CPU処理が後続の操作を高速化する可能性はあるが、テストしたページは初回読み込み、後続読み込み、読み込み後の操作のすべてが遅かった
LCPのゲーム化
LCPは本来、ユーザーに主要コンテンツが見えた時点を推定する指標だが、Chrome の測定は画面上で大きな描画がいつ起きたかに近い- 一部のサイトは、ユーザーに役立たない大きなローディング画面を素早く表示して
LCPを下げ、その後の実コンテンツがLCPとして捉えられないよう小さな更新に分割している - Discourse は Discourse Splash を公開導入し、低速読み込み時に大きなスプラッシュ画面で
LCPを大きく改善したと案内している - Discourse の公式回答は、実際のコンテンツバナーがスプラッシュより大きいと
LCP上不利になる、という趣旨だった - 有用コンテンツ基準の
LCP*と Chrome 測定のLCPの差が大きい代表例は Wix と Discourse だった- Wix は
M3で6x、M1で12x、Tecno Spark 8Cで3x - Discourse は
M3で10x、M1で12x、Tecno Spark 8Cで4x
- Wix は
性能最適化が事業に与える影響
- 大規模企業では、サイトやアプリの性能改善は A/B テストで測定できるほど大きな金銭的価値を持っていた
- 長期ホールドバックでも、性能改善は成長率と維持率に比較的大きな影響を与える施策として現れた
- Twitter では、ユーザー観測ベースの p99 遅延時間が India や複数の African countries だけでなく United States でも約
60sだった - 各国には遅いデバイスや接続を使うユーザーが十分に多く、制約要因は人口全体の平均的なデバイス・接続分布より ユーザーの忍耐力 に近かった
- 遅いデバイスで
60sを50sに短縮する改善は、ハイエンド機器のユーザーにも5sを4.5sにするような影響を与え、売上・成長・維持率にも影響しうる
低スペックデバイスを考慮した設計
- 遅いデバイスや低帯域幅・不安定な接続では、多くのコンテンツを一度に 静的ページ として読み込む体験が概して最も良い
- 画像に適切な
width、height、alt属性があることは役立つが、progressive JPEG は特に大きな助けにはならなかった - 高速回線がある低速デバイスでは、軽量な静的ページはうまく動作し、性能に配慮した軽量な動的ページも動作可能だ
- 重いページでのスクロール時追加読み込みや検索の乗っ取りは、利用可能なインタラクションモデルを壊してしまう
- Substack は iPhone 8 で記事の
LCPが速いことがあっても、ヘッダーの下へスクロールするには次ページの読み込みを6s待ち、その後も1s~2s待たされる例がある - 対照例として、大きな plain HTML ページは低スペックデバイスでも比較的よく動作する
https://danluu.com/diseconomies-scale/は0.1 MB wire / 0.4 MB rawhttps://danluu.com/threads-faq/は0.4 MB wire / 1.1 MB raw1.1 MBのテキスト1ページは、低速デバイスで大半の現代的サイトより良好に動作する
- Zig standard library documentation はソースコードを最初にすべて取得してローカルで描画するが、
Tecno Spark 8Cで4.7sのCPU使用後も比較的応答性を保っていた
低所得ユーザーとアクセシビリティ
Tecno Spark 8Cは Nigeria でUSD 50-60、India でUSD 100-110程度で入手できるが、これらの地域の世帯所得中央値に対する比率は米国の現行世代 iPhone よりはるかに大きい- 世界全体で見れば
Tecno Spark 8Cは最安クラスの端末ではなく、Itel P32も実際に使われている最低スペック機よりは上の部類に入る - Alex Russell によれば、iOS のシェアは India で
7%、Latin America で6%である - Windows テレメトリによれば、ほとんどのノートPC・デスクトップ利用者は最新の iPhone より遅い可能性が高い低スペック機を使っている
- 支給される “lifeline” phone には iPhone 6 や iPhone 8 もあるが、
Itel P32より低性能な端末も多く、データ上限が小さいため使い切ると求職・福祉申請フォームの記入や Maps の利用が難しくなりうる - モバイルアプリは良好な接続時に事前ダウンロードできるが、Webアプリはアクセスのたびに数MBの圧縮 JavaScript を受信しなければならないなら、制約のある接続では使えない
実験条件と限界
- 各サイトは可能な限り「最も基本的」な体験を探す形で計測された
- WordPress は現在のデフォルトテーマ
twentytwentyfourのデモを使用 - Shopify はテーマ一覧で最初に表示されたテーマを使用
- Discourse、vBulletin、XenForo、phpBB、MyBB は公式フォーラムとして検索で見つかったページを使用
- WordPress は現在のデフォルトテーマ
- この作業は1日以内でデータ収集と分析を行う短期プロジェクトとして進められ、最も一般的なテーマや実ユーザーのカスタマイズ分布までは反映していない
- ノートPCは約
60%のバッテリー残量、電源未接続、20°Cの室内で熱平衡に近い状態に置いた後でテストした - モバイル端末は約
100%充電、電源接続、他アプリやタブなしでテストした - 実際のユーザーは同じデバイスでもより多くのアプリやバックグラウンド作業を抱えるため、多くの場合さらに悪い性能を見る可能性が高い
- サイズはモバイルで計測されており、モバイルとデスクトップで異なる資産を受け取る場合はモバイル向け資産サイズを反映している
CPUはメインスレッド CPU 時間で測定し、他スレッド時間も記録したが指標には使っていない
サイト別の注目事例
- Wix は
Tecno Spark 8Cでスクロールが安定せず、Itel P32では非決定的に失敗する - Patreon は初回読み込みの数値以上にスクロール性能が悪く、古い投稿を探しにくいため、別途 Patreon 投稿の索引を維持したくなるほど不便である
- Discourse は
LCPのゲーム化が強く、M3 Maxの1Gbps接続でも Chrome 測定のLCPは115msだったが、実際のコンテンツは1.1sで読み込まれた - Bluesky は
Itel P32で空白画面を表示した - Shopify の最初の2つの実利用例は、テストしたデモページよりどちらもはるかに遅かった
- Tumblr は
Itel P32で JavaScript エラーが出るが、そのおかげでページ読み込みがむしろ速くなり、スクロールやリンククリックは機能した - MyBB はモバイル版を提供していないため Google には不利かもしれないが、低速モバイルではスクロールやタップが実際によく機能する
- Woo Commerce は初回読み込み性能だけで Shopify と比較しにくく、カートやチェックアウトのような実際のフローまで含めた別比較が必要なため表から除外された
1件のコメント
Hacker Newsのコメント
最近、比較的遅いAndroidスマートフォンを使ってみたところ、テキストと画像しかないように見えるWebページでも、読み込みが本当につらいことがある
実際のボトルネックはネットワークではなく、トラッカーや広告、JavaScriptの肥大化にあることが多い
遅い旧型スマホでは、モバイル版Firefoxのようなフル機能ブラウザ自体が重すぎるため、Firefox Focusのような軽量ブラウザを使うことになるが、拡張機能が使えないのでuBlock Originも使えず、Web体験はさらに悪化する
一部のサイトは「標準」ブラウザでないと文句を言って使いものにならなくなり、企業はその代わりにアプリのインストールを強要する
以前は低速な端末や回線向けの簡素化版があったが、そうしたものは徐々に消えつつあり、JavaScriptの肥大化なしでは広告や追跡ネットワークを回しにくいからだと思う
無限スクロールするページにランダムな広告が差し込まれていると、なおさらひどい
最近の例ではNikeのWebショップが決済中に無意味なエラーを表示し、サポートは「アプリを使ってみてください」と言うだけだった
欧州の航空会社の予約サイトも、大企業のWebサイトがしばしば壊れている典型例だ
2024年になって、ほぼ無限に近いリソースを持ちながら動くWebサイトを作れなくてもブランドに悪影響はないと考えているのは奇妙だ
すべての国で動作させる必要があり、最も遅い携帯電話のかなりの割合がその会社の製品だったからだ
速くはないが、Webサイトの利用に困ることはなく、新しいハードウェアほど即応性はないにせよ十分実用的だ
ただし uBlock Origin は使っている
こうしたAndroid端末は、11年前の標準仕様のMacBookより実際に非力なのだろうかと気になる
世界の不平等の度合いを意識すべきだというDanの主旨には強く同意するが、ラテンアメリカや東南アジアのような中所得国も含めるべきだ
たとえば、月間データ上限が1桁GBで、RAM/CPUが10年前の米国のフラッグシップ級というユーザーがいる
Discourseがまったく使えないほどではないが、体験は不快なくらい遅い可能性が高い
DanがCPU/RAM/ディスクの漸進的な改善によって参加率が測定可能なほど向上すると見ているのも、主にこの層のユーザーのためだと思う
Itel P32のような最安クラスの端末のユーザーには、漸進的な最適化ではほとんど効果がないことがDanのグラフから分かる
助けになりうるのは、機能や洗練さを犠牲にして可能な限り薄いコードを提供する、まったく別のクライアント構成、つまり代替のライト/ベーシックモードくらいだ
ただし、このアプローチはあまりうまくいっておらず、パフォーマンスのために何を残し何を捨てるべきかを米国の開発者が誤って判断してしまうという、共感の問題がまた現れるからだ
現在のDiscourseが PhpBB や DLang フォーラムより何を提供しているのか疑問だ
モバイルフレンドリーなデザインを除けば、まともな世界ならレスポンシブCSSを数行修正するだけで十分なはずだ
月30GBのデータが $3.64 で、最低賃金ベースで4〜6時間分くらいだ
もっと重要なのは、人々が西洋のようにデータを浪費しないという点だ
カフェ、レストラン、スーパー、ショッピングモールのどこにも無料Wi‑Fiがあり、たいていの人はメニューより先にWi‑Fiのパスワードを尋ねる
Webサイトがデータをあまりに早く消費するという話は、見たことも聞いたこともない
開発途上国に実際に住んだことのない人たちが作り出した心配事のように聞こえる
ここでデータが尽きる理由は、TikTok、Instagram、Facebookで動画を見るからであって、Webサイトの肥大化のせいではない
パソコンに最初から入っているブロートウェアも同じだ
最近新しいノートPCを買ったが、50ドルの「チューニング」を提案された
新車のディーラーがそんな提案をしたらおかしく感じるはずだ
電波の悪い場所では問題が10倍悪化する
固定ヘッダーや広告のせいで画面の3分の1しか見えないような複雑なUIの話ではなく、設計書のように見えるまで適当に積み上げたWebサイト自体のサイズの問題だ
きちんと作っていてももともと肥大化していただろうサイトが、遅いインターネット接続では使えなくなり、遅いハードウェアならなおさらだ
説明されたような環境でインターネットを使う感覚は想像しにくいし、その人たちが自分たちの帯域や端末に合ったローカルサイトを使っていて、こちらが相手にしているような肥大化したゴミに悩まされていないことを願うばかりだ
ほとんどのWebサイトは拷問に近い
たいていが上司や恐ろしい大企業のせいにばかりするのが興味深い
効率をよく分かっておらず、知ろうとする気もなさそうな力量不足のWebプログラマー集団も大きいという事実を、開発者たちは認めようとしない
悪いソフトウェアを作るよう強いた上司や企業支配層と同じくらい、彼らにもこの悲しいWebソフトウェアの世界に対する責任がある
「成果物」であるHTML, CSS, JSの具体的な部分を尋ねると、まるで別の言語を話している相手を見るような目をされた
JavaScriptフレームワークの世界から来て、その下にある成果物についてはあまり考えていなかったのだ
私の哲学はほぼ正反対で、手で丁寧に書いたHTML+CSS+JSのWebサイトと同等の結果を出せる、最小限で保守可能なコードは何かを問う側だ
たいてい成果物は何桁も小さくなる
1000件のテーブル行をリアルタイムでフィルタリングしつつ、モバイルでも高速に読み込まれて問題なく動くようにした方法を聞かれたので、最初のリクエストで全データを送り、フィルタに合わないデータを動的に隠しただけだと答えた
Webサーバーは同じキャッシュ済みデータを全員に配るだけでよく、そのJavaScriptもそれだけなので、彼らには不自然なくらい速く見えた
彼らのフレームワークベースの解決策で似たようなテーブル行HTMLを見ると、80%は使いもしないボイラープレートだった
Web開発はあまりに凝り固まり、多くの人がWeb技術の本質から離れすぎてしまった
主な対象が米国やEUのユーザーなら、低性能ハードウェアや不安定で低帯域・高遅延な接続に対して過度に最適化しないのも一理あるかもしれない
しかし対象が農村部アフリカなら、積極的な最適化は当然に思えた
ところがホームページは、CSSで500×1000ピクセルに縮小した2MBの巨大画像を読み込み、その先はさらにひどかった
正確なJSペイロードのサイズは覚えていないが数MBあり、見た目の大半は従来型のテンプレートベースなバックエンドアプリのようだったのに、フロントエンドだけが極端に重かった
コンセプトが良かったので応募はしたが、技術はひどかった
一次面接にも進めなかったのでなぜそうなっていたのかは分からないが、西ヨーロッパの開発者たちがこの点で自分たちのしていることをきちんと理解していない以外、想像しにくい
出発点は開発者ではなく予算だ
上層部が技術に明るくないか、エンジニアリングの背景を持っていないと、普通は新機能には予算を付けても、保守や技術的負債の解消には過少にしか配分しないか、まったく配分しない
保守予算があっても、ほぼ全面的にもっと安価な海外の保守チームに任される
機能チームが6か月かけて機能を作り、海外保守チームと1時間の「KTセッション」をしたあとでコードを引き渡す
海外チームは機能について多少の情報は持つが、既存の技術的負債を管理できるほどではなく、ただ火が消えないように保つ程度だ
組織内でこのサイクルが100回から1000回も繰り返されると、本来は最大25万行で済むはずのフロントエンドが200万行になる状況はすぐに訪れる
新機能チームに最高のエンジニアが入ってきても、すでに作られた箱の中で働かねばならない
モックアップと要素が合わなければ、モックアップが間違っているか、UIキットがアップグレードされたか、既存UIキットのリファクタリングが必要なのかもしれないが、そのための予算はない
だからチームはコンポーネントをコピーして、自分たちの機能に合わせて修正しろと指示される
保守チームに引き渡すときも、新チームは既存機能の作業に触れたくないのでそのまま残す
非技術系の経営陣は違いが分からず、何年にもわたってチームが新機能に合わせるためにコピー&ペーストを繰り返した結果、コードベースには「Button」というコンポーネントが50個以上できる
チームに効率を重視する熟練開発者がいて、より効率的なサイトを強く推し進めるか、最初からもっと効率的に作れば、ページは改善できる
しかし多くの場合はインセンティブの問題だ
経営陣が気にしないなら、プログラマーは時間をかけて効率を高めるより、半分の時間でとにかく動くものを作ってバックログを片付ける方を好みがちだ
だから遅いデバイスは、くだらないものを避けるための優れたフィルターになる
最近ようやく6年前のLGフラッグシップから新しいGalaxyに乗り換えたが、性能差はものすごかった
そうであってはならない
発売当時は非常に高級な機種だったし、それほど古くもなく、まだ新品同様に動く
テスト用のGalaxy S9たちも同じ苦労をしているのを見ると、自分のスマホだけの問題でもない
テストにAmazonが入っていてほしかった
私の経験では、AmazonのWebサイトは4年以上前のモバイル機器で最悪中の最悪に入る
比較的新しい高級モバイルハードウェアでも、私が定期的にアクセスしていたサイトの中で唯一、ほとんど使い物にならないレベルだった
LineageOSでAndroid 14を入れたOnePlus 5を日常用に使っているが、ゲーム以外の作業のユーザー体験は十分に良い
このスマホはRAM 6GBなので、今どきの中級機とも近い
唯一の不満は、バッテリーを交換する必要があったことと、スマホの分解が面倒なことだ
一方、同じSoCにメモリ4GB、Samsungによる改変入りの純正Android 9を使うGalaxy S8は延々ともたつく
メモリ2GBの差が影響している可能性はあるが、2台の差は昼と夜ほど大きい
Android 14のメモリ管理がAndroid 9よりはるかに優れているのか、それともSamsungの遅くて肥大化したソフトウェアが端末の足を引っ張っているのかは分からない
いずれにせよ、多くの企業が古い端末や低価格端末でテストしないのは腹立たしい
世界中のユーザーを相手にするなら、世界の大半の人が最新のフラッグシップを使っているわけではないと見るべきだ
実際、そこまでひどくは動かない
もちろん、そんなことをする必要があるべきではないという点には同意する
ただしFirefoxで広告ブロッカーを全部使っているので、それが効いている気はする
今日の技術は、技術に不慣れな人たちに対してあまりにも無頓着だと思う
スマートフォンがその代表例だと感じる
自分の端末をほとんど使いこなせない人や、まったく分かっていない人を本当に大勢見てきたし、彼らにはすべてが黒魔術のように見える
最大の問題は、見えないため存在しないも同然のジェスチャーナビゲーションに過度に依存している点だ
iPhoneのジェスチャーバーは何とか見つけられるとしても、通知センターやコントロールセンターという概念自体が分からない
この人たちが愚かなわけではなく、ほかの分野では私よりはるかに優れているかもしれない
技術において問題なのは努力不足ではなく、直感的なインターフェースの不足だ
実際のドキュメントを見るにはAppleサイトの文書ページまでたどり着く必要があり、さらに少し掘り下げてようやく使えるジェスチャーをいくつか大まかに示したページが出てくる
いつどのジェスチャーを使うべきかについては、一文の例以上の説明がない
しかもこれはOSの話にすぎない
アプリの中で、自分のアプリでジェスチャー機能がどう使われるかを説明する文書を一緒に提供しているところがどれだけあるのか疑問だ
https://support.apple.com/guide/iphone/learn-basic-gestures-...
彼らは間違いなくそうした機器の周りで育った
だから現代技術だけの問題ではないと思う
ユーザーが自分に合ったデザインやインタラクションを選べるようにする代わりに、デザイナーやプロダクト責任者が全ユーザーにとって何が最善かを知っているかのように振る舞っている
Androidから乗り換えたあとで最も大きな不満の一つだった
戻るボタンはどこにあるのか、ホームボタンはどこにあるのか、そもそもボタン自体がどこにあるのか分からない
Appleのミニマリズムへの執着は本当に嫌いで、このスマホが壊れたらAndroidに戻るつもりだ
この記事はデスクトップで読む48歳の私には基本的に読みにくい
開発者ツールで
bodyに以下を追加したら読めるようになったfont-size: 18px;line-height: 1.5em;max-width: 38rem;こうするとどれほど読みやすく、美しいかが分かる
Dan Luuの記事はよく読むが、毎回こうやって変えなければならない
真面目な話、技術者のみなさん、ページをもっと読みやすくするのに必要なのは64バイト増やすことだけだ
そのページはほぼ問題なく、単に**CTRL +**で拡大すればよかった
そのページはほとんど純粋なテキストで、操作要素もほぼない
あなたにはあなたのユースケースに合った解決策があり、私には私の解決策がある
視覚障害のある読者も自分なりの方法でアクセスできる
ソースが単純だから、アクセシビリティの解決策もそれに応じて妥当なほど単純になる
Danは効果的に伝える方法を分かっていると思う
それはシンプルに保ち、必ずしも目で読まれるとは想定しないことだ
自分の目的に合わせて表示を簡単に変更できる
こういう表示のされ方が気に入らないなら、読む前に自分で再整形すればいい
Danは、簡単に操作できるシンプルなテキストストリームとしてメッセージを提供しているわけだ
Luuの読者層は全体として、比較的スタイルのないアプローチを好む可能性が高い
ユーザーは自分の好みに応じてウィンドウサイズ、フォントサイズ、色などを変えられる
毎回ファイルごとに変える必要はあるべきではなく、複数のファイルに適用できるユーザーCSSファイルを追加して使えるようにすべきだ
Firefoxの標準設定ページにある
ウェブサイトが
font-size: 18px;を強制すると、ブラウザでより大きいフォントを選んでいるユーザーにとっては、かえって文字が小さくなることがあるただしブラウザのリーダーモードを使ってもよく、開発者ツールで何段階も操作する代わりにクリック一つで済む
参考までに、Raspberry Pi 3 では YouTube を使えない
この1年の間にそうなってしまい、その前は10〜15FPS程度で動画を「見る」ことはできていて、作業場で修理動画を見るには十分だった
Raspberry Pi Model B、つまり最初に出たモデルが発売された当時は、リポジトリ上の1080p動画を再生し、YouTube を見て、ゲームもできた
YouTube が何をしているのか、ほかのサービスも何をしているのかわからない
気候危機や変化を真剣に考えるなら、Google や Meta のこうしたやり方を非常に厳しく精査すべきだ
利益のために CPU サイクルを焼き尽くすこと、つまり即興的に推測すれば広告技術のせいで低電力デバイスで YouTube が壊れるようになることは、メディアでも大きく批判されるべきであり、全体のユーザー体験が多少悪くなっても、より効率的なサービスを使うべきだ
Pi3 には x264 のハードウェアアクセラレーションがあるが、YouTube はかなり前から別のコーデックを使い始めた
2021年初頭の Intel MacBook Air でも、中程度の負荷でランダムに動画が止まることがあり、以前はこんなことはなかった
気候変動を解決しようとしてそこを攻撃するのは、プラスチックストローやレジ袋の禁止と同じくらい筋が悪い
もう一つの参考点として、10年前の YouTube ならそのハードウェアでも完全に問題なかったはずだ
犯人は全般的な Web の肥大化であり、より具体的には JS で一般化した抽象化モンスターたちだ
「気候危機」をまったく信じない人に対しても、時間がたつにつれて職人技と品質が失われ、その結果こうした混乱が生じたとは言える
だから政治的スペクトル全体で合意できる話題だと思う
Consumer Reports 方式でもいいし、Nielsen 視聴率のように動くアドオンでもよい
その Discourse 側の人は、実際に私たちが生きている世界ではなく、自分が存在していてほしいと願う世界を基準に製品を設計する典型例だ
Qualcomm SoC を搭載したデバイスは数十億台存在し、今後も存在し続け、製造・販売される
どれだけ不満を言っても変わらない
それを受け入れて、そのデバイス向けに最適化すべきだ
そのデバイスのユーザーは開発者の不平不満など気にせず、ソフトウェアがクラッシュすれば、ただ無能なソフトウェア開発者だと思うだけだろう
普段は Dan Luu の文章が好きだが、今回は外していると感じた
LCP/CPU 表 はよかったが、その後は安楽椅子心理学のような流れになる
Discourse 創業者のランダムなコメントをいくつか根拠にして、読者にソフトウェアエンジニアの態度を想像させようとしている
Knuth まで、シングルコア対マルチコア性能に関する発言や Itanium 関連の発言を根拠に引きずり下ろしていたが、それは古い学術的論争の論点だ
文章があまりに柔らかく、ネット上の言い争いに依存していて、しっかり立つには弱いと感じた
Discourse 創業者の発言は、それを非常によく説明しているにすぎない
最近の Web を使っていれば、想像を超えるほど肥大化していて、Google が今や Largest Contentful Paint 2.4秒 を速いと言うほどだ: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
これは4年前の資料なので、今はもっと悪化している可能性が高い
デスクトップで YouTube が CSS 2.5MB を読み込むことから、Vercel 創業者が非常に速いサイトだと自慢したものが、少し制限をかけるだけで読み込みに20秒かかることまで、遠くへ探しに行く必要もない: https://x.com/dmitriid/status/1735338533303259571
フロントエンド向けの単純な API サービス の応答時間が 500ms でも、誰も嘲笑しない
自分たちのクラウドコストがどれくらいかかっているのかを把握し、気にしているエンジニアがどれだけいるのかも疑わしい
今の 並列性 は、専門的なユースケースや、同じシングルスレッドプログラムを複数のデータ項目に対して実行する場合を除けば、ソフトウェアの90%では使われていない
プログラミング言語もハードウェアも、きめ細かな並列性をまともにサポートしておらず、古典的なソフトウェアを並列アプローチで高速化するのは非常に難しい
Luu はむしろかなり寛大に書いているほうだ
Knuth は、何十年も続いた ただ飯 が終わることに不満を言っていただけに近い
Jeff Atwood は単に例として選ばれただけだ
フォロワーの多い有名な Web 開発のオピニオンリーダーたちが似たような見方を繰り返し発信し、多くのフォロワーがそれをそのまま受け入れている
すべての会社が気にかけるのをやめてしまった。特に、標準や良いWebデザイン慣行の最前線にいた Google や Apple のような会社がそうだ。
Google は最近 HTML Gmail を終了したが、これは 2008年製の256MB RAMの Android フォンや古い Firefox でも高速かつ快適に動いていた。
当然ながら、新しいJavaScript肥大版はブラウザを殺してしまう。
極端な例ではあるが、低価格帯のスマートフォンは RAM 2GB で、いまやこうした端末でWebを閲覧しながら妥当な性能を期待するのは難しい。
モバイルWebはひどく、これはユーザーを「ネイティブ」アプリへ追い込むために意図されたものだ。
Apple や Google のような企業にとって、データ収集や広告表示がより簡単になるからだ。
彼らのサイトはモバイルではひどく、Decathlon は高性能ではないデスクトップでもひどい。
それなのにアプリを目立って勧めてもいないので、単に無能だと見るしかない気がする。
開発者たちはバックボーンにつながった高性能端末でしか、すべてをテストしていないようだ。
RIP Google
新しい Reddit は使えず、old Reddit は古すぎる。
Twitch はチャットと映像ストリームの問題のせいで、かろうじて使える程度だ。
リストは長くなる。
最終的な公式をすでに持っているなら、あらゆる変化は雇用維持のための悪い変化になる。
いつかこの土くれの上のサルたちは、仕事と金が存在しないのだと気づくだろうが、そのときには遅すぎる。
いや、それは今だ。
RIP Humans