外貿(mào)網(wǎng)站終極速度優(yōu)化細(xì)節(jié)全展示

時(shí)間：2023-04-24 20:57:02 | 來源：網(wǎng)站運(yùn)營

時(shí)間：2023-04-24 20:57:02 來源：網(wǎng)站運(yùn)營

外貿(mào)網(wǎng)站終極速度優(yōu)化細(xì)節(jié)全展示：之前，我們講了如何科學(xué)的評(píng)估一個(gè)網(wǎng)站的加載速度。這次，主要是介紹下我們的優(yōu)化細(xì)節(jié)。

為說明這些問題，我們使用 GTmetrix 平臺(tái)，分別對(duì)四個(gè)網(wǎng)站，進(jìn)行加載速度測(cè)評(píng)。這四個(gè)網(wǎng)站分別是：

• www.dgcrane.com 我們做的一個(gè)起重機(jī)械網(wǎng)站
• www.demagcranes.com 全球起重機(jī)械行業(yè)頂尖企業(yè)
• avada.theme-fusion.com 這個(gè)是 Wordpress 主題市場里面，排名第一的萬能主題 Avada 的網(wǎng)站
• www.google.com 這個(gè)不介紹

測(cè)評(píng)環(huán)境為：

• 測(cè)試平臺(tái) GTmetrix
• 瀏覽器 Chrome
• 網(wǎng)速 3G Mobile (1.6 Mbps/768 Kbps, 200ms) （為放大網(wǎng)頁加載的差異，我們選在較慢網(wǎng)速進(jìn)行測(cè)試。網(wǎng)速飛快的話，網(wǎng)站不做優(yōu)化，打開也不慢，談優(yōu)化是沒有意義的）
• 地點(diǎn) Vancouver, Canada

測(cè)評(píng)報(bào)告：

• Dgcrane網(wǎng)站測(cè)評(píng)報(bào)告 https://gtmetrix.com/reports/www.dgcrane.com/fET3koPk
• Demag網(wǎng)站測(cè)評(píng)報(bào)告 https://gtmetrix.com/reports/www.demagcranes.com/TBl5ONbW
• Avada網(wǎng)站測(cè)試報(bào)告 https://gtmetrix.com/reports/avada.theme-fusion.com/14XS8Csq
• Google網(wǎng)站測(cè)評(píng)報(bào)告 https://gtmetrix.com/reports/www.google.com/4l4JxfUH

對(duì)比報(bào)告：

https://gtmetrix.com/compare/14XS8Csq/4l4JxfUH/TBl5ONbW/fET3koPk

頁面 Critical CSS 優(yōu)化及非阻塞加載 CSS 文件、Js 文件

為最直接的感受這些網(wǎng)站的加載差異，我們對(duì)網(wǎng)站的加載 Vedio 進(jìn)行截圖并對(duì)比。結(jié)果如下：

我們將瀏覽器開始輸出內(nèi)容的時(shí)間點(diǎn)，稱為 First Paint 時(shí)間。

First Paint 時(shí)間除banner大圖外，其他顯示完全的時(shí)間首屏顯示完全時(shí)間

大家看到 First Paint 時(shí)間差距還是挺大的，最快 1.5s 到最慢 6s。是什么原因造成的呢？請(qǐng)看下圖：

其中，最左的綠色豎線代表 First Paint 時(shí)間 （比我們從視頻中統(tǒng)計(jì)的時(shí)間都要早一點(diǎn)，但不影響對(duì)比的結(jié)果）

• Google 加載時(shí)，網(wǎng)頁的 html文件尚未加載完時(shí)，瀏覽器就已經(jīng)將除了圖片之外的內(nèi)容進(jìn)行了輸出。
• Dgcrane 加載時(shí)，網(wǎng)頁的 html文件加載剛完成后，瀏覽器立馬將除了圖片之外的內(nèi)容進(jìn)行了輸出。
• Avada 加載時(shí)，網(wǎng)頁的 html文件加載剛完成后，瀏覽器并沒有立馬對(duì)頁面進(jìn)行輸出。
• Demag 加載時(shí)，網(wǎng)頁的 html文件加載剛完成后，瀏覽器也沒有立馬對(duì)頁面進(jìn)行輸出。

瀏覽器對(duì)網(wǎng)頁的渲染常識(shí)告訴我們，要想讓網(wǎng)頁隨html文件加載完成后立馬輸出，必須滿足三個(gè)條件：

• html 里面包含必備的 css —— 我們稱之為 critical css。
• 網(wǎng)頁的 css 文件，必須進(jìn)行異步加載，就是非阻塞加載。
• 網(wǎng)頁的 Js 文件，也必須進(jìn)行異步或延遲加載，同樣不能阻塞網(wǎng)頁的渲染（Js文件異步加載后的執(zhí)行，雖然會(huì)對(duì)頁面渲染進(jìn)行阻塞，但時(shí)間較短，可忽略不計(jì)）。

這四個(gè)網(wǎng)站中， Google 和 Dgcrane 都使用了 critical css 技術(shù)，并設(shè)法對(duì)頁面全部的 css 文件及 Js 文件進(jìn)行了非阻塞加載。使用 critical css 技術(shù)，必須配合對(duì)頁面全部的 css 文件及 Js 文件進(jìn)行了非阻塞加載。這個(gè)是非常重要的，不然你縱使做了critical css，因?yàn)?css 或是 js 文件的阻塞渲染，效果也出不來。大家經(jīng)常用的淘寶、京東都使用了這些技術(shù)。雖然 critical css 并不是什么高深的東西，但為每個(gè)頁面生成 critical css 還是一個(gè)很麻煩的事情，所以，除非特別在意網(wǎng)站速度的優(yōu)化，一般的網(wǎng)站很少使用。不過，我們做的網(wǎng)站，不用問，這是標(biāo)配。

針對(duì) wordpress 網(wǎng)站。到現(xiàn)在為止，還沒有能良好實(shí)現(xiàn) critical css的插件。插件庫里面，雖然也有很多關(guān)于critical css 的插件，但我們測(cè)試后發(fā)現(xiàn)都不靠譜，沒有實(shí)際的使用價(jià)值。能實(shí)現(xiàn)異步加載全部 css 和 Js 文件的插件有嗎？ 基本也沒有，css 還好說，js 文件要分析他們之間的依賴關(guān)系，事情就復(fù)雜了。

我們?cè)偈褂?Google pagespeed insight 平臺(tái)，對(duì)這四個(gè)網(wǎng)站測(cè)試一下，結(jié)果對(duì)比如下。大家也可以自己測(cè)試，對(duì)比下看看

其中，Google 是雙一百，很厲害；Dgcrane 也不錯(cuò)；Avada 及 Demag 就要差點(diǎn)了?？聪聝?yōu)化建議，最重要的就是，清除首屏內(nèi)容中阻止呈現(xiàn)的 JavaScript 和 CSS。

同樣的結(jié)論，要做到這一點(diǎn)，就一定要使用 critical css，同時(shí)非阻塞加載 Js 文件和 css 文件，這是我們速度優(yōu)化的一個(gè)核心。

圖片優(yōu)化

HTTP Archieve 有個(gè)統(tǒng)計(jì)，圖片內(nèi)容已經(jīng)占到了互聯(lián)網(wǎng)內(nèi)容總量的62%，也就是說超過一半的流量和時(shí)間都用來下載圖片。從性能優(yōu)化的角度看，圖片也絕對(duì)是優(yōu)化的熱點(diǎn)和重點(diǎn)之一，Google Page Speed 或者 Yahoo 的14條性能優(yōu)化規(guī)則無不把圖片優(yōu)化作為重要的優(yōu)化手段。




我們的圖片優(yōu)化細(xì)節(jié)

• 小圖標(biāo)全部矢量化，無鋸齒，不懼放大。這是一個(gè)很小的細(xì)節(jié)，一般網(wǎng)站都忽略了，但我們傾力而為。做個(gè)對(duì)比，我們將網(wǎng)頁都放大4倍，再看 Avada 和 Dgcrane 的 logo 變化；

• 使用 SVG Sprite 技術(shù)，將大部分 svg 文件進(jìn)行合并，減少圖片請(qǐng)求個(gè)數(shù)。想了解 SVG Sprite 技術(shù)，可看這篇介紹；
• 網(wǎng)站上所有的圖片自動(dòng)裁剪，并自動(dòng)優(yōu)化大小。

所謂圖片優(yōu)化，就是在不影響圖片清晰度的前提下，盡量減小圖片體積大小。一般網(wǎng)站，圖片方面主要問題有兩個(gè)：一是圖片體積過大，沒有經(jīng)過優(yōu)化；二是圖片的尺寸和顯示的尺寸不一致。

我們測(cè)評(píng)的這四個(gè)網(wǎng)站，其實(shí)都是優(yōu)化做的不錯(cuò)的網(wǎng)站，在圖片優(yōu)化這方面都做的還不錯(cuò)，但是實(shí)際上，大多數(shù)的外貿(mào)網(wǎng)站，這方面做的都不夠好，你可以通過 Gtmetrix 或是直接使用 Google 的 Pagespeed insihgt 檢測(cè)下。

如果你的網(wǎng)站圖片優(yōu)化問題很大，推薦個(gè)工具：圖片優(yōu)化網(wǎng)站 Tinypng，還有一個(gè)針對(duì) Wordpress 的 插件，可以把網(wǎng)站的圖片優(yōu)化一下。對(duì)比這些插件，我們開發(fā)的圖片優(yōu)化程序更加方便，你不需要在后臺(tái)做任何操作，正常上傳、使用，所有圖片自動(dòng)優(yōu)化：

• 先找個(gè)需要優(yōu)化的圖片，就用建議優(yōu)化的這個(gè)圖片吧。

• 打開后臺(tái)，上傳上去，找到圖片鏈接。http://www.hnxmx.cn/wp-content/uploads/2018/05/demag.jpg

• 再保存下這個(gè)圖片查看，106k 減少到 12k，還可以吧。

字體優(yōu)化

對(duì)比之前說的那些，字體優(yōu)化就比較小眾了，好吧，我們也做了。字體加載常見的兩個(gè)問題：

• 大家在訪問網(wǎng)站的時(shí)候，有沒有遇到過，網(wǎng)站框架都出來了而文字卻不顯示的情況？在 Avada 和 Demag 網(wǎng)站加載過程中，都有這樣的問題。如圖所示

• 還有的時(shí)候，很多外貿(mào)網(wǎng)站使用了Google字體，在國內(nèi)沒法正常打開。

第二個(gè)問題，還是挺常見的。于是，很多人顧及這個(gè)問題，直接放棄了 Google 字體。實(shí)際上，在網(wǎng)站設(shè)計(jì)過程中，字體是非常重要的部分，要解決這個(gè)問題，可以使用第三方源，但我們調(diào)查了很多第三方的源，感覺都不夠穩(wěn)定，例如之前的中科大的源，后來也關(guān)閉了。為穩(wěn)定的輸出，我們將用到的 Google 字體直接進(jìn)行本地化處理。

第一個(gè)問題，解決起來略微麻煩。為讓字體沒有任何延遲，迅速輸出，就要執(zhí)行 FOUT 字體加載方案。邏輯是，當(dāng)網(wǎng)頁輸出時(shí)，如果字體文件還沒有加載完時(shí)，直接使用通用字體進(jìn)行顯示；當(dāng)字體加載完畢后，再對(duì)字體顯示進(jìn)行切換。如何做到 FOUT 字體加載，可參考這篇文章（Github的文章，請(qǐng)科學(xué)上網(wǎng)）。

GTmetrix 列出來的一些優(yōu)化項(xiàng)目

這些項(xiàng)目，從理論上講都可以優(yōu)化加載速度，但實(shí)際操作中，很多項(xiàng)目僅僅是可以改善評(píng)分，但對(duì)實(shí)際的加載速度影響甚微。下面對(duì)這些項(xiàng)目，根據(jù)實(shí)際的操作經(jīng)驗(yàn)，進(jìn)行簡單的說明。

對(duì)優(yōu)化加載速度有明顯作用的

• Enable gzip compression 啟用gzip壓縮——基本的優(yōu)化措施，能大幅優(yōu)化 html、css、js 文件大小，需要做。
• Leverage browser caching 使用瀏覽器緩存——基本的優(yōu)化措施，可顯著提高網(wǎng)頁重復(fù)加載速度，需要做。
• Optimize images 優(yōu)化圖片——基本的優(yōu)化措施，可大幅減小圖片文件大小，需要做。
• Serve scaled images 提供縮放后的圖片——屬于基本的前端優(yōu)化，就是圖片尺寸大小和顯示大小要一致，有影響，需要做。

對(duì)優(yōu)化加載速度作用或不明顯，但屬于基礎(chǔ)的優(yōu)化措施的，盡量做的

• Inline small CSS 內(nèi)嵌小型 CSS——基本的優(yōu)化措施，減少請(qǐng)求個(gè)數(shù)，影響不大。
• Inline small JavaScript 內(nèi)嵌小型 JavaScript——基本的優(yōu)化措施，減少請(qǐng)求個(gè)數(shù)，影響不大。
• Combine external JavaScript 合并外部的 JavaScript——基本的優(yōu)化措施，減少請(qǐng)求個(gè)數(shù)，影響不大。
• Combine images using CSS sprites 使用精靈圖合并小圖片——屬于前端的前端優(yōu)化，有影響，盡量做。
• Combine external CSS 合并外部的CSS——基本的優(yōu)化措施，減少請(qǐng)求個(gè)數(shù)，影響不大。
• Specify image dimensions 指定圖片大小——屬于基本的前端代碼要求，影響不大，但一般需要做。
• Optimize the order of styles and scripts 優(yōu)化樣式表和腳本的排列順序——基本的優(yōu)化措施，有影響，盡量做。
• Prefer asynchronous resources 優(yōu)先使用異步加載資源——基本的優(yōu)化措施，有影響，盡量做。
• Minimize redirects 盡量減少重定向——基本的優(yōu)化措施，有影響，盡量做。
• Minimize DNS lookups 減少DNS查詢次數(shù)——基本的優(yōu)化措施，影響不大。
• Serve resources from a consistent URL 同一資源由同一URl提供——屬于前端代碼優(yōu)化，有影響，應(yīng)該做。
• Specify a character set early 請(qǐng)指定字符集——屬于前端代碼優(yōu)化，應(yīng)該做。
• Avoid CSS @import 避免在CSS中使用import——屬于前端代碼優(yōu)化，應(yīng)該做。
• Avoid bad requests 避免出現(xiàn)錯(cuò)誤的請(qǐng)求——屬于前端代碼優(yōu)化，對(duì)速度影響不一定大，但需要做。
• Use efficient CSS selectors 使用高效的CSS選擇符——屬于前端代碼優(yōu)化，盡量做。

下面幾個(gè)，偏服務(wù)器端設(shè)置

• Specify a Vary: Accept-Encoding header 請(qǐng)指定一個(gè)“Vary: Accept-Encoding”標(biāo)頭——基本的優(yōu)化措施，盡量做。
• Specify a cache validator 請(qǐng)指定緩存有效期——基本的優(yōu)化措施，盡量做。
• Enable Keep Alive 啟用 HTTP Keep-Alive——基本的優(yōu)化措施，盡量做。
• Minimize request size 盡量減少請(qǐng)求頭的大小——基本的優(yōu)化措施，盡量做。

對(duì)優(yōu)化加載速度作用不明顯，不做也不算問題的

• Parallelize downloads across hostnames 通過不同主機(jī)并行下載資源——如果有許多并行下載需求的話，可以試試，外貿(mào)小網(wǎng)站，影響不大。
• Minify HTML 壓縮 HTML——基本的優(yōu)化措施，優(yōu)化 html 文件大小，影響不大，可不做。
• Minify CSS 壓縮 CSS——基本的優(yōu)化措施，優(yōu)化 js 文件大小，影響不大，可不做。
• Minify JavaScript 壓縮 JavaScript——基本的優(yōu)化措施，優(yōu)化 js 文件大小，影響不大，可不做。

其他的項(xiàng)目

• Remove unused CSS 刪除沒用的 CSS——屬于前端代碼優(yōu)化，對(duì)已經(jīng)做好的網(wǎng)站，可操作性不大。
• Put CSS in the document head 將 CSS 放在文檔標(biāo)頭處——基本的優(yōu)化措施，把需要的 css 前置沒問題，但所有的 css 前置，有一定的爭議。
• Remove query strings from static resources 將查詢字符串從靜態(tài)資源中刪除——可能影響緩存，但不一定，視情況而定。

這些項(xiàng)目，大部分對(duì)評(píng)分影響較大，對(duì)實(shí)際的加載速度影響較小。像 Avada 這種優(yōu)秀的 Wordpress 主題，已經(jīng)做的很優(yōu)秀了。當(dāng)然，我們做的同樣優(yōu)秀，中間有幾項(xiàng)評(píng)分略低，是因?yàn)榫W(wǎng)站添加了統(tǒng)計(jì)代碼、Online chat 插件造成的，而這些東西，是不屬于原有網(wǎng)站的，誰加了都是這樣，排除這些影響，評(píng)分會(huì)更優(yōu)秀。

服務(wù)器相關(guān)的優(yōu)化

上面分析的更多的是網(wǎng)頁代碼方面的一些優(yōu)化，下面說下服務(wù)器相關(guān)的優(yōu)化。先對(duì)比下四個(gè)網(wǎng)站的html文件的加載速度：

我們能看到，dgcrane 在文件加載速度上有一定的優(yōu)勢(shì)（其實(shí)，這四個(gè)網(wǎng)站，這塊做的都不錯(cuò)）。這塊主要涉及三方面的因素：服務(wù)器、緩存技術(shù)、CDN。下面逐一分析：

服務(wù)器優(yōu)化——只選大品牌，穩(wěn)定為先

服務(wù)器選取的話，常見的有：Shared Hosting（共享主機(jī)）、VPS（虛擬主機(jī)）、Dedicated Hosting（獨(dú)立主機(jī)）、Managed Hosting 四種，沒有高低之分，也談不上哪個(gè)更好。使用哪一種，主要是視自己的具體情況而定。不要聽人說 VPS 比共享主機(jī)好，就趕緊換，實(shí)際上，很多 VPS 還不如共享主機(jī)好。

• Shared Hosting——共享主機(jī)：就是和別人的網(wǎng)站一起共享一個(gè)主機(jī)。壞處是，容易受別人影響，但實(shí)際上也沒那么嚴(yán)重。好處是，里面的各種設(shè)置都挺全，設(shè)置簡單，當(dāng)然，還有價(jià)格便宜。玩的不多，像 Blue host、Hostgator 什么的，聽說也都不錯(cuò)；
• VPS——虛擬主機(jī)：就是虛擬出來一個(gè)裸機(jī)。好處是，自己獨(dú)占。壞處是什么都沒有，需要自己去捯飭。雖然，配置個(gè)網(wǎng)站服務(wù)器環(huán)境也不是難事兒，不懂的人看著教程，打開putty，慢慢來也能搞定。但，注意你的時(shí)間成本。當(dāng)然，你不在意的話，鼓搗起來，弄不好還會(huì)上癮……品牌的話有：Linode、Vultr、Digital ocean 等，當(dāng)然 Aws ec2 更牛了，但不推薦，配置略復(fù)雜；
• Dedicated Hosting——獨(dú)立主機(jī)：這個(gè)就是真正的一臺(tái)主機(jī)，一般來說都比較貴。不多說，我覺得用這種的都是專業(yè)的，這里的東西，你看是多余的，當(dāng)然也有被忽悠買這種的……一般小網(wǎng)站，根本用不上；
• Managed Hosting：這個(gè)其實(shí)就是托管服務(wù)器，相當(dāng)于 VPS 加上配置管理服務(wù)，比 VPS 要貴點(diǎn)，如 WP Engine。

沒有基礎(chǔ)的，可以是試下共享主機(jī)；有點(diǎn)基礎(chǔ)的，可以試試 VPS。最后，還是推薦 Managed hosting，省心。總之，一定要用大牌子的，不要太在意價(jià)格，為什么呢？一個(gè)網(wǎng)站，用心去做（這里不提那種過于低檔的網(wǎng)站），自己立意、資料準(zhǔn)備，起碼要一個(gè)月；設(shè)計(jì)公司設(shè)計(jì)建設(shè)，起碼一個(gè)月。為這個(gè)網(wǎng)站投入的價(jià)值，起碼也要三萬以上。如果你是SOHO，全自己做，代價(jià)更高，不信，你算算自己的工時(shí)。幾萬都投了，還在意五刀十刀的錢嗎。網(wǎng)站是你的核心，服務(wù)器一定要用大牌子的，穩(wěn)定省心。

我們用的是 Aws ec2，因?yàn)槲覀冇玫氖?Aws cloudfront，CDN節(jié)點(diǎn)和源站都是 Aws 的，他們通過 Aws 的骨干網(wǎng)進(jìn)行連通，更穩(wěn)定、更快速。

靜態(tài)化緩存優(yōu)化——把動(dòng)態(tài)生成的頁面靜態(tài)化，是網(wǎng)站速度優(yōu)化的不二法門

Wordpress 類網(wǎng)站，一般使用相關(guān)的緩存插件。Avada 推薦 W3TC，其他的如 WP Rocket、WP Super Cache 等都不錯(cuò)。這三個(gè)插件，我都用過，本質(zhì)上沒有多大的差異，效果也都差不多，真的差不多。所以，千萬不要沒事?lián)Q來換去，感受哪個(gè)更好，沒有意義。其中：

• W3TC 功能最多，也最麻煩，很多人看不懂，其實(shí)我也看不大懂。
• Wp Super Cache 最簡單，也適合最多的人。
• WP Rocket 復(fù)雜度居中，各方面還是不錯(cuò)的，但不是免費(fèi)的?；ㄥX的話，感覺沒那個(gè)必要。找破解的吧，有風(fēng)險(xiǎn)也不更新，不推薦。

最后還是推薦，最簡單的 Wp super cache。這些緩存插件的機(jī)制都類似，都沒有擺脫對(duì) php 程序的依賴。

如果，有條件的話，還是推薦直接使用服務(wù)器級(jí)別的緩存，不依賴php，服務(wù)器直接響應(yīng)。對(duì)提升網(wǎng)站響應(yīng)時(shí)間，還是有不錯(cuò)幫助的。而且，不局限于 Wordpress 做的網(wǎng)站。常見的技術(shù)有，Proxy Cache、Varnish Cache 、Squid Cache 等。如，Demag 網(wǎng)站用的是 Varnish cache；Dgcrane 網(wǎng)站用的是 Proxy cache；哪個(gè)好呢？Varnish 更專業(yè)一點(diǎn)，Proxy Cache 更簡單一點(diǎn)。對(duì)于一般小網(wǎng)站，哪個(gè)順手用哪個(gè)，差異不大。我們用的是最簡單的 Proxy Cache，并將緩存放入內(nèi)存，速度還是杠杠的。

CDN優(yōu)化——是否要用CDN及如何選取

一般的小外貿(mào)網(wǎng)站，是否使用 CDN，是存在爭議的。我們的建議是：

• 如果你的網(wǎng)站有比較集中針對(duì)的地域，CDN 不用也罷。只要你把服務(wù)器，放的靠近你的目標(biāo)區(qū)域，選個(gè)穩(wěn)定的服務(wù)器，使用好緩存，基本就夠用了。
• 如果你的網(wǎng)站，是面向全球，也沒有什么特殊的針對(duì)性，CDN 還是很需要的。

CDN 品牌有很多，最牛的是 Akamai，但基本不針對(duì)小網(wǎng)站。其他的有 Aws cloudfont、Cloudflare、Maxcdn 等，都不錯(cuò)。選 CDN 的時(shí)候，有一個(gè)錯(cuò)誤的概念就是，全球節(jié)點(diǎn)多的CDN就厲害，忽略了一個(gè)重要的問題，就是CDN的命中率。如果訪問的時(shí)候，總是沒有命中，那你的CDN就基本沒發(fā)揮作用。一般來說，節(jié)點(diǎn)越多，流量較小的話，命中率反而越低。我們的經(jīng)驗(yàn)是，小流量網(wǎng)站 Cloudfont 的命中率還是不錯(cuò)的，能達(dá)到80%（Cloudfront 擁有眾多的區(qū)域節(jié)點(diǎn)，可有效提高緩存命中率），但 Cloudfront 配置比較復(fù)雜，Cloudflare 配置最簡單，Maxcdn 中規(guī)中矩。而且，AWS Cloudfornt CDN 還有一個(gè)缺點(diǎn)，就是針對(duì)國內(nèi)訪問優(yōu)化不夠。雖然有很多亞洲節(jié)點(diǎn)，但由于天朝網(wǎng)絡(luò)的特殊性，國內(nèi)訪問效果并不好，甚至存在部分地方偶爾無法訪問的問題。但其他國際上流行的 CDN，如 Cloudflare 、Maxcdn 等，針對(duì)國內(nèi)訪問效果也不行，也存在類似的問題。好在，外貿(mào)網(wǎng)站主要還是針對(duì)國外訪問。

CDN的使用，還有一個(gè)問題：全站加速 or 動(dòng)靜分離？

• 動(dòng)靜分離，就是只對(duì)網(wǎng)頁里面的靜態(tài)文件進(jìn)行 CDN 加速，一般還需要進(jìn)行設(shè)置專門的二級(jí)域名，還有對(duì)html文件進(jìn)行相應(yīng)的改寫，好處是邏輯簡單，壞處是最重要的html文件沒有得到加速，如 Maxcdn。當(dāng)然，很多大的網(wǎng)站，都是用動(dòng)靜分離進(jìn)行 CDN 加速，而且，使用專門的二級(jí)域名進(jìn)行CDN加速，也有自己好處，但針對(duì)小網(wǎng)站，能讓html文件，也能使用CDN加速，是最重要的。
• 全站加速，就是對(duì)所有文件進(jìn)行加速，包括 html。不需要設(shè)置二級(jí)域名，不需要對(duì) html 文件進(jìn)行更改。但配置起來較復(fù)雜，很多 CDN 也不支持。Aws cloudfront 是沒有問題的；Maxcdn是不支持的；Cloudflare 針對(duì)html的加速，也不好用。

上面的例子中的，Dgcrane 能最快的完成 html 文件加載，就是因?yàn)槲覀兪褂肅DN，進(jìn)行了全站加速。我們的做法是，根據(jù)重點(diǎn)市場選服務(wù)器地址，然后再加 CDN，就是 Aws ec2 + Aws cloudfront。

說了這么多。倒不是說這些點(diǎn)是什么獨(dú)門絕技，其實(shí)都是很普通的優(yōu)化方法。我們只是想說，我們?cè)诤苡眯牡淖鏊俣葍?yōu)化，讓小網(wǎng)站也能擁有，只有大網(wǎng)站才做到的極致的速度優(yōu)化。

最后，做個(gè)廣告，一般我們工作室制作的網(wǎng)站，保守的說：

GTmetrix 測(cè)評(píng) Pagespeed 及 Yslow 分?jǐn)?shù)在85%以上
Webpagetest 測(cè)評(píng) 5A + √ ，speed index 排名前15%
Google 的 pagespeed insight 評(píng)分在90以上

如果你覺的我們做的還可以，有需求，請(qǐng)聯(lián)系我們！