2017 年，我們探討了網頁肥大化如何影響使用慢速連線的使用者。即使在美國，仍有許多人沒有寬頻速度，導致網路上很大一部分內容難以使用。時至今日，無論在美國國內或國外，依然有許多使用者沒有寬頻，現代網路的很大一部分對網路緩慢的人來說仍然無法使用；不過，頻寬呈指數級成長（Nielsen 認為高階連線每年成長 50%）的速度已經超過了一般網站肥大化的速度，使得這個問題相較於 2017 年已不那麼嚴重，儘管對連線品質不佳的人而言，這仍是個嚴重的問題。

用於網頁應用的 CPU 效能提升速度遠不及頻寬，因此，雖然有越來越多網頁能讓低階連線的使用者存取，卻有越來越多網頁讓使用低階裝置的人無法存取，即使他們擁有高速連線。舉例來說，如果我嘗試在 Tecno Spark 8C 上瀏覽一個「現代」以 Discourse 驅動的論壇，瀏覽器有時會當掉。在當掉的間隙中實際測量效能，其反應速度明顯比用一台 8 MHz 286 加上 1200 baud 數據機瀏覽 BBS 還要差。在我家 1Gbps 的網路連線下，載入訊息標題「所需」的 2.6 MB 壓縮後傳輸量算是相對輕量的。實際在線路上傳輸的大小「僅」增加了 1000x，遠遠被網速的提升所掩蓋。但在 CPU 速度上情況正好相反——就網頁瀏覽與論壇載入效能而言，那顆 8 核心（2 顆 1.6 GHz Cortex-A75 / 6 顆 1.6 GHz Cortex-A55） 的 CPU 根本跑不動 Discourse。這顆 CPU 的速度比我們的 286 快了大約 100000x。或許得要一台快 1000000x 的裝置才夠。

對於不熟悉 Tecno Spark 8C 的人來說，以今天的情況來看，快速搜尋一下就會發現，一台全新的 Tecno Spark 8C 在奈及利亞大約要價 USD 50-60，在印度則可能要 USD 100-110。以占家庭所得中位數的比例來看，這比今天在美國買一支最新一代的 iPhone 還要貴上許多。

以全球標準來看，Tecno Spark 8C 甚至還稱不上是低階裝置，因此我們也測試了更低階的 Itel P32 上的效能（雖然它離現在人們實際在用的最低階裝置還差得遠）。此外，我們還測試了 M3 Max Macbook（14 核心）、M1 Pro Macbook（8 核心），以及在 Chrome 開發者工具中設定為 10x 節流的 M3 Max。為了讓這些裝置都能發揮最佳表現，我們使用相當高速的網路（1Gbps，並搭配一台在負載下延遲表現經實測優於多數同級產品的 WiFi 路由器）。我們測試了一些部落格與微網誌平台（這個部落格、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 使用量（CPU）。Google 的文件將 LCP 解釋為

最大內容繪製（LCP）衡量使用者感知到頁面最大內容可見的時間點。LCP 的指標值代表從使用者開始載入頁面到頁面算繪出主要內容之間的時間長度

LCP 是常見的最佳化目標，因為它是 Google PageSpeed Insights 中呈現的主要指標之一，屬於「Core Web Vital」指標。本文中使用 LCP* 並在旁邊加上星號，是因為 Chrome 所測量的 LCP 是關於螢幕上有大範圍繪製發生的時間點，而非上述定義中關於內容本身。隨著各網站針對 LCP 進行最佳化，出現大範圍但對使用者完全無用的繪製更新、而頁面實際內容卻在 LCP 之後許久才出現的情況，已不算少見。在發生這種情況時，我採用的是有用內容出現時的時間點，而非那個因大型無用更新而被判定為 LCP 的時間點。測試的完整細節以及為何選擇這些指標，會在附錄中說明。

雖然 CPU 時間並非「Core Web Vital」，但這裡仍將它列出，因為它是個簡單的指標，與我和其他使用者在慢速裝置上對可用性的主觀感受高度相關。更詳細的討論請見附錄。CPU 時間之所以適合作為指標的原因之一是，如果一個頁面在其他所有指標上表現都很好，卻耗費了大量 CPU 時間，那它在慢速裝置上就是無法使用。如果它占滿 100% CPU 長達 30 秒，頁面就會有 30 秒完全無法使用；如果它占 50% CPU 長達 60 秒，頁面就會有 60 秒幾乎無法使用，依此類推。另一個原因是，相對於常用的指標，CPU 時間很難透過作弊來美化——很難在不實際改善使用者體驗的情況下，大幅改變這個數字。

下方表格的配色方式是，對於大小而言，越綠代表越小／越快，越紅代表越大／越慢。極端值則以黑色標示。

乍看之下，這張表格大致符合預期，也就是那些除非你有超快裝置否則會感覺很慢的網站，在表格中也確實顯示為慢速（也就是在低階裝置上 max(LCP*,CPU)) 很高）。當我詢問大家認為哪些平台在我們的慢速裝置上會最快、最慢時（Mastodon、Twitter、Threads），大家大致都正確預測到 Wordpress 和 Ghost 會比 Substack 和 Medium 快，而 Discourse 會比 phpBB、XenForo 和 vBulletin 這類老式 PHP 論壇慢得多。我也抓了各頁面的 Google PageSpeed Insights（PSI）分數（未在表中顯示），但那些分數與實際體感的相關性沒那麼強，因為有少數網站設法把 PSI 分數最佳化了，卻沒有真正讓頁面對使用者變快。

如果你從未使用過這類低階裝置，大致的體驗是：許多網站在裝置上根本無法使用，而載入任何耗費資源的東西（一個 App 或一個龐大的網站）都可能導致當機。在耗費資源的 App 中執行太吃重的操作也可能導致當機。雖然評測指出在 Tecno Spark 8C 上可以相當順暢地執行 PUBG 等 3D 遊戲，但這並不代表該裝置就快到足以閱讀現代以文字為中心的社群平台或現代文字論壇上的貼文。雖然在 PUBG 中可以達到 40fps，但在這些網站上捲動時，我們很容易只看到不到 0.4fps 的表現。

從表格中可以看出，有多少網站在你使用慢速裝置時是無法使用的。所有 10s+ CPU 的頁面，即使在載入完成後，體驗也相當糟糕。捲動非常卡頓，經常掉到每秒幾幀，甚至更低。當我們點擊任何連結時，延遲長到讓人無法確定點擊是否真的生效。如果再點一次，就可能陷入那種可怕的狀況：第一次點擊生效了，卻導致第二次點擊做了錯誤的操作；但如果一直等，又常常等得太久，因為原本的點擊其實根本沒生效（或是有生效，但點到的位置不是我們以為的地方）。雖然 MyBB 沒有提供行動版網站，因而被 Google 以「沒有行動裝置友善頁面」為由扣分，但在這些慢速手機上，它實際上比除了最快的幾個網站之外的所有網站都還要好用，因為捲動和點擊真的能正常運作。

另一個可以觀察到的是不同裝置之間相對效能的差異有多大。舉例來說，比較 M3/10 和 Tecno Spark 8C，對於 danluu.com 和 Ghost 而言，M3/10 還算是對 Tecno Spark 8C 的半像樣模擬（儘管 danluu.com 載入得太快），但對 Medium、Substack 和 Twitter 來說，Tecno Spark 8C 在 CPU 上慢了約三倍，對 Reddit 和 Discourse 來說大約慢四倍，而對 Shopify 來說卻快了一個數量級以上。對於 Wix，CPU 的模擬大致準確，但我們的 Tecno Spark 8C 在 LCP* 上慢了三倍以上。Chrome 讓你能方便地在電腦上模擬較慢的裝置固然很棒，但僅僅開啟 Chrome 的 CPU 節流（或使用任何開箱即用的選項組合）所得到的結果，與在許多真實裝置上得到的結果差異相當大。這背後的完整原因超出了本文的範圍；就本文的目的而言，只要知道慢速頁面往往會隨著裝置變慢而呈現超線性的變慢，以及一個頁面的緩慢程度並不能很好地預測另一個頁面的緩慢程度，就已足夠。

如果改從以網站為中心的觀點而非以裝置為中心的觀點來看，另一種解讀方式是，像 Discourse、Medium 和 Reddit 這類網站，在我們快速的 M3 和 M1 電腦上並沒有用掉太多 CPU，但在我們的 Tecno Spark 8C 上卻是最慢的幾個（Reddit 的 CPU 顯示為 ∞，是因為無論我們等多久且不做任何互動，Reddit 都會占用約 90% CPU）。Discourse 在稍微互動一下或只是靜置一段時間後，有時還會讓瀏覽器當掉。舉例來說，有一次在載入 Discourse、捲動兩次後，再讓裝置靜置一兩分鐘，瀏覽器就當掉了。為了保持一致性，這在表格中並未被標記為 FAIL，因為頁面確實有載入完成，但實際上，一個吃資源吃到讓瀏覽器當掉的頁面，其使用者體驗比表格中任何被標為 FAIL 的情況都還要糟。當我們檢視網頁肥大化如何影響慢速連線的使用者時，我們發現網路上很大一部分內容對慢速連線的使用者來說無法使用，而對慢速裝置的使用者來說情況也是一樣的。

另一個可以觀察到的模式是，較舊的網站整體上比新的網站快，那些（視覺上）看起來十年或二十年沒更新過的網站，往往是最快的幾個。例如，MyBB 是看起來最老舊、最沒有現代化的論壇，在 M3 上比 Discourse 快 3.6x / 5x（LCP* / CPU），但在 Tecno Spark 8C 上，差距變成 19x / 33x，而且以整體的擴展趨勢來看，如果 Discourse 能在 Itel P32 這種便宜裝置上跑得動，差距很可能會更大。

另一個例子是 Wordpress（舊版）對比 Medium 和 Substack 這類較新、較潮的部落格平台。Wordpress（舊版）在我們的 M3 Max 上比 Medium 快 17.5x / 10x（LCP* / CPU），比 Substack 快 5x / 7x（LCP* / CPU），而在我們的 Tecno Spark 8C 上，則分別快了 4x / 19x 和 20x / 8x。Ghost 是這個趨勢中值得注意的例外，它是個現代平台（比 Medium 晚一年推出），卻能與較舊的平台競爭（現代的 Wordpress 或許也算是一個例外，但許多人可能仍會將其視為老平台）。在論壇中，NodeBB 似乎也是個小小的例外（詳見附錄）。

那些使用現代技術、例如先載入部分頁面再動態載入其餘內容的網站，如 Discourse、Reddit 和 Substack，往往比表格中的分數所顯示的還要難用。雖然原則上，你可以用簡單的方式打造這類網站，使其在便宜裝置上也能運作良好，但在實務上，使用動態載入的網站往往複雜到在低階裝置上會變得極度卡頓。通常很難或根本不可能以可預測的距離捲動，這意味著使用者有時會因為捲得太遠而不小心觸發更多載入，導致頁面卡死。許多頁面在你捲動時，實際上會移除你已經捲過的部分；所有這類頁面基本上都無法使用。其他基本的網頁功能，例如頁面搜尋，也通常會失效。採用這種動態載入的頁面無法依賴簡單快速的 ctrl/command+F 搜尋，而必須自建搜尋功能。這做得好不好差異很大（這在 Google 文件中過去做得相當不錯，但在過去幾個月或一年間，載入變得如此緩慢，以至於我必須在開啟文件後刻意等待一下，以免觸發瀏覽器那無用的內建搜尋；Discourse 的搜尋在慢速裝置上，或甚至在不算很快但也不算特別慢的裝置上，從來就沒有真正好用過）。

原則上，這些在載入時耗費大量 CPU 的現代頁面，可能是做了一些前置工作，使得之後在頁面上的互動會比那些前期工作較少的頁面更快、更省資源（這是支持這類頁面常見的論點），但對於受測的頁面而言，情況並非如此——它們初始載入較慢，後續載入也較慢，載入完成後的互動也較慢。

要理解為何在理論上預先做這麼多工作，卻通常不會帶來之後更快的體驗，以下這段 Google 的傑出工程師與 Discourse 創辦人之一（當時的 CEO）之間的對話就很能說明問題，很具代表性，在一場創辦人主張應該在筆電上以節流頻寬但不節流 CPU 的方式來測試行動版網站的討論中：

• Google：*你* 也沒有慢速 3G。這兩個設定應該要一起用。同理心需要延伸到在隧道裡使用 iPhone XS 的使用者之外。
• Discourse：基本上任何 iPhone 6 或更新款的手機，速度就跟「平均」筆電差不多。你得理解 Qualcomm 的工作做得有多爛。如果你不相信就去查一下。
• Google：我不需要相信你。我知道。這是關心這件事的人都知道的事。我的重點是，就像不是每個人都有快速連線一樣，也不是每個人都有快速的手機。當然 iPhone 6 在真實世界的網站上也經常會遇到 CPU 瓶頸。但那不是重點。
• Discourse：我們幾十年來一直在朝著無限快的 CPU 速度前進（而我們在桌機上大約五年前就已經漸近地達到了），但我們從未、也永遠不會朝著無限大的頻寬前進。要針對重要的東西去最佳化。還有我對 @qualcomm 毫無同情心。去他的 Qualcomm，他們的工作爛透了。我希望他們倒閉，他們公司所在的土地被撒上鹽，讓任何東西都長不出來。
• Google：行動裝置在大多數情況下根本不是受限於頻寬。他們是受限於延遲。即使是最新的 iPhone，也是在受限於 CPU 之後才會受限於頻寬。如果你在一台 MBP 上以 4 倍降速還能表現良好，那狀況就算是相當不錯了
• ...
• Google：100% 的使用者都在用 iOS 嗎？
• Discourse：會花錢的有影響力的使用者往往都是，我跟你說…… 擔心 CPU 是沒意義的，在 iOS 上它實際上已經是無限快了，即使以 Qualcomm 那種無能的表現，再過四年他們那可笑的 SoC 也會達到

當有人問 Discourse 的創辦人「只是好奇你為什麼討厭他們」時，他回覆了一個連結，該連結引用了來自這篇 Anandtech 評測中的 Kraken 與 Octane 效能測試，其中 Qualcomm 晶片的效能分別為當時 Apple 晶片的 74% 和 85%。

Discourse 的創辦人兼時任 CEO 認為 Qualcomm 的行動裝置效能令人難堪，並對此感到極度不滿，以至於他認為 Qualcomm 的工程師都應該為只做出 Apple 74% 到 85% 的效能而丟掉工作。Apple 擁有一支我認為是有史以來最頂尖的效能團隊。不同的人對此或許有不同看法，但至少必須承認他們是世界級的團隊。所以，做出一款只有史上最強團隊 74% 到 85% 效能的產品，就被視為丟人到該被開除。

這裡呈現了兩種我在許多軟體人員身上看到的態度。第一種是認為 CPU 速度是無限的，不需要擔心 CPU 最佳化。第二種是認為應該期待硬體帶來巨大的速度提升，而硬體工程師之所以無法達成，唯一的原因就是極其嚴重的無能，因此緩慢的軟體應該歸咎於硬體工程師，而非軟體工程師。Donald Knuth 也在以下文字中表達了類似的觀點

我也不妨稍微抱怨一下我個人對當前朝多核心架構發展趨勢的不滿。對我而言，這看起來或多或少像是硬體設計師已經黔驢技窮了，而他們正試圖透過給我們只能在少數關鍵基準測試上跑得更快的機器，來把摩爾定律未來式微的責任推給軟體開發者！如果整個多執行緒的想法最終被證明是個大失敗，比當年那個被吹捧得很厲害——直到後來發現所期望的編譯器根本不可能寫出來——的「Itanium」架構還要糟，我一點也不會感到意外。讓我這樣說吧：在過去的 50 年裡，我寫過一千多個程式，其中許多都具有相當的規模。我想不起其中有哪五個程式會因為平行處理或多執行緒而獲得明顯的提升。當然，例如多處理器對 TeX 毫無幫助…… 我知道平行處理確實存在重要的應用——算繪圖形、破解密碼、掃描影像、模擬物理與生物過程等等。但所有這些應用都需要專用的程式碼和特殊技術，而這些技術每隔幾年就需要大幅更動。即使我對這些方法了解得足以在 TAOCP 中撰寫相關內容，我的時間也 largely 是浪費的，因為很快就沒什麼理由讓任何人去閱讀那些部分…… 我今天使用的機器有雙處理器。只有當我同時執行兩個獨立的工作時，我才能同時用到兩顆處理器；這很不錯，但每週只會發生幾分鐘。

以 Discourse 的情況來說，如果一位硬體工程師無法達到史上最強效能團隊 90% 的效能，就會被視為不配擁有這份工作的難堪人物；但作為一位軟體工程師，做出只有像 MyBB 這種未經高度最佳化的應用程式 3% 效能的產品，卻完全沒問題。以 Knuth 的情況來說，硬體工程師在數十年間每十年就給程式設計師帶來 100 倍的效能提升，而程式設計師幾乎不需付出任何努力。這種提升一旦放緩，程式設計師必須調整以利用新硬體，硬體工程師就成了「黔驢技窮」，但要去學習一些「新」（1970、1980 年代的）觀念來利用現有硬體，卻會被視為浪費時間。而我們之前也討論過 Alan Kay 聲稱硬體工程師「不夠老練」、「沒受過教育」、不是在做「真正的工程」，以及如果聽從 Alan Kay 那些「老練」的想法，我們就能獲得 1000 倍加速的說法。

程式設計師期望硬體能解決他們所有問題是相當常見的，而當這沒有發生時，就把問題丟給使用者，並解釋為何程式設計師不需要為使用者做任何事。一個可以問的問題是，程式設計師到底給我們帶來了多少效能提升。確實有演算法改進帶來巨大加速的案例，但如我們上面所指出的，作為當今成長最快的論壇軟體，Discourse 似乎給我們帶來了大約 1000000x 的效能倒退。

上面呈現的另一種常見態度是，認為不富裕的使用者並不重要。當被問及是否 100% 的使用者都在用 iOS 時，Discourse 的創辦人說「會花錢的有影響力的使用者往往都是，我跟你說……」。我們在 Tonsky 的 JavaScript Bloat 文章的留言中也看到同樣的態度，人們表達出雞尾酒會式的言論，像是「手機 App 都幾百 MB 了，為什麼我們還要糾結於只有幾 MB 的網頁 App？難道非洲飢餓的孩子能下載 Android App 卻不能下載網頁 App？拜託」以及「說真的，應該沒有哪個 gitlab 的使用者會窮到使用慢速裝置吧，認真點」（為求簡潔而改寫）。

但當我們觀察在非洲被下載的 App 大小時，會發現那些沒有使用高階裝置的人，使用的是像 Facebook Lite（只有幾 MB）這類 App，而且普遍使用的 App 大小多為個位數到十幾 MB。有多個原因讓 App 製作者在意 App 的大小。其一是手機上可用的總儲存空間；如果你觀察真實使用者安裝 App 的過程，他們常常必須刪除、解除安裝一些東西才能裝上新的 App，所以較小的體積不僅更容易安裝，在使用者需要更多空間而考慮解除安裝時，被移除的機率也較低。另一個原因是，如果你觀察 App 大小與使用情況的數據（我不知道有任何公開數據；如果你有可以引用的公開資料，請分享給我），當大型 App 增加體積與記憶體使用量時，會出現更多當機，進而導致使用者留存、成長與參與度下降；反之，當它們最佳化體積與記憶體使用量時，當機變少，使用者留存、成長與參與度也會變好。

Alex Russell 指出 iOS 在印度（一個 14 億人的市場）市占率為 7%，在拉丁美洲（一個 6 億人的市場）為 6%。儘管 Discourse 的創辦人說這些不是「有影響力」的、重要的使用者，但他們依然是真實的人。Alex 進一步指出，根據涵蓋絕大多數桌機使用者的 Windows 遙測數據，大多數筆電／桌機使用者使用的是低階機器，其速度很可能比現代的 iPhone 還要慢。

關於「沒有程式設計師會使用慢速裝置」這點，我認識不少仍在使用從他人那裡接收來的、老舊又緩慢裝置的人。他們中有許多人甚至不算真的貧窮；他們只是不明白為何（例如）他們的孩子需要一台超快的裝置，而且他們不理解現代網路有多少內容在慢速裝置上運作得很差。畢竟，那台「慢速」裝置可以玩 3D 遊戲，也能在（搭配合適的 OS 的情況下）編譯像 Linux 或 Chromium 這樣的程式碼庫，那麼為什麼它就不能與像 gitlab 這樣的網站互動呢？

與 Discourse 創辦人所聲稱的「幾年內每個 Android 使用者都會用上某種超快的 Android 裝置」相反，自他發表該言論至今已過了六年，而要讓世界上幾乎所有使用手機的人都擁有高速裝置，至少還需要十年，甚至很可能需要二十年或更久。如果你查詢 Discourse 的市占率統計，會發現它極為成功；它似乎是目前全球成長最快的論壇軟體，而且領先幅度很大。擁有全球成長最快的論壇軟體，卻是由一個其當時的領導者願意公開表示他不在乎那些不是「會花錢的有影響力使用者」、沒有「無限 CPU 速度」的使用者的組織所打造，其影響就是現在有大量論壇對於那些財力不足以購買擁有實質上無限 CPU 裝置的人來說，已經無法存取。

如果 Discourse 的創辦人只是個特例，問題還不至於太大，但他只是把許多程式設計師心中隱含的假設說了出來，這也是為什麼我們會看到如此多現代網站在你購買一支以收入調整後相當於在低所得國家購買全新當代 iPhone 的裝置時，依然無法使用。

感謝 Yossi Kreinen、Fabian Giesen、John O'Nolan、Joseph Scott、Loren McIntyre、Daniel Filan、@acidshill、Alex Russell、Chris Adams、Tobias Marschner、Matt Stuchlik、@[email protected]、Justin Blank、Andy Kelley、Julian Lam、Matthew Thomas、avarcat、@[email protected]、William Ehlhardt、Philip R. Boulain 與 David Turner 提供的意見／更正／討論。

附錄：操弄 LCP

我們在上面提到使用的是 LCP* 而非 LCP。這是因為 LCP 基本上衡量的是何時發生最大範圍的變更。當這個指標尚未被以不 benefit 使用者的方式刻意操弄時，它是個很棒的指標，但隨著越來越多人操弄它，這個指標與實際使用者體驗的代表性已越來越低。在比較不露骨的情況下，人們會做一些能改善 LCP 但幾乎沒有或完全沒有改善實際使用者體驗的小幅最佳化。

在更露骨的情況下，開發者會刻意在頁面上盡早閃現一個非常大的變更，通常是一個對使用者毫無價值（實際上是負價值，因為這樣做會增加總工作量與載入頁面所需的總時間）的載入畫面，然後他們會小心避免做出任何大到足以讓之後的任何變更被標記為 LCP 的更新。

基於與福斯汽車不會公開討論其如何操弄排放數據相同的原因，開發者往往會避免在公開場合討論這類 LCP 最佳化。這方面的例外是 Discourse，他們公開宣布了這類 LCP 最佳化，並有來自其開發者與時任 CTO（現任 CEO）的留言，指出他們新的「Discourse Splash」功能如何在部署後大幅降低了網站的 LCP。而當開發者詢問為何他們的 LCP 很高時，Discourse 開發者的標準建議是讓元素保持小於「Discourse Splash」，以便讓 LCP 的時間戳記是從這個為最佳化 LCP 而丟出來的無用元素計算，而非從任何與使用者相關的實際元素計算。這裡是一則典型的、來自 Discourse 官方的留言

如果你的橫幅比我們用於「Introducing Discourse Splash - A visual preloader displayed while site assets load」的元素還要大，你的 LCP 肯定會很慘。

來自 Discourse 的官方回應是，你應該確保你的內容不會觸發 LCP 的測量，而是讓我們的載入動畫時間戳記被用來計算 LCP。

在有用內容的 LCP 與 Chrome 所測得的 LCP 之比最極端的網站是：

• Wix
  • M3：6
  • M1：12
  • Tecno Spark 8C：3
  • Itel P32：N/A (FAIL)
• Discourse：
  • M3：10
  • M1：12
  • Tecno Spark 8C：4
  • Itel P32：N/A (FAIL)

雖然我們尚未討論對其他指標的操弄，但看起來有些網站也在操弄其他指標，並在即使對使用者毫無益處的情況下「最佳化」它們。

附錄：為網站做最佳化的自利理由

這會取決於網站的規模與其效能，但在我曾任職的大型公司中檢視這些數據時，改善網站與 App 的效能所帶來的價值高得驚人。這在 A/B 測試中是可測量的，而且在長期保留對照組中，它也是對成長與留存影響相對較大的介入措施之一（許多介入措施在短期測試中看起來不錯，但長期來看就沒那麼好，而效能改善往往在長期看起來更好）。

當然你可以從直接的數字中看到這點，但當你檢視數據時，也能從許多面向間接看到這點。舉例來說（就舉一個例子），在 Twitter，使用者實際感受到的 p99 延遲在印度以及許多非洲國家（即使排除像埃及和南非這類相對富裕的國家）約為 60s，在美國也約為 60s。當然，就整體人口而言，美國人的裝置與連線速度更快，但在每個國家，都有足夠多擁有慢速裝置或連線的使用者，使得真正的限制因素其實是使用者的耐心，而非裝置與連線在人口層面的基礎分布。即使你不在乎奈及利亞或印度的使用者，只在乎美國的廣告營收，為低階裝置與連線改善效能所帶來的影響，仍大到足以在全球以及美國營收的 A/B 測試中，特別是在長期保留對照組中，清楚地被觀察到。而你也能在擁有快速裝置的使用者身上看到影響，因為一個將「低階」裝置使用者的延遲從 60s 改善到 50s 的變更，可能會將高階裝置使用者的延遲從 5s 改善到 4.5s，這對營收、成長與留存數據同樣會產生影響。

基於超出本文範圍的各種原因，這類枯燥、但可量化且能推動成長與營收的工作，在我曾任職的大多數大型公司中，相較於那些最終在長期保留對照組中顯示幾乎沒有影響的炫目產品工作，往往更難獲得資金支持。

附錄：為低效能裝置設計

在使用慢速裝置或任何頻寬低、連線品質差的裝置時，體驗最好的往往是一次載入大量內容到靜態頁面中的那種。如果圖片有正確的寬度與高度屬性以及替代文字，那會非常有幫助。漸進式圖片（如 progressive jpeg）並沒有特別大的幫助。

在擁有高頻寬的慢速裝置上，任何輕量的靜態頁面都能運作良好，而輕量的動態頁面如果為效能而設計，也能運作得不錯。笨重的動態頁面則注定失敗，除非頁面的重量沒有導致頁面變得複雜。

在頻寬低、連線品質差的情況下，輕量頁面是沒問題的。對於笨重的頁面，我體驗過最好的方式是觸發一次頁面載入，然後去做別的事，等完成後（或至少 HTML 與 CSS 完成後）再回來。然後我可以把每個想看的連結都在新分頁中開啟，再去做別的事，同時等待它們載入。

許多現代網站在做的最佳化，例如在你往下捲動時分段載入、並因此劫持搜尋功能（因為如果頁面尚未完全載入，瀏覽器內建的搜尋就毫無用處），會讓這種有效的互動模式失效，使頁面變得非常難以互動。

舉例來說，不少人提到 Substack 對他們來說效能很差，因為它會分段載入頁面。這裡有一段由 @acidshill 拍攝的影片，展示在 iPhone 8 上載入一篇 Substack 文章後再捲動的情況，其中該貼文的 LCP 相當快，但如果你想捲過標題，就必須等待 6s 讓下一段頁面載入，然後再次捲動時，又得再等個 1s 到 2s：

作為相反做法的例子，我嘗試載入了一些相當大的純 HTML 頁面，例如 https://danluu.com/diseconomies-scale/（0.1 MB wire / 0.4 MB raw）和 https://danluu.com/threads-faq/（0.4 MB wire / 1.1 MB raw），即使在慢速裝置上，這些頁面對我來說依然相當可用。1.1 MB 看起來比最佳大小還大，將其拆成幾個不同的頁面在低階裝置上會更好，但單一頁面有 1.1 MB 的文字，在慢速裝置上的表現仍遠比大多數現代網站好。雖然當 HTML 頁面大到瀏覽器難以處理時確實會出問題，但對於內容量正常的頁面，通常要到出現複雜的 CSS 負載或 JS 時，頁面才會開始對慢速裝置造成問題。下面我們測試了一些相對簡單的頁面，其中有些包含不少媒體（在一種情況下有 14 MB），發現只要保持簡單，這些頁面運作起來都還算可以。

Chris Adams 也提到，失明使用者在使用螢幕閱讀器時，經常反映動態載入讓體驗變得更糟。就像為了改善效能而做的動態載入一樣，雖然這可以做得很好，但往往要不是做得很差，就是與太多其他複雜度綁在一起，導致結果比簡單的頁面還要糟。

@Qingcharles 提到了另一個無障礙問題——他所協助的（監獄）假釋者會拿到「lifeline」手機，這些手機往往是非常低階的裝置。快速搜尋一下，在 2024 年，有些人會拿到 iPhone 6 或 iPhone 8，但也有不少裝置比 Itel P32 更低階，更不用說 Tecno Spark 8C 了。他們拿到的方案流量也極為有限，當流量用完後，有些人就「無法填寫任何求職、福利申請表格，也無法用 Maps 導航」。

對於那些確實做了前置工作並在低階裝置上提供了不錯體驗的網站，Andy Kelley 指出了一個在慢速裝置上似乎運作良好的前置工作範例，Zig 標準函式庫文件：

我做了一個有爭議的決定，讓它在前端就抓取所有原始碼，然後在本地完成所有內容的算繪。理論上，這是 CPU 密集的工作，但在實務上…… 即使是那些舊手機也有非常快的 CPU！

在 Tecno Spark 8C 上，這會使用 4.7s 的 CPU，之後的反應則相當靈敏（相對於該裝置而言——當然 iPhone 的反應要快得多。點擊連結能相當快地載入，捲動也運作正常（有點卡頓，但在這台裝置上幾乎沒有什麼是真正流暢的）。這似乎就是人們在說可以透過發送較重的負載來獲得更好效能時所指的那種情況，但在低階裝置上真正能改善效能的例子並不多。

附錄：關於網頁效能問題的文章

• 2015：Maciej Cegłowski：The Website Obesity Crisis
  • 大小：1.0 MB / 1.1 MB
  • Tecno Spark 8C：0.9s / 1.4s
    • 捲動有點卡頓，如果非常快速地捲動（從頂端一次跳到頁面中間），圖片會需要一點時間才出現，但以正常距離捲動時，延遲低於幾乎任何使用者能感知的程度。
• 2015：Nate Berkopec：Page Weight Doesn't Matter
  • 大小：80 kB / 0.2 MB
  • Tecno Spark 8C：0.8s / 0.7s
    • 有做延遲載入，如果你把整個頁面捲完，頁面會下載 650 kB / 1.8 MB，但捲動只有一點點卡頓，延遲載入並未造成延遲。這大概是我在實際環境中看過唯一一個以讓慢速裝置體驗變好而非變差的方式實作延遲載入的頁面；我沒有在慢速連線下測試，在那種情況下這仍會讓體驗變差。
  • Itel P32：1.1s / 1s
    • 捲動基本上無法使用；捲動極度卡頓且移動距離隨機，捲到新文字時經常需要超過 1s 文字才會算繪出來；對於延遲載入的圖片情況可能更糟。即使這是我在實際環境中看過最好的延遲載入實作，Itel P32 依然無法應付。
• 2017：Dan Luu：How web bloat impacts users with slow connections
  • 大小：14 kB / 57 kB
  • Tecno Spark 8C：0.5s / 0.3s
    • 捲動與互動運作正常。
  • Itel P32：0.7s / 0.5 s
• 2017-2024+：Alex Russell：The Performance Inequality Gap (series)
  • 大小：82 kB / 0.1 MB
  • Tecno Spark 8C：0.5s / 0.4s
    • 捲動與互動運作正常。
  • Itel P32：0.7s / 0.4s
    • 捲動與互動運作正常。
• 2024：Nikita Prokopov (Tonsky)：JavaScript Bloat in 2024
  • 大小：14 MB / 14 MB
  • Tecno Spark 8C：0.8s / 1.9s
    • 捲動時，圖片需要一段時間（約 500ms）才會顯示，捲動也不夠流暢，但還不至於卡到難以捲到正確位置。
  • Itel P32：2.5s / 3s
    • 捲動不流暢。要精準捲動有點困難，但如果非常小心，還是大致能捲到想要的位置。捲動較大距離時，通常需要超過 1s 新內容才會出現。
• 2024：Dan Luu：This post
  • 大小：25 kB / 74 kB
  • Tecno Spark 8C：0.6s / 0.5s
    • 捲動與互動運作正常。
  • Itel P32：1.3s / 1.1s
    • 捲動與互動運作正常，雖然我為了達到這樣而做了一個修改——本文原本內嵌了一段影片，Itel P32 根本無法好好處理。
      • 請注意，雖然這些數字比「Page Weight Doesn't Matter」那篇的數字還差，但這個頁面在載入後是可用的，而另一篇頁面則因為執行了某種對這支手機來說過於複雜的延遲載入而無法使用。
        

附錄：對非富裕使用者的同理心

隨著程式設計變得越來越有聲望、收入也越來越高，我長期觀察到的一個現象是，人們往往來自更富裕的背景，也較少接觸不同收入階層的人。我們之前討論過的一個例子，是在一家知名、具聲望且員工普遍左傾的新創公司，每個人都變得富有後，在一次關於疫情紓困支票的 Slack 討論中，一位出於善意的進步派員工說，紓困支票根本沒用，因為人們只會拿去買股票。這個人顯然從未與任何中產階級（更不用說貧窮）的人談論過他們的錢都花到哪裡去，或看過關於誰持有股票的數據。而這還只是看美國的財富狀況。當我們放眼全球財富時，大家的理解程度就更低了。人們似乎真的低估了世界各地財富與所得的動態範圍。從我與不少人的對話中，許多人腦中似乎只有「以美國標準來看的窮」（會拿紓困支票去買股票）和「以世界標準來看的窮」（也許根本不買股票）這兩個桶子，但世界上的貧窮範圍，遠遠超越美國貧窮的範圍，其程度是許多富裕的程式設計師所未能意識到的。

舉個例子，在這場關於我父母能來到美國在財務機會上有多幸運的討論中，有人提到這沒什麼大不了，因為他們在波蘭也有很好的財務機會。一方面，就討論的主題——一個人最終能獲得高薪程式設計工作（在高薪科技公司擔任資深 Staff 工程師）或同等機會的機率——我懷疑在我出生時，在美國當窮人出生的機率，可能比在波蘭當相對富裕的人還要好，但如果有人拿出數據證明相反的情況，我也能接受。但如果我們要比較的是波蘭 vs. 美國，與越南 vs. 美國的情況，如果我花 15 秒快速查一下這些國家在我出生那年的大致財富數字，美國 : 波蘭的人均 GDP 比約為 8:1，而波蘭 : 越南則約為 50:1。波蘭與越南之間的財富差距，大約是美國與波蘭差距的平方，所以波蘭對越南的差距，大致相當於波蘭與某個比美國比波蘭富有程度還要再富有的假想國家之間的差距。這些情況根本無法相提並論，但許多人腦中的模型似乎是只有「富裕國家」和「不富裕國家」，而「不富裕國家」全都被歸在同一個桶子裡。人均 GDP 並非理想指標，但它比百分位所得統計更容易找到；我快速搜尋時也發現，當時越南的年所得大約是每年 200 到 300 美元。越南當時也正經歷一場饑荒的尾聲，其影響有點難以判定，因為這方面的統計數據似乎被動過手腳，但如果你相信死亡率統計數據，饑荒導致總體死亡率飆升至正常基線的兩倍¹。

當然，在當時，低所得國家的中位數人口根本不會有電腦，更不用說能上網了。但是，今天低所得國家的人們擁有裝置已是相當普遍的事。許多人似乎要不是沒有意識到這點，就是不理解這些人中有許多人使用的是什麼樣的裝置。

附錄：來自 Fabian Giesen 的留言

關於 Discourse 創辦人對 iOS vs. Android 市占率的言論，Fabian 提到

在美國，根據我能找到的最新數據（2023 年），iPhone 的市占率約為 60%。在歐盟，則約為 33%。這會帶來連帶效應。iOS 使用者不僅偏向較富裕的族群，也偏向美國。

這也帶來一些次級效應。例如，在美國，iMessage 在群組聊天等方面非常受歡迎，而且眾所周知它與 Android 裝置的互通性非常差，讓 Android 使用者的體驗非常惱人（幾乎可以肯定是故意的）。

在歐盟，至少部分因為 Android 更為普及，iMessage 就沒那麼受歡迎；據我所知，即使在我認識的 iPhone 使用者中，那些在美國可能會用 iMessage 的人，也往往改用 WhatsApp。

重點是，以全球來看，近期 iOS 加上快速網路的組合，比許多在美國的 App 開發者所意識到的，還要更偏向某一特定族群。

而關於行動 App vs. 網頁 App 大小的留言，Fabian 說：

再從經驗補充一點：App 是在你安裝時就下載好的，而且通常有機會在你處於慢速或計量制連線時（或根本沒有數據時）暫緩更新。

回想我當初剛拿到美國手機時，因為沒有美國信用紀錄而只能使用預付方案。我到現在還在用，因為對我平時實際使用手機的方式來說已經夠用了，但這確實意味著我每年去德國一次時，完全無法使用數據漫遊。（而且，在德國打電話一通要花我 1.50 美元，即使 T-Mobile 是德國最大的行動電信商——當然，不是 T-Mobile US。）

重點是，我在 T-Mobile 熱點（例如主要火車站、機場等）以及有提供熱點的城際列車上確實能用到免費且快速的 Wi-Fi，但在德國時我實際上完全沒有數據方案。

這對於那些可離線運作並在有連線時同步資料的手機 App 來說完全沒問題。但網頁 App 在我不在公共 Wi-Fi 附近時就完全無法使用。

同樣地，我很樂意透過 Gmail App 在慢速的計量制連線下寄一封電子郵件，但我絕對不會在計量制連線下使用任何需要下載幾 MB 壓縮後 JS 才能做任何事的網頁版郵件用戶端。

至少對於原生 App 的下載，我可以預先準備，在有良好網路的地方先下載好！

Fabian 的另一則留言（這次是轉述自一段對話）是，人們常常會因為某件事在質性上應該要慢，就為其在量性上極度緩慢而辯護。他舉的一個例子是螢幕經常需要很長時間來同步連線，而這被辯護為因為有必須執行的操作需要時間。長期以來，這些操作往往需要數秒。最近，許多顯示器同步得快得多，因為 Nvidia 對「G-Sync」認證規定了這段時間的上限，所以顯示器製造商現在實際上會在合理的時間內完成這件事。雖然確實有必須執行的操作需要時間，但並沒有根本性的理由讓它們需要花費過去那種動輒數秒的時間。他舉的另一個例子是，有人為讀取數千個檔案需要很長時間辯護，理由是該操作需要大量 syscall 而「syscall 很慢」，這在質性上是正確的說法，但如果你去看 syscall 的實際成本，在當時討論的案例中，syscall 的成本與足以合理說明為何讀取數千個檔案需要那麼久的成本，差距了好幾個數量級。

關於這個主題，當有人指出某個現代網站很慢時，通常會有人以質性的辯護回應，說現代網站擁有舊網站所缺乏的那些很棒的功能。雖然（例如）Discourse 確實擁有 MyBB 所沒有的功能，但很難主張其功能集足以合理化 33x 的緩慢。

附錄：實驗細節

除了 danluu.com 以及勉強可算的 HN 之外，對於每個網站，我都試圖找到「最預設」的體驗。舉例來說，對於 WordPress，這意味著使用當前預設主題 twentytwentyfour 的示範部落格。在某些情況下，這可能不是今天最常見的使用情境，例如對於 Shopify，我查看的是在瀏覽其主題時他們給你的第一個主題，但我並未嘗試尋找主題數據來確認哪個主題最常被使用。對於本文，我希望將所有資料收集與分析作為一個短期的專案，在不到一天內完成，因此採取了許多像這樣的捷徑，細節將在下方說明。我認為使用第一個呈現的 Shopify 主題並沒有錯，因為有相當比例的使用者可能會使用第一個呈現的主題，但這當然不如抓取最常見的主題、再測試許多使用該主題的不同實際網站、來觀察人們為自身用途修改主題時真實效能的差異來得有代表性。如果我在 Shopify 工作或想為競爭對手做競品分析，我會那樣做，但對於一個關於大型網站在低階裝置上對使用者影響的一日專案而言，這裡所展示的 Shopify 效能似乎已經足夠。我其實是在二月進行這些民調前後完成這份工作的初期作業的，只是直到一個月後才有時間真正把這些內容整理成文。

對於筆電上的測試，我盡量讓筆電電量維持在約 60%、未插電，並讓筆電閒置足夠長的時間以在 20°C 的房間內回到熱平衡狀態，因此頁面不應受到先前頁面載入或其他先前在機器上執行的作業的影響。

對於行動裝置測試，手機電量約為 100% 且插著電，並且先前也處於 100% 電量，因此手機不會有因快速充電而產生的發熱效應。如上所述，這些測試是在 1Gbps WiFi 下進行。沒有其他 App 在執行，瀏覽器沒有開啟其他分頁，裝置上也只安裝了必要的 App，因此除了裝置預設會執行的背景工作之外，不應有額外的背景任務在執行。實際使用者在相同裝置上看到的效能，在幾乎所有情況下都會比我們這裡測得的更差，除非在手機上執行 Chrome 開發者工具會顯著降低效能。我注意到，在 Itel P32 上，開啟開發者工具時的捲動比正常執行時還要卡頓一些，但由於這是一個一日專案，我並未嘗試量化這點，以及它是否對某些網站的影響遠大於其他網站。就絕對值而言，開銷不可能太大，因為最快的幾個網站在開啟開發者工具的情況下依然相當快速，但如果存在某種與網站工作量呈超線性關係的開銷（可能是間接地，如果它導致某種資源耗盡），那麼這可能會對某些網站的測量造成問題。

所有大小都是在行動裝置上測量的，因此在行動版與桌機版載入不同資源的情況下，我們測量的是行動版資源的大小。CPU 是以主執行緒上的 CPU 時間來測量（我也有記錄使用其他執行緒的網站在其他執行緒上的時間，但未使用該數據；如果 CPU 是人們想要操弄的指標，就必須將其他執行緒上的時間也納入計算，以防止網站試圖將盡可能多的工作卸載到其他執行緒，但目前這並非問題，而且主執行緒上的時間與可用性的相關性比所有執行緒總和時間更高，而那個能防止作弊的指標在目前沒有好處的情況下可讀性也較差）。

對於 WiFi 速度，測速結果如下：

• M3 Max
  • Netflix (fast.com)
    • 下載：850 Mbps
    • 上傳：840 Mbps
    • 延遲（無負載 / 有負載）：3ms / 8ms
  • Ookla
    • 下載：900 Mbps
    • 上傳：840 Mbps
    • 延遲（無負載 / 下載 / 上傳）：3ms / 8ms / 13ms
• Tecno Spark 8C
  • Netflix (fast.com)
    • 下載：390 Mbps
    • 上傳：210 Mbps
    • 延遲（無負載 / 有負載）：2ms / 30ms
  • Oookla
    • Ookla 網頁 App 失效，無法看到結果
• Itel P32
  • Netflix
    • 下載：44 Mbps
    • 上傳：測試無法運作（只送出一塊資料後就卡住，不再送出任何資料）
    • 延遲（無負載 / 有負載）：4ms / 400ms
  • Okta
    • 下載：45 Mbps
    • 上傳：測試無法運作
    • 延遲：測試無法顯示延遲

值得注意的一點是，Itel P32 實際上並沒有能力使用它名目上擁有的頻寬。查看排名最前面的 Google 評測，沒有任何一篇提到這點。第一篇評測寫道

就效能而言，這支手機不會卡頓。它搭載最新的 Android 8.1（GO Edition）…… 我們有 8GB+1GB 的 ROM 與 RAM，搭配 1.3GHz 四核心處理器以便輕鬆多工…… 我對 P32 上的功能印象深刻，特別是考慮到它的價格。對於那些總是在外奔波的人，我會推薦它。而對於那些將智慧型手機的電池續航力視為第一優先的人，那麼 P32 就是你的最佳選擇。

第二篇評測寫道

Itel mobile 是非洲排名前幾的分銷商之一，在全非洲排名第三…… 輕量作業系統的表現符合我們的期待，在 1GB RAM 的裝置上沒有遲緩現象…… 相當快速的處理速度…… Itel P32 智慧型手機的效能超越了其能力所及…… 以高達 UGX 330,000 的價格標籤來看，Itel P32 是那些驚人的低階智慧型手機之一，值得被掛上中階的旗幟，因為它在單一包裝中嵌入了驚人的功能。

第三篇評測寫道

「遠不僅僅是一支預算型入門智慧型手機…… 我們使用兩週後的完整評測…… 在應用程式之間切換以及瀏覽較重的網頁時，效能是最佳的。當多個 App 在背景執行、同時玩遊戲時，有少數卡頓。然而，整體效能對於大多數手機使用者來說是平均水準，對於一般使用者來說是最好的[遊戲截圖] 即使遊戲會跳過一些影格並自動降低圖形細節，如果沒有其他 App 在手機上執行，速度還是快得多。

關於網站的備註：

• Wix
  • www.wix.com/website-template/view/html/3173?originUrl=https%3A%2F%2Fwww.wix.com%2Fwebsite%2Ftemplates%2Fhtml%2Fmost-popular&tpClick=view_button&esi=a30e7086-28db-4e2e-ba22-9d1ecfbb1250：這是我點擊取得主題時出現的第一個項目
  • 在每台裝置上 LCP 都具有誤導性
  • 在 Tecno Spark 8C 上，捲動從來沒有真正正常運作過。非常卡頓且從未穩定下來
  • 在 Itel P32 上，頁面會非確定性地失敗（不同次載入出現不同錯誤）；可能需要相當長的時間才會報錯；在第一次執行時是 23s，CPU 滿載 28s
• Patreon
  • www.patreon.com/danluu：在可行的情況下使用我的個人頁面
  • 在 Patreon 上捲動並尋找舊貼文是如此痛苦，以至於我自己維護了一個我的 Patreon 貼文索引，以便不用透過 Patreon 也能找到舊貼文。雖然 Patreon 在表格中的數據在快速筆電上看起來沒有那麼糟，但那只是初始載入的情況。隨著你捲動時的效能之差，我認為今天已不存在任何電腦與網路組合能以不錯的效能瀏覽 Patreon。
• Threads
  • threads.net/danluu.danluu：在可行的情況下使用我的個人頁面
  • 在 Itel P32 上，這在技術上沒有正確載入，可以被標記為 FAIL，但已接近到我將其計為成功。錯誤之處在於個人頭像周圍有一個方形外框
    • 然而，如同其他笨重的頁面，與頁面互動實際上無法運作，頁面也無法使用，但這似乎是出於標準的效能原因，而非因為頁面未能算繪
• Twitter
  • twitter.com/danluu：在可行的情況下使用我的個人頁面
• Discourse
  • meta.discourse.org：這是搜尋官方論壇時找到的結果。
  • 如上所述，LCP 被高度操弄，基本上毫無意義。我們連結到一篇 Discourse 團隊提到他們在慢速載入時會在 2s 時放上一個巨大的啟動畫面以將 LCP 上限設為 2s 的文章。另一個值得注意的是，在比 2 秒更快的載入中，LCP 也被高度操弄。例如，在搭配低延遲 1Gbps 網路的 M3 Max 上，LCP 被回報為 115ms，但頁面實際內容是在 1.1s 時才載入。這似乎使用了與「Discourse Splash」相同的根本技巧，也就是在螢幕上繪製一個巨大的變更，然後小心地載入較小的元素，以避免讓實際頁面內容被偵測為 LCP。
  • 在 Tecno Spark 8C 上，捲動不可預測且可能跳得太遠，觸發無限捲動的載入，導致頁面卡住 3s-10s。此外，如果只是讓瀏覽器在該頁面上靜置一段時間，整個瀏覽器有時會當掉。
  • 在 Itel P32 上，7.5s 後會顯示錯誤訊息
• Bluesky
  • bsky.app/profile/danluu.com
  • 在 Itel P32 上顯示空白畫面
• Squarespace
  • cedar-fluid-demo.squarespace.com：這是我點擊主題以取得主題時出現的第二個主題；第一個是名為「Bogart」的主題，但那基本上是一個沒有內容的「即將推出」單頁畫面，所以我改用了第二個而非第一個。
  • 在 Itel P32 上主控台中有大量錯誤與警告，但頁面似乎能載入並運作，儘管與其互動相當緩慢且痛苦
  • 在 Tecno Spark 8C 上的 LCP 明顯早於頁面內容實際載入的時間
• Tumblr
  • www.tumblr.com/slatestarscratchpad：使用這個是因為我知道這個 tumblr 存在。我並不常看很多 tumblr（大概三、四個），而這個看起來是最接近我在 tumblr 上部落格的例子。
  • 此頁面在 Itel P32 上會失敗，但並未被標為 FAIL。主控台顯示 JavaScript 發生錯誤，但頁面仍能正常運作（我嘗試了捲動、點擊連結等，這些都正常），所以你實際上可以前往想要的貼文並閱讀它。JS 錯誤似乎讓此頁面的載入速度比原本快得多，也讓載入後與頁面的互動變得相當輕快。
• Shopify
  • themes.shopify.com/themes/motion/styles/classic/preview?surface_detail=listing&surface_inter_position=1&surface_intra_position=1&surface_type=all：這是我尋找主題時出現的第一個主題
  • 在第一次 M3/10 執行中，Chrome 開發者工具回報了不合理的 697s CPU 時間（該次執行在正常時間內完成，遠低於 697s 甚至 697/10s。此筆執行在計算結果時被忽略。
  • 在 Itel P32 上，頁面載入永遠無法完成，只顯示一個由主題刻意載入的閃爍游標狀圖像。在能正常載入的裝置上，該閃爍游標圖像會立即被另一張圖片覆蓋，但在這裡從未發生。
  • 我曾想過使用這個範例主題是否不公平，因為頁面上有些可讓你切換主題樣式的東西，所以我檢查了該主題的實際使用案例（宣傳該主題的頁面列出了使用者）。我嘗試了列出的前兩個真實範例，它們都比這個示範頁面慢得多。
• Reddit
  • reddit.com
  • 相較於頁面變得可用所需的時間，其 LCP* 異常地低。雖然未在此測試中測量，但我一般發現該頁面在 Intel Macbook 上也很慢且有點難用，而以歷史標準來看，Intel Macbook 已是極快的電腦（除非我使用 old.reddit.com）
• Mastodon
  • mastodon.social/@danluu：在可行的情況下使用我的個人頁面
  • 在 Itel P32 上無法載入，只給你一個空白畫面。由於在 Itel P32 上所有事情通常都很慢，一段時間內很難判斷頁面是失敗還是只是慢
• Quora
  • www.quora.com/Ever-felt-like-giving-up-on-your-dreams-How-did-you-come-out-of-it：我嘗試用 google 搜尋 quora 加上我聽說現在在 Quora 上很活躍的某位 metafilter 使用者的名字。Google 並未回傳其個人頁面，而是回傳了這個頁面，該頁面似乎與我搜尋的使用者毫無關係。因此，這與社群媒體個人頁面無法相比，但從 Google 得到一個隨機且無關的 Quora 結果正是我與 Quora 互動的典型方式，所以我想這算是代表了我的 Quora 使用情況。
  • 在 Itel P32 上，頁面在某個時間點停止執行腳本且未完全載入。這導致它無法正確顯示。與頁面的互動也無法真正運作。
• Substack
  • 使用 thezvi.substack.com，因為我知道 Zvi 有一個 substack 且寫作主題相似。
• vBulletin：
  • forum.vbulletin.com：這是搜尋官方論壇時找到的結果。
• Medium
  • medium.com/swlh：我在 Medium 上沒有閱讀任何東西，所以我用 google 搜尋 Medium 上的程式設計部落格，這是排名最高的結果。從主題來看，它似乎不是特別重或特別客製化的 Medium 部落格。由於它似乎被廣泛閱讀且受歡迎，它比這裡的其他一些部落格更有可能從 CDN 提供服務。
  • 在一次非基準參考執行的測試中，在 Itel P32 上，我在載入頁面後 35 秒嘗試捲動。捲動的延遲為 5s-8s，且捲動的距離不可預測，使得頁面完全無法使用。這在表格中未被標記為 FAIL，但可以主張這應該算 FAIL，因為頁面已無法使用。
• Ghost
  • source.ghost.io 因為這是目前預設的 Ghost 主題，也是我找到的第一個範例
• Wordpress
  • 2024.wordpress.net 因為這是目前預設的 wordpress 主題，這是我找到的第一個範例
• XenForo
  • xenforo.com/community/：這是搜尋官方論壇時找到的結果
  • 在 Itel P32 上，版面配置嚴重錯誤，頁面內容彼此重疊。由於這樣，無法以合理的方式與想要的元素互動，閱讀文字也需要閱讀被重複疊印多次的文字。
• Wordpress (old)
  • 使用 thezvi.wordpress.com，因為它擁有與 Zvi 的 substack 相同的內容，且恰好使用某個舊的 wordpress 主題，該主題曾經是非常常見的選擇
• phpBB
  • www.phpbb.com/community/index.php：這是搜尋官方論壇時找到的結果。
• MyBB
  • community.mybb.com：這是搜尋官方論壇時找到的結果。
  • 網站沒有提供行動版。一般來說，我發現在慢速裝置上，網站的桌機版明顯比行動版更好用，所以這運作得相當好，儘管他們很可能因此被 Google 扣分。
• HN
  • news.ycombinator.com
  • 原則上，HN 應該是最慢的社群媒體或連結聚合網站，因為它是用一種未經高度最佳化的客製 Lisp 寫成的，且程式碼最初是以簡潔與巧妙為目標撰寫的，這通常會帶來相當差的效能。然而，這只是相對於你若要寫高效能程式碼時會得到的效能而言，而這在這裡並非相關的比較基準。
• danluu.com
  • 不言自明
  • 目前這個頁面使用的 CPU 比 HN 還少一點，但我預期這個頁面最終會使用更多 CPU，因為主頁面會持續成長。目前，這個頁面有 176 個連結指向 168 篇文章，而 HN 則有 199 個連結指向 30 篇文章，但除非發生不幸的意外，這個頁面的連結數最終應該會超過 HN。
    • 如上所述，我發現對於這種小頁面來說，分頁會讓在慢速裝置或連線不佳情況下的瀏覽體驗變得更差，所以我不想透過將其分頁或更糟地做某種捲動時動態載入內容來「最佳化」它。
• Woo Commerce
  • 我原本也有測量 Woo Commerce，但與上面測試的頁面與平台不同，我並未發現其在初始載入時是快是慢，就必然能代表其他操作的後續效能，因此未將其納入表格，因為將其放入表格有點像是要求與 Shopify 做比較。特別是，雖然我能找到的「最預設」Woo 主題在慢速裝置上的初始載入明顯快於「最預設」的 Shopify 主題，但在慢速裝置上很容易找到 Shopify 比 Woo 快以及 Woo 比 Shopify 快的現實情境，這與我所觀察到的較新的部落格平台如 Substack 和 Medium 相較於較舊平台如 Wordpress，或現代論壇如 Discourse 相較於較舊的 PHP 論壇的情況相當不同。對於擁有購物車、結帳流程等的購物網站的真實比較，需要對這些網站的實際使用情況有比我在一日內能獲得的更深入理解。
• NodeBB
  • community.nodebb.org
  • 這不在我最初的測試中，我只是因為 NodeBB 的一位創辦人建議才嘗試，他說：「我很想看看 @[email protected] 在你的測試中表現如何。這些年來我們花了相當多時間讓它變得非常快，我個人認為它至少在速度與初始負載方面，比 Discourse 更能代表現代論壇軟體。」
  • 我沒有做完整的測試，因為我沒有讓 Itel P32 保持充電（電池狀況不佳，一旦拔掉插頭就會很快放電，所以我得等相當長一段時間才能讓它回到充電狀態）
  • 在我做的測試中，它在 M1 上得到 0.3s/0.4s，在 Tecno Spark 8C 上得到 3.4s/7.2s。這比 vBulletin 稍慢，比那些較快的 php 論壇慢上許多，但比 Discourse 快得多。如果你因某些原因需要一個「現代」論壇，又希望你的論壇能讓那些以全球標準來看並不富有的人也能使用，這似乎是可行的。
  • 另一個值得注意的地方是，鑑於它是個「現代」網站，初始載入後的互動運作正常；你可以捲動和點擊東西，這些大致上都能正常運作，沒有當掉等情況。
  • 大小為 0.9 MB / 2.2 MB，因此對於一個「現代」網站來說也算是相當輕量，或許在慢速連線下也能使用，儘管在此並未測試慢速連線。

另一種測試方式是嘗試將頁面配置得盡可能相似。如果有人做了那樣的測試，我會很想看看結果，但那種測試會耗時得多。一方面，它需要客製化每個網站。另一方面，它需要決定網站應該長什麼樣子。如果你測試像 danluu.com 這類的頁面，每個能讓你直接從 CDN 提供輕量內容的平台，像 Wordpress 和 Ghost，應該都會得到相似的分數，分數取決於 CDN 與 CDN 快取命中率。像 Medium 和 Substack 這類客製化程度相對較低的網站，分數則會與此處大致相同。實際上，從觀察現有網站來看，大多數使用者建立的網站會比 Wordpress 和 Ghost 的「最預設」主題更慢，儘管這個部落格的讀者平均來說可能會相反，所以你大概會想測試各種不同的網站樣式。

附錄：本站 vs. 在慢速裝置或慢速連線上無法運作的網站

順帶一提，我覺得很有趣的一件事是，我長期以來收到不少關於此頁面樣式的仇恨信（以及數量相近的感謝信）。所謂仇恨信，我指的不是客氣地建議修改，而是等同於路怒，但發生在網頁瀏覽上；可稱之為網頁路怒。我認識一些經營複雜到讓世界上相當大比例的人無法使用的網站的人。為什麼人們會對本站的樣式如此憤慨，而相對地，幾乎完全不在乎網路對那麼多人來說無法使用的事實呢？

另一個有趣的地方是，那些欣賞此樣式的人，通常欣賞的是本站沒有覆寫任何預設樣式，讓你可以透過設定視窗大小來讓寬度完全符合你想要的樣子，也不會覆寫你套用到網站上的任何預設樣式。那些對此非常堅持的人希望每個人都有他們偏好的某種寬度限制、他們偏好的某種字體等，但這總是以一種彷彿他們不是為自己要求，而是為了大眾利益的方式來表述，儘管迎合這些網頁路怒者的偏好會直接與那些（舉例來說）偏好透過調整視窗寬度來調整文字寬度的人的偏好相衝突。

在我指出數十次之前，這類對話通常會以網頁路怒者告訴我「研究顯示」較窄的文字寬度客觀上更好作為開頭，但在閱讀我能找到的關於此主題的每一篇研究後，我並未發現情況如此。此外，在要求提供引文時，很明顯說這些話的人根本沒有讀過任何相關研究，有時還會倉促地寄給我一篇他們似乎沒有讀過的研究。當我指出這點後，人們就會將論點改為研究無法真正描述這個問題（奇怪的是他們一開始還引述研究），雖然有一人向我引用了一本書（我讀了，而他顯然沒讀，因為那本書同樣不支持他的論點），然後轉而主張這就是每個人想要的，即使從我收到的意見以及我從做出改變時所擁有的數據來看，顯然並非如此。

有這種推理方式的網頁路怒者似乎無法吸收「他們的偏好並非普世」這個資訊，並會堅持認為無論人們說自己喜歡什麼，他們的說法才是對的，這點我覺得相當有趣。就數據而言，當我從 Octopress 樣式（當時程式設計部落客最流行的樣式）切換到目前的樣式時，我得到了看似因果關係的流量與參與度提升，所以看來不僅是寫感謝信給我、喜歡此樣式的人喜歡這個樣式，整體上那些不會寫信給我的人的感受似乎也是本站沒問題，而且顯然比標準的程式設計師部落格樣式更受歡迎。當我提到這點時，人們往往會更加堅持認為他們的偏好是普世的，並認為那些自認有其他偏好的人是錯的，並回覆一些完全無稽的內容。

要說清楚，我當然不會聲稱本站的設計是最佳的。我只是移除了當時程式設計師最流行的部落格平台中最受歡迎的 CSS，因為那個 CSS 對低階連線的使用者來說客觀上很糟，而作為副作用，整體流量與參與度反而增加，不僅僅是來自那些傾向擁有較低階連線與裝置的地區的流量。毫無疑問，一位關心低階連線與裝置使用者的設計師可以做得更好，但在這個議題上的不誠實與激烈言辭，確實有些奇怪。