如何優化移動性能

已發表: 2022-03-10
快速總結↬您不能低估跨各種形狀和大小的設備的一致、高質量網頁設計的重要性。 響應式網頁設計是前進的方向——但它通常與性能問題有關。 當 64% 的智能手機用戶無情地期望網站在 4 秒內加載,但平均頁面權重繼續上升時,這一點至關重要。

最好的設計從一開始就考慮到移動設備來平衡美學和性能。 從設置嚴格的性能預算到實施客戶端和服務器端優化技術,我將分享我們在Cyber​​-Duck使用的當前移動性能優化流程。

Mobile Performance
從一開始就考慮到移動設計有助於平衡跨設備的網站美感和性能。 (大預覽)

成為移動思維

性能是用戶體驗的關鍵部分,因此不能在開發過程結束時事後考慮。 最好通過具有移動意識的結構來管理項目,設計師和開發人員從一開始就合作。

協作審查

對於每個項目,與內部團隊一起審查設計和開發範圍,並定義關鍵績效指標 (KPI) 目標。 這些是基於業務目標表明項目成功的里程碑指標。 鑑於它們的重要性,與性能相關的目標應該出現在此處。

在整個內部團隊審查輸出之前,不要與利益相關者簽署重要的項目里程碑(如藝術指導和線框圖)。 否則,我們發現開發人員可以在實施過程中請求設計調整(以減小頁面大小)。 由於設計已經簽署,此階段的更改可能會造成複雜性,從而開啟進一步的客戶批准。 當開發人員從一開始就參與其中時,他們可以估計接口所需的大小和編程能力,並避免這種情況。

Cyber-Duck team meeting
設計人員和開發人員應一起審查關鍵里程碑,在發送審批之前評估潛在性能。 (大預覽)

績效預算

進入移動思維模式的最佳方式是設置並遵守嚴格的性能預算:為最終網站的速度和規模製定目標。 當團隊朝著明確的高性能目標努力時,他們必須選擇是否實施輪播等昂貴的功能。

具體的業務目標和用戶需求決定了我們是否設置基於數字的績效預算。 例如,我們自己的網站改造旨在顯著改善跨設備的加載時間,並提高移動轉化率。 我們為移動設備設置了不超過 40 個 HTTP 請求或 500KB 數據的嚴格限制。 谷歌分析數據可以告知在改造期間選擇哪些目標,因為歷史互動表明了目標受眾的行為。

通常我們定義頁面大小的目標,移動主頁的限制為 500KB。 服務器請求更難預測,因此我們不太可能設置確切的數字。 這些粗略的指導方針適合我們對客戶項目的需求。 但是 Daniel Mall 有一個很好的實用指南來增加預算的細節:從為 HTML 和 CSS 分配權重,到 JavaScript、圖像和網絡字體。

跳躍後更多! 繼續往下看↓

優化技術

在移動設備上,網站加載速度由客戶端和服務器端因素驅動。 使用解決這兩個因素的有針對性的優化技術可以幫助您滿足為項目設置的性能預算。

客戶端優化

隨著移動環境的多樣化(2014 年有超過 5,000 種獨特的智能手機設備),開發人員對單個設備性能的控制遠低於服務器端因素。 因此,客戶端優化至關重要。 以下技術旨在減少移動設備加載網站所需的處理時間和功率。

優化代碼

許多開發人員陷入了使用 jQuery 編寫來為網站提供動力的陷阱。 但是沒有這樣的事情。 事實上,您正在使用 JavaScript 編寫代碼,同時使用了一個有用的快捷方式和函數庫。 儘管這加快了開發速度——有用,但當您需要將產品快速推向市場時——可能會產生性能成本。 jQuery 庫增加了重量,插件(和函數)的靈活性意味著它們經常會變得臃腫。

這是一個示例,JavaScript 和 jQuery 用於相同的功能。 用純 JavaScript 編寫可以避免將另一個外部庫拉入您的應用程序,並將節省另一個寶貴的 HTTP 請求。

 // jQuery var con = $('#my_container'); con.css('width','75%'); // Plain JavaScript var con = document.getElementById('my_container'); el.style.width = '75%';

您可以使用 Grunt 或 Gulp 等系統或 Prepos、Codekit 或 Hammer 等前端編譯器應用程序進一步優化 CSS 和 JS 文件。 它們通過執行各種任務來減少 HTTP 請求和文件大小:連接文件、編譯 Sass、Less 或 CoffeeScript、Uglify JS(壓縮 JavaScript)以及壓縮/壓縮文件以供生產使用。

優先於首屏

Google Pagespeed Insights(和類似工具)建議優先考慮首屏內容的加載大小和速度。 先分離用於渲染頁面可見部分(首屏)的 CSS; 在頁面呈現後延遲加載其餘樣式。

將頂部 CSS 直接添加到頁眉中可以做到這一點。 但是,請記住,這不會像 CSS 文件的其餘部分一樣被緩存,因此必須限制在關鍵內容中。 多種工具可以幫助您確定要分離的 CSS,包括 Scott Jehl 的 Critical CSS 和 Paul Kinlam 的 Bookmarklet 工具。

優化圖像

考慮到當前對豐富設計的偏好,不幸的是圖像通常是導致頁面過大的罪魁禍首。 但是,如果在導出為正確格式之前和之後對每個都進行優化和壓縮,則以圖像為主導的設計仍然是可能的。 始終確保使用適當的圖像類型。 較重的彩色照片更適合作為 JPEG 文件,而平面彩色圖形則應採用 PNG8 格式。 漸變和更複雜的圖標最適合作為具有 alpha 透明度的 PNG24/32 或 SVG。

Photoshop 和 Fireworks 可以幫助您自定義圖像不同區域的優化級別。 這意味著主要主題可以保持高質量,而其餘主題則經過優化以提高性能。 ImageOptim 和 TinyPNG 等無損圖像壓縮工具可以最大限度地利用文件大小,而不會損失圖像質量。

您還可以使用新的 HTML5 <picture>元素以及圖像的srcsetsize屬性。 該語言的這兩個新增功能可幫助您直接在 HTML 中定義響應式圖像,因此瀏覽器只會下載與給定條件匹配的圖像。

 <picture> <source media="(min-width: 960px)"> <source media="(min-width: 465px)"> <img src="images/picture.png" alt="Picture alt"> </picture>

但是,應謹慎使用此技術。 只有少數瀏覽器支持它:一些現代瀏覽器(如 Safari)、Android 瀏覽器和 IE10/11(及更早版本)不支持。 Polyfill 替代方案可以使此方法在舊版瀏覽器中工作,但這些是必須單獨加載的外部 JavaScript 庫,並且考慮到其他技術可用,可能不值得。 值得考慮您的目標受眾,以及他們將使用什麼技術,看看是否需要額外的 polyfill 重量。

數據 URL 是最後的選擇。 可以將圖像數據轉換為 base64(或 ASCII)編碼字符串並直接嵌入到 CSS 或 HTML 文件中,而不是鏈接到外部圖像文件。 提供了一個簡單的在線轉換工具。 數據 URL 很有幫助,因為它們可以保存 HTTP 請求並且可以更快地傳輸小文件。 但是,如下所示,嵌入式代碼大小比鏈接到外部圖像要大。 增加的長度會使 HTML 和 CSS 文檔更難維護,並且每次都必須重新編碼和嵌入圖像更改。

 <img width="32" height="32" alt="Camera" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAYZJREFUeNrsVsttwzAMtYUAvfrck0fIBukIyQAF5AkaTxB0gowQAR3AWcEbdASfeva1p5YEmIAgZEmWZKeHEhD8k2Ty8fFRZZFg3x/PL3DpYFSOac3T65eZ+qiKNLt4fo52Bker7A7AphoudcBU/PlxCQROM+a+TaGgFo7ei4JaIXonCmqF6J0oqJWiv6MgX5QU1R7LJTKyGBtgtKAP15J+3hWPsYOiyB9lZ7Ui7DarN5aXnzDeGeG2nk1GGKj1Pd3fGL+DoX1SjRz4kXlBcjByuvhhiEzjRMlWlGI9tcEmAT5nl0MjxxpwpKfGFYRASAoMbN7MFLCLDQkbAlsP7BhVKzaXOnKvczYN1+wlJ2KU0PCcM57wasL7jr7xdJgcUtzLWnbVuWdtlAOjYLlLR+qptbmOZMkW40Al8jp4mo51bYoDO/HcOua2nrVRDmh+sqFSO4hoB66ojC9BOhCSAmR3I5y4+jpfrhTcUNAzj3E6VIpniVJqM0p1YJF2/Od14N+BrPYrwAAH54zsDNHtwgAAAABJRU5ErkJggg==" />

自動化 CMS 媒體優化

應用上一節中的資產優化技術意味著我們可以為 BAM 選擇經典的、以圖像為主導的設計,使他們能夠展示新的建築項目攝影。

但是我們還需要讓 BAM 可以自由地更新內容,而無需我們優化每個圖像。 當然,沒有任何解決方案比手動優化更有效,但我們確實設法實現了合理程度的自動化優化。 我們重新配置了他們現有的 Sitefinity CMS 以創造靈活性。 標準選項用於自動調整(和優化)圖像的大小,以適應每個網頁的上下文:

 <thumbnailResizeSettings compositingQuality="HighQuality" interpolationMode="HighQualityBicubic" smoothingMode="HighQuality"> </thumbnailResizeSettings>

Sitefinity 還可以通過使用 URL 參數從 URL 調整圖像大小,甚至可以通過緩存調整大小的圖像來實現更快的渲染,使用以下選項:

 /images/image-opt.jpg?size=480 
BAM website on mobile
BAM 網站的首頁依賴於定期的項目攝影更新,因此我們實施了自動圖像優化。 (大預覽)

大多數 CMS 系統允許某種程度的媒體優化。 例如,您可以定義媒體設置以確保未來用戶只添加適合網站模板的圖像。 這是來自 WordPress 的一個簡單示例。

Wordpress media settings
在 WordPress 中,實施此類媒體設置,以確保未來的圖片上傳適合網站模板。
 // Wordpress example <div class="avatar"> <?php the_thumbnail( 'thumbnail' ); ?> </div>

簡化字體和圖標

字體是用戶體驗和網站或應用程序品牌的重要組成部分,但可能不是用戶的首要任務。 出於這個原因,網絡字體可能是另一個需要優化的因素。

通過延遲字體加載,瀏覽器將以它開始可用的任何字體顯示副本。 這意味著用戶將始終首先獲得內容。 延遲字體加載可以通過分離鏈接到字體文件的 CSS 部分來實現,並在頁面的其餘部分呈現後加載它。 但是請注意,加載網絡字體時,文本可能會短暫閃爍以更改。

同樣,圖標是另一個需要優化的領域,因為它們是需要經常加載的小文件。 您也可以考慮為圖標使用字體文件。 使用 Fontello 之類的服務來選擇各種圖標,並生成限制您選擇的字體文件。 這種技術可以為所有屏幕分辨率創建高質量的矢量圖標,對性能的影響很小。

或者,圖像精靈是一個眾所周知的選項。 它們將圖像組合到一個文件中(僅使用一個請求來加載)並使用背景位置僅顯示設計所需的部分。 Paul Stamatiou 描述了這是如何完成的,並概述了一些限制。

裝載技術

以下技術可避免將網站的全部內容髮送到移動瀏覽器。 相反,通過針對每個斷點進行優化,只下載所需的精確數據。 移動加載速度是 Velocity Drive 網站的一個關鍵考慮因素,該網站提供拖車技術。 JavaScript 庫必須在所有斷點處加載,以測試瀏覽器功能並避免故障。 但我們為每個斷點仔細優化了資產:主頁加載大小在移動設備上僅為 323KB,在大型桌面上上升到 828KB。

使用條件延遲加載技術進一步提高感知頁面速度。 他們分階段加載可見部分,關鍵內容放在首屏。 除非用戶選擇滾動瀏覽內容,否則不會加載在頁面末尾找到的昂貴項目(如圖像)。 這項技術是 Niu Solutions 網站“洞察”部分的關鍵,涵蓋了他們的 IT 創新。 當用戶向下滾動時,我們使用了一個名為 jScroll 的小型 jQuery 插件來加載更多文章。 這是我們如何設置此插件的示例,它只需要指向更多內容的鏈接:

 <a href="articles.php" class="more">Load more</a>
 // Insights javascript $('.insights-container).jscroll({ nextSelector: '.more', loadingHtml: '<p>Loading...</p>' });

預加載技術提供了更多機會。 他們可以通過加載他們接下來可能查看的頁面來預測並為用戶的下一步行動做準備,從而提供更快的體驗。 但是,在改造現有網站時,發現典型的流量結構會更容易,因為您可以在 Google Analytics 上研究行為流漏斗。

從核心體驗中增強

BBC 的 Responsive News 指的是給用戶他們要求的核心體驗,然後評估用戶的環境並相應地增強體驗的想法。 一個簡單的例子是最初加載低分辨率的圖像,然後根據用戶的帶寬顯示高分辨率。

這個想法是漸進增強的一部分,其中 Web 技術被分層以提供跨環境的最佳體驗。 漸進增強可以基於許多不同的因素。 其中包括用戶可以訪問的技術,例如他們的瀏覽器、操作系統和環境(例如互聯網速度)。 在這裡,定義一組必須在功能最差的瀏覽器上工作的基本功能,並且只有在測試瀏覽器是否可以處理它之後才會增加進一步的複雜性。

檢測瀏覽器是否支持 HTML5 和 CSS 功能有助於我們編寫條件代碼以涵蓋所有可能性:在支持時增強和添加功能,同時為不支持的設備和瀏覽器保持安全和簡單。

減少功能測試

合併諸如 Modernizr 或 has.js 之類的功能測試庫是一種常見的推薦做法。 但是太多的開發者實現了整個庫; 他們測試所有功能,即使只需要少量結果來確定是否添加功能。

Tim Kadlec 報告了同一庫(最小化 jQuery 2.1.1)在一系列設備上的解析和執行時間。 這表明與桌面相比,實施這些庫通常會產生更大的移動性能成本(甚至在新舊設備之間)。 我們傾向於定制庫,只測試相關的網站功能。 這將節省時間和寶貴的移動處理能力。

Reducing the size of the Modernizr testing library
定制測試庫至關重要。 這張圖片比較了實現整個庫的大小(頂部),並將測試限制在我們需要的範圍內(底部)。 (大預覽)

服務器端優化

服務器響應時間是網站速度的一個關鍵因素:許多目標是少於 200 毫秒。 但是網絡延遲(數據在服務器和設備之間移動時的延遲)是移動性能的真正瓶頸,使移動用戶的體驗變慢。

這受網絡速度的影響。 根據 Ofcom 的數據,英國流行的 3G 和 4G 網絡的平均下載速度分別為 6.1Mbps 和 15.1Mbps。 有些人將此解釋為對最大網站大小的明確限制。 但實際情況更為複雜,因為速度因覆蓋範圍和環境背景而異。 用戶經常在超出範圍時連接到慢速 Edge (E) 和 GPRS。

有多種技術可用於提高服務器端網站的性能。

緩存、預渲染和靜態內容

動態網頁需要多個數據庫查詢,花費寶貴的時間來處理輸出和格式化數據,然後呈現為瀏覽器可讀的 HTML。 建議緩存之前為該設備呈現的內容。 對於回訪者,它不會從頭開始處理,而是檢查緩存,並且只發送更新。

許多人還選擇像 Handlebars 和 Mustache 這樣的 JavaScript 模板庫來處理 Web 內容。 但是解析和執行 JavaScript 既費力又費時。 移動設備無法像台式計算機那樣快速處理這些模板庫,並且會耗盡它們的處理資源。 在服務器上完全渲染頁面要快得多。 Twitter 早在 2012 年就選擇了這種方法,並在其博客上解釋了其價值。

最近,我們的高級前端開發人員在他的個人作品集中突破了這種技術的界限。 它是使用基於文件的 Statamic CMS 構建的,它剛剛添加了 html_cache 支持。 實施後,此功能將所有頁面的平均加載時間從大約 1.8 秒減少到 225 毫秒。

瀏覽器緩存

粒度優化可以通過防止定期傳輸您知道不經常更新的文件來簡化網站加載。 使用服務器處理程序(如.htaccess文件)來指示瀏覽器存儲哪種類型的內容,以及它們應保留副本的時間。 以下是在 Apache 服務器上實現瀏覽器緩存的方法:

 <IfModule mod_expires.c> ExpiresActive on ExpiresDefault "access plus 1 month" # CSS ExpiresByType text/css "access plus 1 year" # Data interchange ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/ld+json "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType text/xml "access plus 0 seconds" # Favicon and cursor images ExpiresByType image/x-icon "access plus 1 week" # HTML components (HTCs) ExpiresByType text/x-component "access plus 1 month" # HTML ExpiresByType text/html "access plus 0 seconds" # JavaScript ExpiresByType application/javascript "access plus 1 year" # Manifest files ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds" ExpiresByType text/cache-manifest "access plus 0 seconds" # Media ExpiresByType audio/ogg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType video/webm "access plus 1 month" # Web feeds ExpiresByType application/atom+xml "access plus 1 hour" ExpiresByType application/rss+xml "access plus 1 hour" # Web fonts ExpiresByType application/font-woff "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" </IfModule>

內容交付網絡 (CDN)

您可以通過使用像 CloudFlare 這樣的 CDN 以及您通常的託管服務來改善資產加載。 在這裡,靜態內容(如圖像、字體和 CSS)存儲在全球服務器網絡上。 每次用戶請求此內容時,CDN 都會檢測他們的位置並從最近的服務器傳送資產,從而減少延遲。 它通過允許主服務器專注於交付應用程序而不是提供靜態文件來提高速度。

雖然增加了費用,但使用專用 CDN 來提高資產重網站的加載速度。 除了初始設置,CloudFlare 不需要手動配置; 緩存是根據歷史流量和最適合服務的資產為您構建和更新的。 但在實現這一點時要牢記未來的獨立內容管理:確保從 CMS 上傳的所有資產也通過 CDN 透明地提供服務。

CDN 是我們的 Eurofighter Typhoon 網站的最佳選擇,因為引人注目的國防飛機高分辨率照片是展示其能力的關鍵特徵。 在過去的 30 天裡,報告顯示 CloudFlare 節省了 76% 的請求和 48% 的帶寬,從而提高了圖像密集型網站的速度。

Eurofighter website on mobile
我們為 Eurofighter Typhoon 的網站實施了 CDN,以加快高分辨率照片的加載。 (大預覽)

測試

在整個生產過程中,測試是無可替代的。 旨在通過模擬移動體驗和診斷潛在的性能問題來使用各種工具來測試正在進行的工作。

隨著生產的進行,請始終關注數字:從確保正確生成和導出設計資產,到通過瀏覽器上的開發工具檢查頁面文件大小和 HTTP 請求數量。 在這裡,“網絡”選項卡為您提供了加載資源、總文件大小和渲染時間的完整概覽:

Developer Tools - Cyber-Duck Website
開發者工具為我們提供了 Cyber​​-Duck 網站性能指標的完整概覽。 (大預覽)

請注意上面 Chrome Inspector 中時間線右側的藍色和紅色垂直線。 它們分別代表 DOM Ready 和 Page Load 事件。 在窗口底部,它顯示在當前斷點處加載的 HTTP 請求數量和總文件大小。

其他工具包括:

  • WebPagetest 提供了多種測試實時 URL 的選項:從選擇世界各地的任何位置,到塑造特定的 3G 和 4G 連接速度和延遲。 您甚至可以通過幻燈片視圖和視頻體驗網站如何為這些用戶加載。
  • Google 的 Pagespeed Insights 是一種更直觀的介紹性工具,用於分析頁面速度。 它將結果拆分為桌面或移動,並建議改進站點目標區域的技術:指示要緩存的資源或要優化的圖像。

在真實設備上測試

但不要只依賴模擬器。 我們還在各種真實的移動設備上測試整個生產過程中的項目。

創建您自己的設備實驗室或使用 OpenDeviceLabs。 理想情況下,通過避開強大的辦公室 Wi-Fi 來了解真實的用戶體驗。 在您可以從辦公室網絡外部訪問的 Web 服務器(理想情況下與實時服務器相同)中創建一個測試站點。 然後,在擁擠的咖啡店或酒店等典型環境中移動時通過網絡連接進行測試。

移動性能摘要

最重要的是,旨在創建一個可以在移動端平衡美觀和性能的網站,並實現真正的轉化指標。 協作、迭代的性能優化過程將幫助您實現這一目標。

從項目一開始,通過設置嚴格的績效預算,鼓勵內部團隊在移動思維下一起工作。 了解決定移動網站性能的客戶端和服務器端因素。 然後,您可以通過實施我所描述的目標優化技術的混合來實現設定的目標。 當然,在某些情況下,在引人注目的設計、高性能和安全性之間仍然需要權衡取捨。 一個協作的設計和開發團隊可以決定什麼對業務最有利,並與相關的項目經理和利益相關者進行核對。

我們為一家全球技術諮詢公司提供的優化項目展示了這些技術如何結合起來顯著提高加載速度和尺寸。 該項目涉及緩存模板和頁面、優化資產和字體以及減少功能測試等技術。 到目前為止,測試表明渲染和總加載時間已從我們開始工作前的近 4 秒縮短到不到 1.4 秒; 同樣,文件大小已從超過 3MB 減少到 1MB。

關於 SmashingMag 的進一步閱讀

  • 2017 年前端性能清單
  • 為 HTTP/2 做好準備
  • 你需要知道的關於 AMP 的一切
  • 移動瀏覽器的(並非如此)秘密力量