Smashing Podcast 第 34 集與 Harry Roberts：Web 性能狀況如何？

在本集中，我們將討論 Web 性能。 2021 年的業績前景如何？ 我與專家哈里·羅伯茨（Harry Roberts）進行了交談以找出答案。

顯示註釋

Harry 將於 2021 年 5 月與 Smashing 一起舉辦一個 Web 性能大師班研討會。在發佈時，仍然可以享受大早鳥折扣。

• 哈利在推特上
• Harry 的諮詢網站 CSS Wizardry
• 視頻課程我為快速製作 CSS 魔法所做的一切，包括15% 的折扣
• 顧問電子書的問題，包括15% 的折扣
• Web Vitals 的 Web.dev 指南
• 德魯最喜歡的 OXO GoodGrips 打蛋器

每週更新

• 2021 年網頁設計趨勢：Suzanne Scacca 撰寫的報告
• 在由 Fortune Ikechi 編寫的 React 應用程序中使用 Grommet
• 如何為以太坊區塊鏈構建 Node.js API 由 John Agbanusi 編寫
• 我們如何改進 SmashingMag 性能 作者 Vitaly Friedman
• 何時對 Becca Kennedy 撰寫的自由職業者項目說不

成績單

Drew McLellan：他是來自英國利茲的獨立顧問 Web 性能工程師。 在他的職責中，他幫助一些世界上最大和最受尊敬的組織為他們的客戶提供更快、更可靠的體驗。 他是受邀的 Google 開發專家、Cloudinary 媒體開發專家、屢獲殊榮的開發人員和國際演講者。 所以我們知道他對網絡性能瞭如指掌，但你知道他有 14 條胳膊和 7 條腿嗎？ 我的 Smashing 朋友們，請歡迎 Harry Roberts。 嗨，哈利，你好嗎？

哈里·羅伯茨：嘿，非常感謝你。 顯然，14 條手臂，7 條腿……仍然是它常見的問題。 不可能買褲子。

德魯：還有自行車。

哈利：是的。 好吧，我有三輛半自行車。

德魯：所以我今天想和你談談，不幸的是，不是關於自行車，儘管這本身很有趣。 我想和你談談網絡性能。 這是一個我個人非常熱衷的主題，但這是我擔心的領域之一，當我把注意力從球上移開並參與其他一些工作，然後再回來做一些表演工作時，我擔心我正在使用的知識很快就會過時......這些天網絡性能是否像我認為的那樣快速發展？

哈利：這是……我什至不是為了對你好，這是一個很好的問題，因為我最近一直在思考這個問題，我想說有兩半。 我會嘗試告訴客戶的一件事是，實際上它並沒有那麼快。 主要是因為，這是我一直使用的聲音片段，你可以在瀏覽器上打賭。 不允許瀏覽器從根本上改變它們的工作方式，因為當然，它們必須維護二十年的傳統。 所以，一般來說，如果你押注瀏覽器並且你知道這些內部結構是如何工作的，並且 TCP/IP 永遠不會改變......所以某些事情是相當固定的，這意味著最佳實踐總體上將始終是涉及基本面的最佳實踐。

Harry：它變得更有趣的地方是……我越來越多地看到，當涉及到站點速度問題時，我們正在把自己畫到角落裡。 所以我們實際上給自己製造了很多問題。 所以這實際上意味著性能……我想這是移動的球門柱。 網絡的景觀或地形變化越多，它的構建方式和我們的工作方式越多，我們就會給自己帶來新的挑戰。 因此，在客戶端上做更多工作的出現帶來了與五年前我們解決的不同的性能問題，但這些性能問題仍然與瀏覽器內部有關，總的來說，五年來沒有改變。 所以很大程度上取決於...而且我想說它肯定有兩個明確的方面...我鼓勵我的客戶依靠瀏覽器，依靠標準，因為它們不能只是改變，球門柱並沒有真正移動. 但是，當然，這需要與更現代、或許更有趣的開發實踐相結合。 所以你保持你的……好吧，我想說“在兩個陣營都有一隻腳”，但我的七英尺，我必須……四和三。

Drew：您提到基本原理不會改變，TCP/IP 之類的東西也不會改變。 確實發生了變化的一件事……我說的是“最近幾年”，這實際上可能要追溯到現在，但是 HTTP 是因為我們已經建立了用於在客戶端和服務器之間進行通信的 HTTP 協議，然後它發生了變化我們得到了 H2，它是二進制的並且是不同的。 這改變了很多......這是出於性能原因，它是為了消除一些現有的限制，但這是一個變化，我們必須針對該協議進行優化的方式發生了變化。 現在穩定了嗎？ 或者它會再次改變，或者......

哈里：所以我想進一步了解的一件事是問題的後半部分，即再次變化。 我需要更多地研究 QUIC 和 H3，但它對我的客戶有用。 當談到 H2 時，情況發生了很大變化，但我真的認為 H2 是很多虛假的承諾，我相信它是匆匆忙忙的，考慮到 H1 的推出，這很了不起……我的意思是 1.1，是 1997 年，所以我們有很多時間來研究 H2。

Harry：我想主要的好處是 Web 開發人員理解它或認為它現在在飛行請求中是無限的。 因此，而不是一次六個已調度和/或六個飛行中的請求，可能是無限的，無限的。 雖然帶來了非常有趣的問題，因為......如果沒有視覺輔助很難描述，但您仍然可以獲得相同數量的可用帶寬，無論您運行的是 H1 還是 H2，該協議都不會使您的連接更快。 因此，您很可能會通過一次請求 24 個文件來淹沒網絡，但您沒有足夠的帶寬。 因此，您實際上並沒有變得更快，因為您一次只能管理其中的一小部分。

哈里：還有你必須考慮的是文件如何響應。 這是我在客戶研討會等方面經歷的另一個專業提示。 人們會看到一個 H2 瀑布，他們會看到傳統的 6 個調度請求，他們可能會看到 24 個。調度 24 個請求實際上並沒有那麼有用。 有用的是這些響應何時返回。 您會注意到您可能會發送 24 個請求，因此您的瀑布左側看起來非常漂亮且陡峭，但它們都以相當交錯的順序返回，因為您需要限制帶寬量，所以您無法同時完成所有響應。

哈利：嗯，另一件事是，如果你要同時完成所有響應，你就會交錯響應。 所以你晚上得到了每個文件的前 10%，接下來的 20%……JavaScript 文件的 20% 是無用的。 JavaScript 在 100% 到達之前是不可用的。 所以你會看到，事實上，當你查看響應時，H2 瀑布的表現方式......無論如何，它看起來更像 H1，它更加交錯。 所以，H2，我認為它被超賣了，或者工程師沒有被引導相信它的有效性有上限。 因為你會看到人們過度分片他們的資產，他們可能有 20 個……讓我們保持數字 24。你可能有 24 個小包，而不是兩個大的 JS 文件。 他們仍然會按順序返回。 它們不會同時到達，因為您沒有為自己增加帶寬。

Harry：另一個問題是每個請求都有固定的延遲。 因此，假設您請求兩個大文件，往返時間為 100 毫秒，下載時間為 250 毫秒，即 250 毫秒的兩倍。 如果您將最多 24 個請求相乘，您仍然有恆定的延遲，我們已經確定為 100 毫秒，所以現在您有 2400 毫秒的延遲和 24 倍……而不是 250 毫秒的下載，假設它是 25 毫秒的下載，它實際上需要更長的時間，因為延遲保持不變，您只需將該延遲乘以更多請求。 所以我會看到客戶會讀到 H2 是這個神奇的子彈。 他們會分片……哦！ 他們不能簡化開發過程，我們不需要做捆綁或連接等等等等。 最終它會變得更慢，因為您已經設法將您的請求傳播出去，這是承諾，但您的延遲保持不變，因此您實際上在瀏覽器中獲得了 n 倍的延遲。 就像我說的，真的很難，如果沒有視覺效果，試圖解釋這一點可能毫無意義，但與人們希望它可能做的相比，H2 的表現方式非常了不起。

德魯：那個分片過程還有好處嗎，好吧，得到全部仍然需要相同的時間，但是當你得到第一個 100% 的第 24 回時，你可以開始處理它，你可以在 24 日結束之前開始執行它。

哈利：哦，伙計，另一個很好的問題。 所以，絕對地，如果事情進展順利並且它確實體現在一個更像 H1 的響應中，這個想法將是文件一首先返回，二、三、四，然後它們可以按照到達的順序執行。 因此，您實際上可以通過確保事物同時到達來縮短總時間。 如果我們查看網頁而不是瀑布流，並且您注意到請求是交錯的，那是個壞消息。 因為就像我說的，10% 的 JavaScript 文件是無用的。

哈里：如果服務器正常工作並且發送、發送、發送、發送、發送，那麼它會變得更快。 然後，您的緩存策略可以更精細地獲得連鎖反應。 所以真的很煩人，你會更新日期選擇器小部件上的字體大小。 在 H1 世界中，您必須緩存站點中大約 200 千瓦的 CSS。 而現在，您只需緩存 bust datepicker.css。 所以我們有這樣的分支好處，這絕對是非常有價值的。

德魯：我想，在你神奇地一次獲得所有請求的情況下，這顯然會潛在地讓客戶端陷入困境，不是嗎？

哈利：是的，有可能。 然後實際發生的是客戶端必須進行大量資源調度，所以你最終會得到一個瀑布，你的所有響應都會同時返回，那麼你之間就會有相當大的差距最後一個響應到達及其執行能力。 所以理想情況下，當我們談論 JavaScript 時，您希望瀏覽器按請求順序請求它們，基本上是您定義它們的順序，服務器以正確的順序返回它們，這樣瀏覽器就可以執行它們以正確的順序排列。 因為，正如您所說，如果它們都同時返回，那麼您就可以同時運行大量的 JavaScript，但仍需要對其進行調度。 因此，在文件到達和它變得有用之間，您最多可能會有第二個懷疑。 所以，實際上，H1 ......我想，理想情況下，你所追求的是 H2 請求調度，H1 樣式響應，所以當它們到達時，事情就會變得有用。

德魯：所以你基本上是在尋找一個看起來可以滑下來的響應瀑布。

哈利：是的，沒錯。

德魯：但你不需要降落傘。

哈利：是的。 這真的很難……我認為大聲說出來聽起來真的很微不足道，但考慮到 H2 的銷售方式，我覺得這很……沒有挑戰性，因為這讓我的客戶聽起來……愚蠢……但這是一件需要解釋的事情對他們來說……如果你想想 H1 是如何工作的，那還不錯。 如果我們得到這樣的回复，“哦，是的，我現在可以看到”。 我以前必須教過性能工程師這個。 做我做的事的人。 我不得不告訴性能工程師，當我們提出請求時，我們不會太介意，我們真的很關心響應何時變得有用。

德魯：事情似乎進展得很快，尤其是在過去五年中，其中一個原因是性能是谷歌的一個大話題。 當谷歌將重量放在這樣的事情上時，它就會獲得牽引力。 但本質上，性能是用戶體驗的一個方面，不是嗎？

哈利：哦，我的意思是……這是一個非常好的播客，我半小時前就在想這個，我向你保證我半小時前就在想這個。 性能是應用的可訪問性。 您正在保證或增加某人可以訪問您的內容的機會，我認為可訪問性始終只是……哦，它是屏幕閱讀器，對嗎？ 是看不見的人。 建立網站而不是應用程序的決定......這些決定是訪問更多的受眾。 所以，是的，性能是應用的可訪問性，因此是用戶體驗。 這種用戶體驗可以歸結為“有人能體驗你的網站嗎”句號。 或者它可能是“那種體驗令人愉快嗎？ 當我點擊一個按鈕時，它是否及時響應？”。 所以我 100% 同意，我認為這就是谷歌重視它的很多原因，因為它會影響用戶體驗，如果有人要信任搜索結果，我們想嘗試給那個人一個網站他們不會討厭的。

Drew：這是……你所想的一切，你所想的所有好處，用戶體驗，諸如增加參與度之類的東西，這絕對是真的，不是嗎？ 沒有什麼比緩慢的體驗更能讓用戶離開網站的了。 這太令人沮喪了，不是嗎？ 使用您知道導航可能不是那麼清晰的網站，並且如果您單擊鏈接並認為“這就是我想要的嗎？ 不是嗎？” 只是點擊的成本，​​只是等待，然後你必須點擊返回按鈕，然後等待，這只是......你放棄了。

哈利：是的，這很有意義。 如果你去超市，你看到它絕對擠滿了人，你會做的最低限度。 你不會在那里花很多錢，就像“哦，我只需要牛奶”，進進出出。 而如果這是一次不錯的體驗，你會得到“哦，好吧，我在這裡的時候，我會看看……哦，是的，他們有這個……哦，我明天晚上做這個”或其他什麼。 我仍然認為，網絡進入了三個十年，即使是為網絡構建的人也在掙扎，因為它是無形的。 他們很難真正認為在真實商店中會惹惱您的東西會在網上惹惱您，並且確實如此，並且統計數據表明確實如此。

德魯：我認為在早期，我在想 90 年代後期，在這裡顯示我的年齡，當我們建立網站時，我們非常考慮性能，但我們從人們之間的聯繫的角度考慮性能使用太慢了。 我們談論的是撥號、調製解調器、通過電話線、28K、56K 調製解調器，並且在某一時刻，有一種趨勢是使用樣式圖像，圖像的每一行都會用純色空白來給出這個……如果你可以想像它就像透過百葉窗看圖像。 我們這樣做是因為它有助於壓縮。 因為每隔一行，壓縮算法都可以——

哈利：折疊成一個指針。

德魯：是的。 因此，您已經顯著減小了圖像尺寸，同時仍然能夠獲得……它成為了一個設計元素。 每個人都在做。 我想也許 Jeffrey Zeldman 是最早開創這種方法的人之一。 但我們當時考慮的主要是我們能以多快的速度把事情搞定。 不是為了用戶體驗，因為我們沒有考慮……我的意思是我猜這是用戶體驗，因為我們不希望人們離開我們的網站，本質上。 但是我們正在考慮不要將事物優化為非常快，而是盡量避免它們非常慢，如果這有意義的話。

哈利：是的，是的。

Drew：然後，我認為隨著像 ADSL 線路這樣的速度變得越來越普遍，我們不再考慮這些術語，而是開始根本不考慮它。 現在我們處於使用移動設備的情況，它們的連接受限，可能 CPU 速度較慢，我們不得不重新考慮它，但這次是為了獲得優勢。 除了用戶體驗方面，它還可以在成本和盈​​利能力方面獲得真正的商業利益。 不是嗎？

哈利：是的，非常好。 我的意思是，不知道如何措辭。 不是在這裡開槍打死自己，而是我嘗試向客戶強調的一件事是，網站速度會給你帶來競爭優勢，但只有一件事能給你帶來競爭優勢。 如果您有沒有人願意購買的產品，那麼您的網站速度有多快都沒有關係。 同樣，如果有人真的想要世界上最快的網站，你必須刪除你的圖片，刪除你的 CSS，刪除你的 JavaScript，然後看看你告訴了多少產品，因為我保證網站速度不是因素。 但研究表明，速度快有巨大的好處，數以百萬計。 在我們說話的時候，我正在和一位客戶一起工作。 我們為他們計算出，如果他們可以將給定的頁面渲染速度快一秒，或者更確切地說，他們最大的繪製內容快一秒，那麼每年價值 180 萬，這是一個很大的數字。

德魯：那幾乎可以支付你的費用。

哈利：嘿！ 是的，差不多。 我確實對他們說：“看，兩年後這一切都會得到回報。 你會收支平衡”。 我希望。 但是，是的，面向客戶的方面......對不起，如果您有一個電子商務網站，他們將花費更多的錢。 如果您是出版商，他們會閱讀更多文章，或者他們會查看更多分鐘的內容，或者您​​所做的任何事情都是您衡量的 KPI。 可能是在 Smashing 網站上，也可能是他們沒有反彈，他們實際上點擊了更多文章，因為我們讓它變得非常簡單和快速。 然後更快的網站運行成本更低。 如果您已對緩存策略進行了排序，那麼您將使人們遠離您的服務器。 如果您優化您的資產，那麼必須來自您的服務器的任何東西的重量都會減少很多。 運行起來便宜很多。

哈利：問題是，到達那裡是有代價的。 我認為 Scott Jehl 可能說得最多……我首先是從他那裡聽到的，所以我假設他想出了這個詞，但俗話說“做一個快速的網站很容易，但做一個網站很難快速地”。 這就是如此簡潔。 因為網絡性能可能會被推到要做的事情列表中的原因是因為您可能可以對客戶說“如果我讓您的網站快一秒，您將每年多賺 180 萬”或者它可以是“如果你剛剛在結賬時添加了 Apple Pay，你將多賺 500 萬。” 因此，這不僅僅與網絡性能有關，也不是決定因素，它是更大戰略的一部分，尤其是對於在線電子商務而言。 但有證據表明，我已經與我的零售客戶、我的電子商務客戶進行了第一手測量。 它的情況就在那裡，你是絕對正確的。 這是競爭優勢，它會讓你賺更多的錢。

Drew：再一次回到過去，但像 Steve Souders 這樣的人是第一批真正開始撰寫和談論 Web 性能的人。 像史蒂夫這樣的人基本上是在說“忘記後端基礎設施，所有的收益都在瀏覽器中，在前端，一切都慢了。” 15年後還是這樣嗎？

哈利：是的，是的。 他在當時和現在之間重新進行了測試，差距實際上已經擴大了，所以實際上成本更高。 但是有一個反擊，那就是如果你的後端性能真的很差，如果你慢慢地走出大門，那麼你只能在前端抓回這麼多。 我現在有一個客戶，他們到第一個字節的時間是 1.5 秒。 因此，我們的渲染速度永遠不會超過 1.5 秒，所以這將是一個上限。 我們仍然可以在前端搶回時間，但是如果您的第一個字節的時間非常非常糟糕，那麼您的後端速度就會變慢，您的前端性能努力可以讓您加快多少速度是有限度的。 但絕對。

哈利：然而，這正在改變，因為……嗯，不，我猜它沒有改變，它變得更糟了。 我們正在將更多內容推給客戶。 它曾經是“你的服務器和它一樣快但之後我們得到一堆問號”的情況。 因為我經常聽到這樣的話“我們所有的用戶都在 WiFi 上運行。 他們都有台式機，因為他們都在我們的辦公室工作。” 嗯，不，現在他們都在家工作。 你沒得選。 所以，這就是所有問號出現的地方，這是減速發生的地方，你無法真正控制它。 在那之後，事實上我們現在傾向於把更多的東西放在客戶身上。 我的意思是，客戶端上的整個運行時間。 無論如何，您已經將所有應用程序邏輯移出服務器，因此您的第一個字節時間應該非常非常少。 應該是從 CDM 發送一些捆綁包到我的……但是你已經從能夠規範到你自己的服務器到希望有人沒有讓 Netflix 在他們試圖查看你的網站的同一台機器上運行.

Drew：關於我們設計網站的方式，這是一個非常好的觀點，我認為傳統的最佳實踐一直是你應該嘗試迎合各種瀏覽器、各種連接速度、各種屏幕尺寸，因為你不不知道用戶會期待什麼。 而且，正如您所說，您會遇到這樣的情況，人們會說“哦，不，我們知道我們所有的用戶都在他們的工作發布的台式機上，他們正在運行這個瀏覽器，它是最新版本，他們已經硬連線到 LAN 中”但後來事情發生了。 擁有網絡應用程序的一大好處是我們可以做一些事情，比如將我們的勞動力突然全部分配回他們的家中，他們可以繼續工作，但這只有在工程質量達到這樣的情況下才成立他們的家用機器上可能裝有 IE11 或其他任何東西，無論工作質量是否存在，這實際上意味著 Web 發揮了其成為真正可訪問媒體的潛力。

Drew：正如你所說，有一種趨勢是將越來越多的東西轉移到瀏覽器中，當然，如果瀏覽器速度很慢，那就是速度變慢的地方。 你不得不懷疑“這是一個好趨勢嗎？ 我們應該這樣做嗎？” 我有一個我特別想到的站點，注意到它幾乎 100% 呈現服務器。 JavaScript 很少，而且速度極快。 每次我去看它時，我都會想“哦，這太快了，這是誰寫的？” 然後我意識到“哦，是的，是我”。

哈利：那是因為你在本地主機上，難怪感覺很快。 這是您的開發網站。

Drew：然後，我的日常工作是構建單頁應用程序並將內容從服務器轉移，因為在這種情況下服務器是瓶頸。 你能說在瀏覽器中性能更高嗎？ 或者在服務器上性能更高？ 這只是一個根據具體情況衡量和採取的情況嗎？

哈里：我認為你需要非常、非常、非常了解你的背景，並且......真的，我認為一個錯誤是......自戀，人們認為“哦，我的博客應該在某人的瀏覽器中呈現。 我的博客跳出率為 89%，需要在瀏覽器中擁有自己的運行時間，因為我需要快速的後續導航，我只想獲取一個……基本上是數據的差異。” 無論如何，沒有人會點擊您的下一篇文章，伙計，不要將運行時推送到管道中。 所以你需要非常了解你的上下文。

Harry：而且我知道……如果 Jeremy Keith 聽到這個，他可能會對我大發雷霆，但我想說，網站和網絡應用程序之間存在差異，它的定義非常，很模糊。 但是，如果您有一個讀寫量很大的應用程序，那麼您在輸入數據、操作數據等的地方。 基本上我的網站不是一個網絡應用程序，它是一個網站，它是只讀的，我會堅定地加入網站陣營。 像我的會計軟件是一個網絡應用程序，我會說是一個網絡應用程序，我準備承受一點啟動時間成本，因為我知道我會在那里呆 20 分鐘，一個小時，不管怎樣。 所以你需要一些背景知識，也許自戀有點苛刻，但你需要有一個真正的“我們需要讓這份報紙成為客戶端應用程序嗎？” 不，你沒有。 不，你沒有。 人們已經啟用了廣告攔截器，無論如何人們都不喜歡通勤報紙網站。 他們可能甚至不會閱讀這篇文章並在 Facebook 上大肆宣揚。 只是不要將類似的東西構建為客戶端呈現的應用程序，它是不合適的。

哈里：所以我確實認為，在某一點上，更多地關注客戶肯定會有所幫助，那就是你對客戶流失的敏感性降低的時候。 因此，任何com 類型，例如，我正在為一個站點進行片刻審核……我認為它是一個E-Com 站點，但它是100% 的客戶端。 你禁用了 JavaScript，你什麼也看不到，只是一個空的 div id="app"。 E-Com 是……你對任何問題都非常敏感。 您的結帳流程甚至有點錯誤，我在其他地方。 太慢了，我去別的地方了。 您沒有人願意在一段時間內使用該應用程序的上下文。

哈里： Photoshop。 我打開 Photoshop，我很高興知道這將需要 45 秒的啟動畫面，因為我將在那裡待……基本上 45 秒值得 45 分鐘。 這很難定義，這就是為什麼我真的很難說服客戶“請不要這樣做”，因為我不能只說“你認為你的用戶會在那里呆多久”。 如果您 89% 的跳出率沒有針對第二次頁面瀏覽進行優化，您可以從以下方面進行代理。 首先降低跳出率。 我確實認為肯定存在分歧，但我想說的是，大多數人都站在這條線的錯誤一邊。 大多數人將不應該存在的東西放在客戶端中。 例如 CNN，在完全啟動 JavaScript 應用程序之前，您無法閱讀 CNN 網站上的單個標題。 服務器唯一呈現的是頁眉和頁腳，這是人們唯一不關心的。

哈利：我覺得那隻是……我不知道我們是怎麼走到那一步的。 它永遠不會是更好的選擇。 你提供了一個實際上毫無用處的頁面，然後不得不說“酷，我會去獲取本來應該是一個網絡應用程序的東西，但我們要在瀏覽器中運行它，然後我會去問一個標題，然後你就可以開始……哦，你走了。” 這真的，真的讓我很惱火。

Harry：這不是任何人的錯，我認為這是這種 JavaScript 生態系統的起步階段，圍繞它的炒作，而且，這聽起來真的很刺耳，但是……這基本上是很多天真的實現。 當然，Facebook 已經發明了 React，不管怎樣，它對他們有用。 10 人中有 9 人不是在 Facebook 規模工作，100 人中有 95 人可能不是最聰明的 Facebook 工程師，這真的很殘酷，說起來聽起來很可怕，但你只能……沒有默認情況下，這些東西很快。 你需要一個非常非常優雅的實現這些東西來使它們正確。

Harry：我正在和我的老……討論這個問題……他是我 10 年前在 Sky 所在球隊的首席工程師。 前幾天我和他談過這個問題，他必須非常努力地讓客戶端渲染的應用程序快速，而讓服務器渲染的應用程序快速，你不需要做任何事情。 你只需要不再讓它變慢。 而且我覺得有很多玫瑰色眼鏡，天真，營銷......我聽起來很黯淡，我們需要繼續前進，然後我才開始真正失去這裡的人。

Drew：您認為作為一個行業，我們有時是否傾向於更多地關注開發者體驗而不是用戶體驗？

哈利：不是作為一個整體，但我認為這個問題會出現在你所期望的地方。 如果你看一下這種差異……我不知道你是否看過這個，但我想你已經看到了，你似乎非常了解脈搏，HTTP 存檔關於哪些框架和哪些數據之間的差異JavaScript 庫與 JavaScript 狀態調查相比，JavaScript 庫被廣泛使用，如果您遵循 JavaScript 調查狀態，它會說“哦，是的，75% 的開發人員正在使用 React”，而只有不到 5% 的網站正在使用 React。 所以，我覺得，總的來說，我不認為這是一個問題，但我認為在你所期望的領域，例如對一個框架的高度忠誠度，開發人員的體驗是……可能在用戶之前得到傳播。 我認為不應忽視開發人員的經驗，我的意思是，一切都有維護成本。 你的車。 設計時有一個決定，“好吧，如果我們對機制隱藏這個鍵，那個功能，那麼這個機制會花費更長的時間來修復它，因此我們不會做那樣的事情”。 所以確實需要在人體工程學和可用性之間取得平衡，我認為這很重要。 我認為主要關注開發人員體驗對我來說只是莫名其妙。 不要為你優化，為你的客戶優化，你的客戶付錢給你，不是相反。

德魯：所以當你看到每個人都說“哦，你應該使用這個，你應該這樣做”時，在線迴聲室並不能完全代表現實，那麼這實際上只是一小部分人。

哈利：是的，這是一件好事，讓人放心。 回音室……如果你想這樣稱呼它，那麼擁有那種單一文化也許是不健康的。 而且，我覺得……而且我在我自己的很多工作、很多開發人員中都看到了這一點……作為一名顧問，我與很多不同的公司合作。 很多人都在 WordPress 中做著驚人的工作。 WordPress 為 24% 的網絡提供支持。 而且我覺得對於像這樣的開發人員來說，在後端使用 WordPress 或 PHP 之類的東西，自定義代碼，不管它是什麼，感覺有點像“哦，我猜每個人都在使用 React 而我們不是” 但實際上，沒有。 每個人都在談論 React，但你仍然隨波逐流，你仍然是大多數人。 找到沉默的大多數是相當令人欣慰的。

Drew：靜態站點生成器的趨勢，然後將站點完全託管在 CDN 上，類似於 JAMstack 方法，我想當我們談論那些發布類型的站點，而不是軟件類型的站點時，我想這是一個非常健康的趨勢，你覺得呢？

哈利：我非常喜歡，絕對。 你還記得我們以前把 SSG 稱為“flap 文件”的時候吧？

德魯：是的。

Harry：所以，當 Jekyll 被稱為翻頁文件網站時，我在 Jekyll 上構建了 CSS Wizardry。 但現在我們為我們的發電機提供服務，這是它的超級超級粉絲。 There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

德魯：是的。

Harry: … diminishing returns, that's exactly it. 是的，正是。

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? 這太好了。 Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

哈里：他贏得了尊重，但他是小伙子中的一員，我們都非常喜歡他。 但他在各個方面都是巨大的。 身高超過六英尺，但只是個大男孩。 大，大，大，大人。 他對我們說：“如果你要設計一個門口，你會為普通人設計嗎？” 15 歲的大腦會說“嗯，是的，如果每個人的身高都大約是 5 英尺 9 英寸，那麼是的”他就像“嗯，馬上，哈利不能使用那扇門。” 您不是為普通人設計，而是為四肢設計，因為您希望它對大多數人有用。 如果你為普通人設計一把椅子，Brocklesby 先生不會適合它。 所以他從一個非常非常大的年齡教我設計到你的四肢。

Harry：在網絡性能中真正有趣的地方是......如果你想像一個梯子，然後你用機器人拿起梯子......好吧，我剛剛意識到我的比喻可能......我會堅持下去，你可以笑之後我。 想像一個梯子，你通過底部的梯級將梯子抬起。 那是你最糟糕的經歷。 您選擇梯子的底部梯級將其抬起。 整梯隨其而來，如漲潮浮舟。 比喻不起作用的原因是，如果你從最上面的梯級拿起梯子，它也會升起來，它就是梯子。 如果我把它變成一個繩梯，這個比喻甚至都行不通，因為一個繩梯，你抬起底部梯級，什麼都沒有發生，但是……我的意思是，如果你能提高 90% 的體驗，它必須把它提高到你的第 10 個百分位，對吧？

哈里：這就是為什麼我告訴客戶，他們會對我說“哦，我們的大多數用戶都在 iPhone 上使用 4G”之類的話，好吧，我們開始在 Android 上測試 3G，比如“不，不，我們的大多數用戶都是 iPhone”好吧……這意味著您的普通用戶將獲得更好的體驗，但任何尚未處於第 50 個百分位的人都會被遠遠甩在後面。 因此，通過將期望設置得相當低，為自己設置相當高的標準。

哈利：對不起，我有一個很壞的習慣，就是對簡短的問題給出很長的答案。 但這是一個絕妙的問題，而且，嘗試總結一下，我 100% 肯定同意你的觀點，你想看看那個長尾，你想看看那個……你的第 80 個百分位，因為如果你把所有的經驗都放在該網站並查看中位數，並且您提高了中位數，這意味著您已經讓那些已經非常滿意的人變得更好。 50% 的人被有效地忽視不是正確的方法。 是的，它總是回到布洛克斯比先生告訴我“不要為普通人設計，因為那樣哈利就不能使用門”。 哦，對於任何人來說，我是 193 厘米，所以我很瘦，就是這樣。

德魯：還有那些胳膊和腿。

哈利：是的。 這也是另一個很好的。 我的女朋友最近發現了 iOS 中的輔助功能設置……所以每個人的手機都處於靜音狀態，對吧？ 沒有人真正擁有真正響起的電話，每個人都將其設為靜音。 她發現“哦，你知道，你可以設置它，這樣當你收到一條消息時，閃光燈就會閃爍。 如果你點擊手機背面兩次，它就會截屏。” 這些是可訪問性設置，它們是為第 95 個百分位設計的。 然而她就像“哦，這真的很有用”。

Harry： OXO Good Grips 也是如此。 OXO Good Grips，廚房用具。 我在廚房裡有很多。 它們的設計是因為創始人的妻子患有關節炎，他想製作更舒適的器皿。 他為 99% 的人設計的，大多數人沒有關節炎。 但是通過為 99% 進行設計，不經意間，其他所有人都會說“天哪，為什麼所有的土豆削皮器都不能這麼舒服？” 而且我覺得它真的，真的……我喜歡在這些場景中推出的感覺良好或軼事。 但是，是的，如果您針對他們進行優化……嗯，漲潮會使所有船隻飄浮，因此優化了人們的尾端，您將在此之上吸引更多更快樂的客戶。

德魯：你有 OXO Good Grips 手動手動打蛋器嗎？

哈利：我沒有。 沒有，好用嗎？

德魯：調查一下。 它是那麼好。

哈利：我確實有 OXO Good Grips 曼陀林切片機，它上週把我的手指末端弄斷了。

德魯：是的，我不會靠近其中一個。

哈利：是的，這是我自己愚蠢的錯。

德魯：從我自己的經驗中獲得長尾服務的另一個例子是，在我目前正在進行的項目中，長尾就在最後，你有表現最慢的人，但如果你看看這些客戶是誰，他們是企業最有價值的客戶——

哈利：好的。

德魯： ……因為他們是擁有最多數據的最大組織。

哈利：對。

Drew：所以他們遇到了瓶頸，因為他們有太多的數據要顯示在頁面上，而這些頁面需要稍微重構以幫助該用例。 因此，他們的體驗最慢，歸根結底，他們支付的錢最多，並且比所有擁有真正快速體驗的人產生的影響要大得多，因為他們是免費用戶，擁有少量的數據，一切都很好，而且速度很快。

哈利：那是一個迷人的維度，不是嗎？ 事實上，我也有類似的情況……我對業務的影響遠沒有你剛才描述的那樣，但幾年前我和一個客戶合作過，他們的 CEO 聯繫了他們，因為他們的網站速度很慢。 比如，慢，慢，慢。 也是非常好的人，他只是一個非常接地氣的人，但他受到指導，就像真正的有錢人一樣。 他有最新的 iPhone，他買得起。 他是一位千萬富翁，他花費大量時間往返於他來自的澳大利亞和他現在居住的愛沙尼亞之間。

哈利：而且他坐的是頭等艙，他當然是。 但這意味著他大部分時間都在他漂亮、閃亮的 iPhone 12 Pro Max 上，不管怎樣，都是通過飛機 WiFi 進行的，這太糟糕了。 正是這種驚人的並列，他擁有該網站並且他經常使用它，這是他使用的網站。 他正在推動它……我的意思是，他們最富有的客戶很容易就是他們的首席執行官。 而且他處於這個奇怪的特權位置，他的聯繫比 Joe Public 更糟糕，因為他在新加坡上空的某個地方乘坐 Quantas 的航班，香檳倒在他的脖子上，他正在掙扎。 這是一個非常令人著迷的見解……哦，是的，因為你有 95% 的百分位基本上可以朝任何一個方向發展。

德魯：是的，當你開始優化使用一個手裡拿著一杯香檳的網站時，你會想“也許我們開始有點迷路了”。

哈利：是的，沒錯。

德魯：我們談了一點關於績效衡量的問題，根據我自己在績效工作中的經驗，衡量每一個問題非常重要你正在做出不同，你正在做出多大的改變。 我們應該如何衡量我們網站的性能？ 我們可以使用哪些工具，我們應該從哪裡開始？

哈利：哦，伙計，另一個好問題。 因此，根據修復站點速度的時間、資源和傾向，有一系列答案。 所以我將嘗試對客戶做的是……某些現成的指標非常好。 加載時間，不再關心這個了。 它非常、非常、非常……我的意思是，如果您的加載時間為 120 秒，它是一個很好的代理。我猜您的網站速度不是很快，但它太晦澀難懂而且不是真正面向客戶的。 實際上，我認為 Vitals 是朝著正確方向邁出的非常好的一步，因為它們確實衡量了用戶體驗，但它們基於技術輸入。 Largest Contentful Paint 對視覺來說是一件非常好的事情，但其中的技術內容可以暢通您的關鍵路徑，確保英雄圖像快速到達並確保您的網絡字體策略是體面的。 這些指標存在技術暗流。 那些現成的真的很好。

Harry：但是，如果客戶有時間，通常是時間，因為您想要捕獲數據但您需要時間來實際捕獲數據。 所以我嘗試與客戶一起做的是讓我們去“看，我們不能在接下來的三個月裡一起工作，因為我已經訂滿了。 所以，我們能做的就是快速讓您免費試用 Speedcurve，設置一些自定義指標”，這意味著對於出版商客戶、報紙，我將衡量“文章呈現？ 文章的主要圖片渲染速度有多快？” 對於我想要衡量的電子商務客戶，因為顯然您正在衡量諸如開始被動渲染之類的東西。 一旦您開始使用任何性能監控軟件，您就可以免費獲取實際的性能指標。 因此，您的第一個內容豐富的繪畫、最大的內容內容等。我真正想要捕捉的是對他們作為企業而言重要的事情。

Harry：所以，在我們能夠關聯的那一刻與 E-Com 客戶合作……您的開始渲染速度越快，添加到購物車的概率是多少。 如果您能盡快向他們展示產品，他們就更有可能購買。 這需要付出很多努力，對於真正有抱負的客戶來說，這是一種延伸目標，但任何你真正想要衡量的東西，因為就像我說的，你真的不想衡量你最大的目標Contentful Paint 是，您想衡量您的收入，這是否受到大型 Contentful Paint 的影響？ 因此，延伸目標，即最終目標，將是您認為該業務的 KPI 的任何內容。 可能是，在報紙上，有人將文章向下滾動了多遠？ 這是否與第一次輸入延遲有任何關係？ 如果 CLS 較低，人們是否閱讀了更多文章？ 但在我們開始進行自定義、自定義指標之前，老實說，我認為 Web Vitals 是一個非常好的起點，而且它也已經很好地標準化了。 它變成了一個……我不知道這個詞是什麼。 我猜是最低公分母，現在行業中的每個人都可以在這個公平的競爭環境中討論表現。

Harry：我遇到的一個問題是，我實際上需要與 Vitals 團隊開會，我也真的認為 Lighthouse 很棒，但 CLS 佔 web Vitals 的 33%。 你有 LCP、FID、CLS。 CLS 佔您生命體徵的 33%。 Vitals 是通常出現在您的營銷團隊、分析部門面前的內容，因為它會在搜索控制台中彈出，在搜索結果頁面的上下文中被提及，而 Vitals 則具有很高的權重，33%，三分之一Vitals 是 CLS，它只占我們 Lighthouse 分數的 5%。 所以你會得到的是圍繞 Lighthouse 構建的開發人員，因為它可以集成到工具中，這是一個實驗室指標。 Vitals 是現場數據，是朗姆酒。

Harry：所以你有一個巨大的脫節，你的營銷團隊說“CLS 真的很糟糕”，而開發人員認為“嗯，這是 DevTools 給我的 Lighthouse 分數的 5%，這是分數的 5% Lighthouse CLI 在 CircleCI 中為我們提供了“或任何您正在使用的東西，但對於營銷團隊來說，他們關心的是 33% 的內容。 所以問題有點脫節，因為我確實認為 Lighthouse 非常有價值，但我不知道他們如何調和在生命體徵中的相當大的差異，CLS 是你得分的 33%……嗯，不是因為你得分真的沒有，Lighthouse 只有 5%，在我們可以無縫討論之前，仍然需要解決這些問題。

哈利：但是，再一次，對一個簡短問題的長回答。 生命體徵真的很好。 LCP 是一個很好的用戶體驗指標，可以歸結為技術解決方案，與 CLS 相同。 所以我認為這是一個非常好的起點。 除此之外，它是自定義指標。 我試圖讓我的客戶達到一個點，他們並不真正關心他們的網站有多快，他們只關心他們從昨天賺更多的錢，如果這樣做是因為它運行得很快？ 如果它減少了，是因為它運行得更慢了嗎？ 我不希望他們追逐神秘的兩秒 LCP，我希望他們追逐最優的 LCP。 如果這實際上比你想像的要慢，那麼無論如何，沒關係。

Drew：所以，對於只對……感興趣的 Web 開發人員來說……他們沒有預算花在 Speedcurve 之類的工具上，他們顯然可以在瀏覽器中運行 Lighthouse 之類的工具，以獲得一些好的測量結果……像 Google 這樣的東西嗎？分析對那個級別有用嗎？

哈利：它們是，而且它們可以變得更有用。 多年來，分析已經捕獲了基本的性能信息。 這將是 DNS 時間、TCP 和 TLS、第一個字節的時間、頁面下載時間，這是一個代理......好吧，無論如何，只是頁面下載時間和加載時間。 所以相當笨重的指標。 但這是一個很好的起點，通常我從客戶開始的每個項目，如果他們沒有 New Relic 或 Speedcurve 或其他什麼，我只會說“好吧，讓我看看你的分析”，因為我可以至少從那裡代理情況。 它永遠不會像 Speedcurve 或 New Relic 或 Dynatrace 之類的那樣好。 您可以非常、非常、非常輕鬆地將自定義指標發送到分析。 如果有人收聽希望能夠發送……例如我的網站。 我有一些指標，比如“你能多快閱讀我的一篇文章的標題？ 關於頁面圖像是在什麼時候呈現的？ 在什麼時候呼籲採取行動，懇求你僱用我？ 多久會渲染到屏幕上？” 捕獲這些數據真的很簡單，將其發送到分析幾乎同樣簡單。 因此，如果有人想在我的網站上查看源代碼，向下滾動到結束正文標籤並找到分析片段，您將看到我捕獲自定義數據並將其發送到分析是多麼容易。 而且，在分析 UI 中，您無需執行任何操作。 通常，您必須設置自定義報告並挖掘數據並使其易於呈現。 這些是谷歌分析中的一等公民。 因此，當您開始捕獲自定義分析時，儀表板的整個部分都專門用於它。 GA 本身沒有設置，也沒有繁重的工作，所以這真的很簡單，如果客戶有真正的預算，或者我想向他們展示自定義監控的力量，我不想說“哦，是的，我保證真的很好，我可以為 Speedcurve 準備 24 個 Grand 嗎？” 我可以先說“看，這是初級的。 讓我們看看這裡的可能性，現在我們也許可以說服你升級到像 Speedcurve 這樣的東西。”

Drew：我經常發現，我對某件事應該有多快或改變應該產生什麼影響的直覺可能是錯誤的。 我會做出改變，並認為我讓事情變得更快，然後我測量它，實際上我讓事情變得更慢。 這只是我在網絡性能上的垃圾嗎？

哈利：一點也不。 我有一個非常相關的例子。 預加載……對於沒有聽說過預加載的人來說，這是一個真正的快速介紹，在網絡上加載某些資產本質上非常慢，這裡的兩個主要候選者是 CSS 和網絡字體的背景圖像，因為在你可以下載背景圖像之前，你有下載 HTML，然後下載 CSS，然後 CSS 顯示“哦，主頁上的這個 div 需要這個背景圖片。” 所以它本質上是非常慢的，因為你有整個 CSS 時間介於兩者之間。 使用預加載，您可以在 HTML 中的 head 標籤中添加一行內容：“嘿，您還不知道，但是，相信我，您很快就會需要這張圖片。” 因此，您可以在 HTML 中放置一個預加載，該預加載會搶先啟動此下載。 當 CSS 需要背景圖像時，就像“哦，太棒了，我們已經得到它了，真快。” 這被吹捧為這個網絡表演彌賽亞......事情就是這樣，我向你保證，我上週發了這個推文，從那以後我兩次被證明是對的。 人們聽說了預加載，以及它給出的承諾，而且它也受到 Lighthouse 的大力推動，理論上，它可以讓您的網站更快。 人們對預加載的想法如此執著，以至於即使我可以證明它不起作用，他們也不會再次刪除它。 因為“不，但燈塔說。” 現在這是理論合理的事情之一。 如果您必須等待您的網絡字體，而不是早點下載它，您會更快地看到內容。 問題是，當您考慮 Web 的實際工作方式、您第一次訪問的任何頁面、您訪問的任何全新域時，您的帶寬是有限的，而瀏覽器非常聰明地正確地使用了該帶寬。 它會非常快速地瀏覽您的 HTML 並製作購物清單。 最重要的是 CSS，然後是這個 jQuery，然後是這個……然後接下來的幾件事是這些，這些，以及這些優先級較低的。 一旦您開始使用預加載加載 HTML，您就是在告訴瀏覽器“不，不，不，這不再是您的購物清單了，伙計，這是我的。 你得去拿這些。” 有限的帶寬仍然是有限的，但它並沒有花在更多的資產上，所以一切都會稍微變慢。 在過去的一周裡，我不得不發出兩次噓聲，但仍然有人說“是的，但不是，因為它下載得更快了。” 不，它被請求得更快，但它正在從你的 CSS 中竊取帶寬。 您可以從字面上看到您的網絡字體正在從您的 CSS 中竊取帶寬。 所以這是你必須、必須、必須遵循數字的事情之一。 我以前在大型客戶上做過。 如果你在聽這個，你聽說過這個客戶，我非常堅持“不，不，你的頭部標籤順序錯誤，因為它應該是這樣的，你需要把它們放在這個訂購，因為從理論上講，它暗示了……”即使在我對客戶的印像中，我也知道我是在為自己設置一個傻瓜。 由於瀏覽器的工作方式，它必須更快。 因此，我正在對數以百萬計的人進行這種策略，這種改變，而且速度變慢了。 它變慢了。 而我坐在那裡，憤憤不平地堅持“不，但是，瀏覽器是這樣工作的”是沒有用的，因為它不工作。 我們恢復了它，我就像“對不起！ 仍然要為此開具發票！” 所以根本不是你。

德魯：按照這些數字。

哈利：是的，沒錯。 “我實際上要向你收取更多費用，因為我花了時間恢復它，花了我更長的時間。” 但是，是的，你是絕對正確的，不是你，這是其中之一……我已經做了很多次，規模要小得多，我會說“嗯，這理論上必須有效”，但它沒有不。 你只需要跟隨現實世界中發生的事情。 這就是為什麼監控非常重要。

Drew：隨著環境的變化和技術的發展，谷歌推出了新技術來幫助我們加快速度，有沒有什麼好方法可以讓我們跟上變化？ 在網絡性能方面，我們是否應該尋找任何資源來使我們的技能保持最新？

Harry：為了快速解決整個“谷歌製作”……我知道這有點開玩笑，但我會專注於這個。 我想一開始就押注在瀏覽器上。 例如，像 AMP 之類的東西，它們充其量只是一個經過深思熟慮的解決方案。 建立一個快速的網站是無可替代的，當你開始使用 AMP 之類的東西時，你必須堅持那些非標準的標準，AMP 團隊會改變主意。 我有一個客戶花了一大筆錢從 AMP 允許列出的字體提供商那裡獲得字體許可，然後在某個時候，AMP 決定“哦，實際上不，提供的字體，我們現在要阻止它們”所以我有一個客戶誰在 AMP 和這個字體提供商上投入巨資，不得不選擇“好吧，我們是撤消所有 AMP 工作，還是我們只是在網絡字體上浪費了這個非常大的數字”等等。 所以我對任何人都非常警惕……我是一名 Google 開發人員專家，但我不知道任何令人作嘔的命令……我可能很挑剔，我會說……避免被稱為單一尺寸的東西- 萬能的解決方案，例如 AMP。

Harry：為了讓別人暫時傾倒，Cloudflare 有一個叫做 Rocket Loader 的東西，它是 AMP 式的。 它的設計就像“哦，只要在你的 CDN 上打開這個東西，它會讓你的網站更快。” 實際上，它只是一開始就正確構建站點的替代品。 所以……為了解決這方面的問題，盡量保持獨立，了解瀏覽器的工作原理，這立即意味著 Chrome 的單一文化，你又回到了谷歌的圈子裡，但知道瀏覽器是如何工作的，堅持一些基本的意識形態。 在構建站點時，請查看頁面。 無論是在 Figma、Sketch 還是其他任何地方，看看設計並說“嗯，這是用戶首先想要看到的，所以我不會做任何事情。 我不會懶惰地加載這個主圖像，因為那很愚蠢，我為什麼要這樣做？” 所以只要想一想“你希望用戶首先是什麼？” 在 E-Com 網站上，它將是那個產品圖像，可能同時是導航，但是產品的評論、產品的 Q 和 A 會延遲加載。 把它藏在 JavaScript 後面。

Harry：無論您正在閱讀什麼技術，某些基本的工作方式都會為您服務，即“優先考慮客戶的優先事項”。 做更多的工作會更快，所以不要把事情放在一邊，而是讓人們意識到更多的戰術性事情，跟上……再次，直接回到谷歌，但是 web.dev被證明是框架不可知論、堆棧不可知論見解的非凡資源……所以如果你想了解生命體徵，你想了解 PWA，所以 web.dev 真的很棒。

Harry：實際上很少有以性能為中心的出版物。 Calibre 的電子郵件是，我認為它每兩週一次的電子郵件非常出色，它是一個非常好的摘要。 密切關注 Web 平台，所以有性能工作組，他們在 GitHub 提案上有很多東西。 再次回到谷歌，但沒有人知道這個網站及其驚人的：chromestatus.com。 它準確地告訴你 Chrome 正在做什麼，來自其他瀏覽器的信號是什麼，所以如果你想看看優先提示的工作是什麼，你可以去獲取所有相關錯誤跟踪器的鏈接。 Chrome 狀態會向您顯示每個里程碑……“這是在 MAT8 中發布的，這是在 67 年發布的”或其他任何東西，這對於相當技術性的見解來說是一件非常好的事情。

哈利：但我一直在談論這件事，我知道我可能聽起來像“老人對克勞德大喊大叫”，但堅持基本原則，我所賺取的幾乎每一英鎊或美元、歐元，都在教客戶“你知道瀏覽器已經這樣做了，對吧”或“你知道這不可能更快”，這聽起來對我很有道理……我從來沒有從銷售額外技術中賺到一分錢。 我賺的每一點錢都是關於去除，減去。 如果您發現自己添加了一些東西以使您的網站更快，那麼您就走錯了方向。

哈里：舉個例子，我不打算點名……大型廣告/搜索引擎/瀏覽器公司，不打算點名，也不打算點名 JavaScript 框架，但我目前在與一個非常、非常大、非常流行的 JavaScript 框架討論刪除正在積極損害的東西，或者有選擇地刪除會損害大量網站性能的東西。 他們就像“哦，我們要循環進來……”來自這家大公司的某個人，因為他們做了一些研究……就像“我們需要一個選項來刪除這個東西，因為你可以在這里和這裡看到，並且這讓這個網站變慢了。” 他們的解決方案是添加更多，比如“哦，但如果你也這樣做，那麼你可以迴避那個”，就像“不，不，添加更多以使網站更快一定是錯誤的解決方案。 如果需要更多代碼才能最終獲得更快的網站，那麼您肯定會發現您正朝著錯誤的方向前進。”

哈里：因為它一開始很快，而你添加的所有東西都會讓它變慢。 以及添加更多以使其更快的想法，儘管……它可能會在更快的網站中表現出來，但這是錯誤的方式。 這是一場逐底競賽。 對不起，我真的很生氣，你可以看出我有一段時間沒有咆哮了。 所以這是另一回事，如果您發現自己添加功能以使網站更快，那麼您可能正朝著錯誤的方向前進，通過刪除東西來加快速度要比添加它們更有效。

Drew：您製作了一個視頻課程，名為“我為快速製作 CSS 魔法所做的一切”。

哈利：是的！

Drew：這和傳統的在線視頻課程有點不同，不是嗎？

哈利：是的。 老實說，部分原因是……我不想說我的懶惰，但我不想設計一個必須非常嚴格的課程，讓你從零到英雄，因為這樣做需要時間是巨大的，我不知道我是否會有時間。 所以我想要的是有現成的材料，只是屏幕投射我自己通過它說話，所以它不會以“這是一個瀏覽器，這是它的工作原理”開始，所以你至少需要知道網絡性能基礎知識，但它是黑客和專業技巧以及現實生活中的例子。

哈里：而且因為我不需要完成完整的課程，我能夠將價格大幅降低。 所以這不是一個 10 小時的大型課程，可以讓你從零到英雄，它是你認為合適的進進出出。 它基本上只是在查看我的網站，這是一個非常適合不穩定事物的遊樂場，或者……我在那裡進行實驗的風險非常低。 所以我剛剛完成了視頻系列。 錄製非常有趣。 只是拆除我自己的網站並談論“這就是它的工作原理，這就是你如何使用它”。

Drew：我認為將其拆分為解決不同的問題真的很棒。 如果我想了解更多關於優化圖像或其他內容的信息，我可以想“好吧，我的伙伴 Harry 對此有什麼看法？”，然後觀看有關圖像的視頻，然後我就走了。 以這種方式真的很容易獲得，你不必坐幾個小時的東西，你可以去你想要的地方，學習你需要學習的東西，然後出去。

哈里：我想我試著保持更多……不做死板課程的好處是你不需要先看某個視頻，沒有介紹，只是“去看看周圍，看看你覺得有趣的東西”這意味著遇到 LTP 問題的人會說“哦，我必須在這裡深入研究這個文件夾”，或者如果他們遇到 CSS 問題，他們可以深入研究那個文件夾。 顯然我沒有統計數據，但我想課程的放棄率很高，純粹是因為你必須跋涉三個小時的介紹，以防你錯過了什麼，就像“哦，你知道嗎，我不能每天都這樣做”，人們可能會放棄很多課程。 所以我的想法只是潛入，你不需要看到前三個小時，你可以去尋找你想要的任何東西。 並且反饋真的，真的......事實上，我要做的是，它還不存在，但我會在通話後立即做，任何使用折扣代碼 SMASHING15 的人，他們將獲得 15% 的折扣其中。

德魯：所以這幾乎就像你已經優化了課程本身的性能，因為你可以直接進入你想要的部分，而不必進行所有談判並且-

哈利：是的，是無意的，但我會為此負責。

Drew：所以，我一直在學習有關 Web 性能的所有知識，Harry，你最近在學習什麼？

哈利：技術的東西……不是真的。 我的“要學習”清單上有很多東西，所以 QUIC、H3 之類的東西我想獲得更多關於這方面的工作知識，但我在英國第一次封鎖期間寫了一本電子書，所以我學會了如何製作非常有趣的電子書，因為它們只是 HTML 和 CSS，而且我知道我的方法，所以這非常有趣。 我為這門課學習了非常基本的視頻編輯，我喜歡這些都不是概念性的工作。 顯然，學習一門編程語言，你必須與概念搏鬥，而學習電子書只是工作流程和……我以前從未修改過的東西，所以學習很有趣，但不需要改變職業，所以這很好。

哈利：然後，非技術性的東西……我騎了很多自行車，我從自行車上摔下來了很多……而且因為自去年三月以來我幾乎沒有旅行過，現在已經快一年了，我已經做了很多騎自行車並更多地關注……改善這一點。 因此，我一直在圍繞功率輸出和功能性閾值功率進行大量研究，目前我正在做一個訓練計劃，因此經常，不斷地疲憊的腿，但我正在學習很多關於騎自行車的生理學。 我不知道為什麼，因為除了繼續騎行之外，我沒有任何計劃對它做任何事情。 這真的很迷人。 我覺得在封鎖期間我很幸運，複數，但我設法保持活躍。 很多人會錯過一些簡單的事情，比如每天上班通勤、伸展雙腿的好機會。 如您所知，在英國，騎自行車非常受歡迎，因此我一直在努力從更生理的角度學習更多有關騎自行車的知識，這意味著……不知道，只是一個書呆子換個東西。

Drew：網絡上的性能優化和自行車上的性能優化之間可能沒有太大區別，都是邊際收益，對吧？

哈利：是的，沒錯。 還有我在自行車上查看的圖表數量……我已經從自行車上獲得了功率數據，我會出去騎車然後回來，就像“哦，如果我在這裡還有 5 瓦，然後節省了 10瓦在那裡，我可以做到這一點，這個，這是有史以​​來最快的”，並且……對此非常著迷。 但是，是的，你是對的。 你知道嗎，我想你在那裡發現了一些真正感興趣的東西。 我認為這種事情對於有點痴迷，喜歡追逐數字的人來說是一項很好的運動/消遣。 有些事情，我的意思是你會知道這一點，但是，Strava，你有你的 KOM。 去年我買了 19 個，對我來說，這是一個驚人的數量。 這幾乎全來自對可用數據的痴迷，並看著“我試圖擊敗的這個人，他現在的功率是 700 瓦，如果我能達到 1000 瓦然後停止”，等等，等等，等等......這是強迫症。 書呆子。 但你是對的，我想這是類似的事情，不是嗎？ If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

哈利：是的。 I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.