Cloudflare：為什么移動(dòng)性能很重要？

為什么移動(dòng)性能很重要？

網(wǎng)絡(luò)正在移動(dòng)化。Statista 的數(shù)據(jù)顯示，全球 51％ 的網(wǎng)頁瀏覽量來自于移動(dòng)設(shè)備。在亞洲和非洲等一些地區(qū)，這個(gè)百分比還要更高，而且不管是哪個(gè)地區(qū)，每年都有穩(wěn)步增長(zhǎng)。

主流搜索引擎意識(shí)到了這一趨勢(shì)，因而優(yōu)先考慮移動(dòng)端加載時(shí)間較短的站點(diǎn)。移動(dòng)用戶的帶寬可能有限，但仍然希望快速找到信息。這些用戶往往不夠耐心，因此加載緩慢的網(wǎng)站具有較高的跳出率。（“跳出率”是僅瀏覽單個(gè)頁面后即離開的網(wǎng)站訪問者的百分比）。

Google 和其他網(wǎng)站速度權(quán)威機(jī)構(gòu)認(rèn)定，移動(dòng)站點(diǎn)的最長(zhǎng)加載時(shí)間應(yīng)為三秒左右。三秒之后，用戶留存率會(huì)急劇下降。搜索引擎將“懲罰”加載緩慢的站點(diǎn)，進(jìn)一步降低它們?cè)谒阉鹘Y(jié)果中的排名，特別是面對(duì)移動(dòng)用戶時(shí)。

移動(dòng)連接三秒加載限制不是非常寬容，但有一些切實(shí)可行的策略來縮短移動(dòng)加載時(shí)間。

如何提高移動(dòng)性能

有諸多因素會(huì)影響移動(dòng)性能，因此可以通過多種策略和最佳實(shí)踐來縮短加載時(shí)間。

最大程度縮減文件大小和文件數(shù)量

為確保加載時(shí)間更快，所有網(wǎng)站文件都應(yīng)制作得盡可能小。圖像通常是請(qǐng)求的文件中最大的，可以通過使用圖像優(yōu)化器或轉(zhuǎn)換為輕量級(jí)圖像格式（例如 SVG）來縮小圖像。

也可以通過極簡(jiǎn)化來縮小 HTML、JavaScript 和 CSS 文件的大小。代碼極簡(jiǎn)化意味著從代碼中刪除所有空白和注釋，并以盡可能緊湊的方式進(jìn)行重組。這會(huì)將文件大小減至最小。盡管會(huì)使代碼幾乎對(duì)人類不可讀，但 Web 瀏覽器仍然可以正常執(zhí)行代碼。

除了創(chuàng)建更小的文件外，總體文件數(shù)量也應(yīng)保持最少。加載網(wǎng)站時(shí)每多一個(gè)文件都意味著請(qǐng)求和響應(yīng)變多，而這些往返都會(huì)延長(zhǎng)加載時(shí)間。站點(diǎn)上若有多個(gè) JavaScript 和 CSS 文件，則應(yīng)將所有 JavaScript 代碼合并為一個(gè)文件，CSS 同樣如此。如果頁面只需很少的 JavaScript 或 CSS，那么使用內(nèi)聯(lián)樣式* 可以顯著縮短加載時(shí)間。

*通常，Web 開發(fā)人員在不同的文件中編寫 HTML、JavaScript 和 CSS 代碼。使用稱為“內(nèi)聯(lián)樣式”的技巧，開發(fā)人員可以將 JavaScript 和/或 CSS 代碼與 HTML 寫在同一文件中。

在邊緣緩存資源

通常，當(dāng)用戶訪問網(wǎng)站時(shí)，用戶的設(shè)備必須與 Web 服務(wù)器通信以獲取網(wǎng)站文件。如果 Web 服務(wù)器位于舊金山，而用戶位于伯克利（10 英里外），則速度應(yīng)該很快。但是，如果用戶在東京（5,000 英里外）呢？這意味著每個(gè)請(qǐng)求和響應(yīng)都必須穿越數(shù)千英里，大幅加劇網(wǎng)站加載的延遲。

緩解此問題的常用方法是利用內(nèi)容交付網(wǎng)絡(luò)（CDN）。全局 CDN 在網(wǎng)絡(luò)邊緣緩存內(nèi)容。也就是說，CDN 擁有許多緩存服務(wù)器，遍布于世界各地的數(shù)據(jù)中心。任何接入 Internet 的人都不會(huì)離數(shù)據(jù)中心太遠(yuǎn)。這些數(shù)據(jù)中心服務(wù)器可以與源站 Web 服務(wù)器通信以緩存網(wǎng)站數(shù)據(jù)，以便訪問使用 CDN 的網(wǎng)站的用戶可以從當(dāng)?shù)氐臄?shù)據(jù)中心獲取網(wǎng)站文件。這可確保用戶擁有快速的請(qǐng)求響應(yīng)時(shí)間，無論他們身在何處。

緩存 API 調(diào)用

API 調(diào)用是從外部資源獲取數(shù)據(jù)的 HTTP 請(qǐng)求。例如，諸如 Rotten Tomatoes 之類的電影評(píng)論網(wǎng)站可能會(huì)對(duì) Fandango 這樣的票務(wù)服務(wù)進(jìn)行 API 調(diào)用，以便瀏覽 Rotten Tomatoes 的用戶可以查看當(dāng)?shù)氐碾娪胺庞硶r(shí)間。雖然 API 調(diào)用有助于打造可靠的體驗(yàn)并減少多余的工作，但也會(huì)帶來新的 HTTP 請(qǐng)求，而這會(huì)減慢加載時(shí)間。

可以緩存 API 調(diào)用，最大程度減少這些額外的 HTTP 請(qǐng)求。在上面的電影放映時(shí)間示例中，Rotten Tomatoes 每天只需獲取一次洛杉磯電影放映時(shí)間。他們可以將站點(diǎn)配置為每天緩存一次這個(gè) API 調(diào)用。這樣，如果每天有 10,000 個(gè)洛杉磯用戶訪問 Rotten Tomatoes，只有第一個(gè)用戶必須等待對(duì) Fandango 的 API 調(diào)用。

優(yōu)先對(duì)待可見內(nèi)容

在加載網(wǎng)頁時(shí)，用戶立即看到的通常只是冰山一角；他們必須向下滾動(dòng)才能看到頁面的其余部分。滾動(dòng)之前出現(xiàn)在用戶屏幕上的內(nèi)容稱為“首屏”內(nèi)容。Web 開發(fā)人員在編寫代碼時(shí)，應(yīng)采用首屏內(nèi)容始終最先加載的方式。有一種技巧可以實(shí)現(xiàn)這個(gè)目標(biāo)，稱為延遲加載，它通過在用戶向下滾動(dòng)頁面的同時(shí)動(dòng)態(tài)加載非首屏內(nèi)容來工作。

避免重定向

由于各種原因，一些網(wǎng)站會(huì)在頁面加載時(shí)創(chuàng)建重定向。例如，改換過名稱或或品牌的網(wǎng)站上通常使用 301 重定向。這種做法應(yīng)盡可能避免，因?yàn)橹囟ㄏ驎?huì)消耗寶貴的加載時(shí)間。

隨著移動(dòng)瀏覽漸成趨勢(shì)，擁有高性能移動(dòng)站點(diǎn)變得越來越重要?？焖俚囊苿?dòng)站點(diǎn)將獲得更高的參與度和轉(zhuǎn)換率，其 SEO 也會(huì)加強(qiáng)。網(wǎng)站所有者應(yīng)實(shí)施以上部分或全部策略，從而獲得這些益處。