Magento 2 速度優化：研究證明默認功能就足夠了

已發表: 2019-07-05

介紹
測試環境
第 1 章 Magento 設置和服務器配置
- 壓縮包
- 縮小 Js 和 CSS
- 合併 Js 和合併 CSS
- JS 捆綁包
- 高級 JS 包
- HTTP/2
- 將JS代碼移動到頁面底部
- 縮小 HTML
第 2 章附加工具
- 第三方擴展：縮小/合併 JS/CSS/HTML | 捆綁 JS
- 減小圖像大小
- 延遲加載圖片
而不是最後的話
- 關於 Bundle JS
- PS放大器

介紹

據 Statista 稱，預計 2019 年全球手機用戶數量將突破 50 億大關。在這方面，谷歌最重視移動設備上的網站加載速度。這個參數無疑會影響搜索結果的排名。此外，快速的網站加載時間會增加轉化率，因為網站可以避免失去住院用戶。

在本文的第一部分，我們將嘗試弄清楚並展示是否可以使用標準方法加快 Magento 2 頁面加載時間，最重要的是，定義這些方法的有效性。

在第二部分中，我們將深入了解 3rd 方解決方案和方法的有效性。

測試環境

所有測量都將在Chrome 審核中進行，並帶有“適用於具有模擬快速 3G 的移動設備”的限制：

Magento 2 速度優化：研究證明默認功能就足夠了MageWorx Magento 博客

Docker 容器中展開的 Magento 2.3.1 將在審查中使用。這將使我們能夠隔離資源。

我們將使用完全啟用的內置緩存在生產模式下測量性能。

測試將在三個站點頁面上進行：主頁面、產品頁面和類別頁面。對於每個此頁面，我們將運行 3 次審計檢查。將選擇平均測試結果。

由於我們不會運行負載測試——而本文將主要介紹瀏覽器中客戶端的頁面加載時間——因此不會指定 MySQL 和 PHP 版本。我們最感興趣的不是絕對結果，而是各種配置之間的性能差異。

如何使用標準 Magento 和服務器方式加快頁面加載時間？

最重要的是，這可以通過減少發送數據的大小或請求的數量來實現。繼續閱讀以獲得更詳細的見解。

第 1 章 Magento 設置和服務器配置

壓縮包

從下表可以看出，要做的第一件事也是最關鍵的事情——你是對的，它與 Magento 設置無關——是在服務器上啟用壓縮。數據量是決定慢速移動網絡加載速度的關鍵因素。啟用壓縮後，網站的描繪速度會更快。不可避免的缺點包括在服務器端解包導致First CPU Idle參數增加。

沒有 Gzip：

啟用 Gzip 後：

縮小 Js 和 CSS

如果我們嘗試進一步減小傳輸數據的大小會怎樣？首先，讓我們啟用 Minify Js 和 Minify CSS。然後，做一個比較。

所有優化相關的配置都可以在Stores -> Configuration -> Developer 中找到：

該選項卡僅在開發人員模式下可用。在生產模式下，請務必先切換到開發人員模式，使用以下命令：

 > bin/magento deploy:mode:set developer

然後，您將能夠看到開發人員部分，進行必要的配置更改，清除緩存並再次切換回生產模式：

 > bin/magento deploy:mode:set production

在那之後，將進行靜態內容部署。

後綴 min 被添加到 js/css 文件中：

數據量確實減少了！對於主頁，傳輸了 1 Mb 而不是 1.3 Mb。

如果你認為這將我們的參數提高了三分之一，那你就錯了。情況有所好轉，但並不明顯。

我們一次又一次地運行它，但結果是穩定的，即儘管有一定的改進，但它們與傳輸數據量的減少不成比例。

合併 Js 和合併 CSS

現在，假設進一步的改進必須與請求數量的減少有關，而不是與數據量有關，這是合乎邏輯的。

讓我們試一試，啟用 Merge Js 和 Merge CSS 配置。

請注意，Magento 本身將此功能描述為過時的功能：

'我們不建議使用不推薦使用的設置，如合併 JS 和 CSS 文件，因為它們僅設計用於頁面 HEAD 部分中的同步加載 JS。 使用這種技術可能會導致捆綁和 requireJS 邏輯無法正常工作。

儘管如此，讓我們試一試：

請求數量的變化並不令人印象深刻，是嗎？

雖然“第一次有內容的繪畫”和“第一次有意義的繪畫”等參數已經得到改進，但肯定還有改進的空間。

JS 捆綁包

讓我們嘗試一下 JS Bundle 技術，其中 js 文件基於固定大小進行捆綁。這使我們能夠在整體數據量保持不變的情況下管理請求數量。

結果令人失望。問題是內置的 Magento 機制為所有站點收集 js-bundle，即實際上所有 js 將在任何頁面上一直收集。這將導致頁面量急劇增加。

是的，您可以從包中排除某些 js 文件（其中一些默認情況下被排除）。但是，您不能針對特定頁面執行此操作。

Magento 也不建議在生產模式下啟用 Bundle JS。似乎這是第二個可用的選項，但實際上 - 不是真的。

高級 JS 包

Magento 認識到 Bundles JS 的困難，但提供避免自己解決這些問題。在官方指南中，您將找到一個示例，說明如何在當前頁面上僅捆綁所需的 js 文件。是的，這比更改配置中的參數要困難一些。對於 Advanced Bundle，您必須使用 Nodejs、Require JS、Phantom JS。當然，這不是一個現成的解決方案。但是在測試了所提供的機制之後，我們將從理論上了解 Advanced Bundle 如何加快頁面加載時間。

建議的機制在手動模式下工作，而不是在框架內部而是在框架外部。特殊工具分析加載在頁面上的 js 文件並將它們收集到一個包中，可以是通用包，也可以是頁麵類型包的特定包。

最終，收集到的包被寫入 require js 並由它加載到頁面上：

在每種頁麵類型（自然，為其收集了一個捆綁包）上，都會加載一個特定的捆綁包。這將是主頁的示例：

看起來，在我們減少了請求的數量之後，額外的數據不會被加載，性能必須顯著提高……但是對於 SEO First Contentful Paint 和 First Meaningful Paint 的關鍵時間也顯著增加。那講得通。在加載捆綁文件之前，不會進行跟踪。

________________

好像我們已經盡力了，或者沒有？我想現在是繼續前進並嘗試當前技術的時候了。

HTTP/2

讓我們在 Magento 中禁用 Bundle JS 並在服務器上啟用 HTTP/2。
在我們的例子中，它只是 nginx。我們所做的只是更改了幾行 ― 添加了對 443 端口的 http2 支持。

 listen 80; listen 443 ssl http2; server_name md201.local; ssl_certificate /etc/nginx/ssl-certificates/md201.local/localhost.crt; ssl_certificate_key /etc/nginx/ssl-certificates/md201.local/localhost.key;

為了在 Chrome 中進行測試，我們需要將自簽名證書添加到 Trusted Root Authority（在我們的例子中是 MacOS）。

下面是 HTTP/2 連接的樣子：

這無一例外地改善了所有參數！這完全取決於 HTTP/2 技術的特性。

減少訪問延遲以加快頁面加載時間，特別是通過：

HTTP 標頭中的數據壓縮，
在服務器端使用 puch 技術，
請求傳送，
解決頭部 HTTP 1.0/1.1 協議阻塞，
在一個 TCP 連接中多路復用多個請求。

使用 HTTP/2，大量請求不會成為問題，因為沒有為每個請求打開 TCP 連接。

在大多數實際瀏覽器中，最新版本的 nginx 和 apache 都支持 HTTP/2：https://caniuse.com/#search=http2

對此，您可能會有以下疑問：如果我們將 Advanced JS Bundle 和 HTTP/2 結合起來會怎樣？

從理論上講，它不會加快頁面加載時間，因為 HTTP/2 在加載大型捆綁 js 文件方面沒有顯著優勢。但是要確定它，讓我們檢查一下。

正如我們所見，在 HTTP/2 連接中使用 Advanced Bundle JS 並不能提高速度。

嘗試微調捆綁包是一個耗時的過程。它要求在每次 Magento 或第 3 方擴展（在前端添加 JS）更新之後，以及在添加連接其特定 js 或不使用其他產品 js 的新產品類型之後重新生成捆綁包類型。基本上，還有更多的細微差別需要考慮。在我看來，如果你有可能使用 HTTP/2，轉向 Bundle JS 不會產生顯著的結果。

還有哪些其他的速度優化方法？是否可以使頁面加載時間更快？

_______________

將JS代碼移動到頁面底部

老實說，我們計劃從 3rd 方供應商那裡審查這種優化手段，但是當本文處於創建過程中時，Magento 2.3.2 已經發布。此功能已添加到新版本中（默認情況下禁用）。

啟用後，一些 js 文件會從 <head> 部分傳輸到 </body> 的末尾，理論上這應該會加快網站可視化的開始。

這就是我們一開始的情況：

這是啟用它後我們得到的：

為了運行這樣的測試，我們必須將我們的 Magento 版本更新到 2.3。連接文件的數量和大小已更改。因此，測試結果可能很粗糙。為了了解 Magento 版本本身對結果的影響，我們首先將 M2.3.1 與 M2.3.2 版本與HTTP/2 + Minify JS/CSS組合進行了比較——得到的結果幾乎相等，並沒有超過測量的不確定性。

正如我們所見， First Contentful Paint和First Meaningful Paint在所有情況下都提高了 10-15%。

在 Magento 速度優化的所有概述方法中，以下變體似乎處於領先地位：

Gzip + Minify JS/CSS + HTTP/2 +將 JS 代碼移動到頁面底部

讓我們將其視為一個起點並進一步發展。以前，我們只玩過僅涉及 JS/CSS 的配置。因此，有一些方面可以改進。

縮小 HTML

設置可以在這裡找到：

主頁的 HTML 部分——HTML Minify 之前為 89 Kb，在服務器上壓縮後為 88,7——12,2 對 12,1 Kb。

類別頁面的 HTML 部分——HTML Minify 之前 155 Kb 和之後 100 Kb / 在服務器上進行壓縮——16,8 對 15,2 Kb。

產品頁面的 HTML 部分——HTML Minify 之前為 80 Kb，之後為 67，在服務器上進行壓縮——15 對 14,1 Kb。

由於使用了服務器端的壓縮，1-2 Kb 的差異並不重要，並且在審計缺陷範圍內。

第 2 章附加工具

第三方擴展：縮小/合併 JS/CSS/HTML | 捆綁 JS

同時，為 JS/CSS/HTML 和捆綁 JS 提供 3rd-party 解決方案並沒有多大意義。即使您獲得了額外的壓縮結果，它們在前端的份額也將被限制為 1%。作為回報，您將在系統中獲得一個或多個 Magento 擴展。它們的存在和算法的運行需要額外的資源，並且通常會增加系統故障的風險。如果您不確定潛在收益是否超過相關風險，建議您停止使用。

如果您知道任何通過壓縮和捆綁大大提高加載速度的第三方解決方案，我們鼓勵您在評論中分享或直接通過[email protected]通知我們。我們很樂意對其進行調查

現在，讓我們嘗試使用 Magento 默認情況下不可用的方法進行改進。

減小圖像大小

在網絡上使用圖像始終是質量和圖像文件大小之間的折衷。

我們主要關心的是在不損失質量的情況下減小圖像尺寸。好吧，使用默認的 Magento 功能，確實可以減小圖像大小。但圖像質量將受到嚴重影響。

讓我們減小標準圖像的大小，Magento 根據配置轉換和調整大小，即我們最感興趣的是位於 magento_root_directory/pub/media/catalog/product/cache 中的圖像。

Magento 配置可以在這裡找到：

首先，讓我們嘗試手動操作並使用 jpegoptim 實用程序。旨在加速 Magento 的多個模塊（包括付費模塊）由該實用程序提供支持。

除非我們降低圖像質量，否則緩存中的圖像沒有結果：

這似乎有些不對勁。出於測試目的，我們將其應用於原始圖像，實際上並沒有顯示在頁面上。我們確實取得了一定的成果，雖然微不足道：

尋求自動化解決方案怎麼樣？

讓我們試試下面的免費圖像優化器：https://github.com/justbetter/magento2-image-optimizer。

我們已經安裝了擴展使用的所有提供的實用程序：

JpegOptim
優化
量化 2
SVGO
gifsicle

JPEG 的圖像壓縮設置已設置為 80。這對應於默認的 Magento 設置。然後，我們對所有媒體目錄進行了優化。

壓縮前的完整媒體目錄大小為 353 Mb，之後為 ― 340,1 Mb

media/catalog/product/cache 目錄大小為 194.7 Mb，壓縮後未更改。

我們發現這些解決方案既方便又有用，特別是如果您在將圖像上傳到您的站點之前沒有準備好圖像。

但是，在減少產品和類別頁面上的整體圖像大小時，並沒有取得顯著的改進。

可能，其他圖像格式主要用於您的情況。因此，結果可能更加重要。

我們故意不在這裡概述 webp 圖像格式，因為蘋果瀏覽器不支持這種格式：https://caniuse.com/#feat=webp。

____________________

好吧，如果我們不能顯著減小圖像文件大小，讓我們嘗試只為可見區域上傳它們。

延遲加載圖片

讓我們嘗試我們遇到的第一個免費的 3rd 方解決方案 ― Magento 2 Lazy Loading。

和以前一樣，我們對產品、類別和主頁進行了審核。

沒有取得重大改變。變化在測量的不確定性範圍內。

這可能是因為示例數據頁面非常輕量，並且所有主要圖像都位於可見區域中。

產品描述不包含圖像。該類別根本沒有描述。
讓我們做最簡單的方法，在 pager 的類別頁面上簡單地增加產品數量（包括加載圖像的數量）——首先從 9 增加到 30，然後增加到 48 並列出結果。

結果是顯而易見的。初始加載時不可見的網站區域中的圖像越大（數量和大小），優勢就越顯著。從優化的角度來看，該功能肯定是一個有用的功能，儘管它確實存在某些可用性缺點。

_________________

而不是最後的話

我們概述了標準 Magento 功能和一些允許優化頁面加載性能的 3rd-party 解決方案。

儘管進行了研究，但我們發現很難得出確切的結論，因為所有網站都是獨一無二的，並且有自己獨一無二的特點。因此，適用於一個站點的解決方案總是有一定程度的可能性不會對其他站點產生任何影響。

然而，最有用的具有有意義效果的功能是默認 Magento 的Gzip + Minify JS/CSS + HTTP/2 + Image Lazy Loading

關於 Bundle JS

因此，如果沒有額外的個性化站點微調，來自 3rd 方擴展開發人員的此捆綁包的高級版本將很難顯著提高加載速度。

肯定有更多的方法可以幫助增加加載時間。但是，其中許多並不是萬能的解決方案。例如，來自世界不同國家的站點訪問者的相關性和物理服務器/服務器位置也很重要。將站點傳輸到服務器是有意義的，對於大多數站點用戶來說，從服務器傳輸數據會更快/使用 CDN 傳輸靜態文件。如果網站訪問者主要來自一個地區，那麼您可以嘗試使用 Varnish 緩存靜態文件：https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish-magento.html#緩存靜態文件。

最終，一種從根本上改變情況並使您的網站在移動設備上最大速度的方法是使用 AMP 技術。

PS放大器

（https://amp.dev/about/websites）

對於手持設備，通過 Google SERP，用戶不會訪問您的站點，而是訪問存儲在 Google 服務器上的緩存版本。初始加載將像閃電一樣快。這樣的網站自然會在 SERP 中用閃電錶示。

這項技術不是一種簡單的技術，它假設只使用自己的 amp js 庫。此外，您有機會擁有一個單獨的頁面版本，它不會以任何方式與您當前的主題相關聯。

這可能是一個艱難的選擇。一方面，這一切都是為了提高加載速度和轉化率。另一方面，AMP 技術施加了限制，即您只能從 AMP 庫中使用 js 和 HTML。結果，功能受到限制。