外贸网站速度优化细节全展示

之前，我们讲了如何科学的评估一个网站的加载速度。这次，主要是介绍下我们的优化细节。

为说明这些问题，我们使用 GTmetrix 平台，分别对四个网站，进行加载速度测评。这四个网站分别是：

• www.dgcrane.com 我们做的一个起重机械网站
• www.demagcranes.com 全球起重机械行业企业
• avada.theme-fusion.com 这个是 Wordpress 主题市场里面，的主题 Avada 的网站
• www.google.com 这个不介绍

测评环境为：

• 测试平台 GTmetrix
• 浏览器 Chrome
• 网速 3G Mobile (1.6 Mbps/768 Kbps, 200ms) （为放大网页加载的差异，我们选在较慢网速进行测试。网速飞快的话，网站不做优化，打开也不慢，谈优化是没有意义的）
• 地点 Vancouver, Canada

测评报告：

• Dgcrane网站测评报告 https://gtmetrix.com/reports/www.dgcrane.com/fET3koPk
• Demag网站测评报告 https://gtmetrix.com/reports/www.demagcranes.com/TBl5ONbW
• Avada网站测试报告 https://gtmetrix.com/reports/avada.theme-fusion.com/14XS8Csq
• Google网站测评报告 https://gtmetrix.com/reports/www.google.com/4l4JxfUH

对比报告：

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

页面 Critical CSS 优化及非阻塞加载 CSS 文件、Js 文件

为直接的感受这些网站的加载差异，我们对网站的加载 Vedio 进行截图并对比。结果如下：

我们将浏览器开始输出内容的时间点，称为 First Paint 时间。

大家看到 First Paint 时间差距还是挺大的，快 1.5s 到慢 6s。是什么原因造成的呢？请看下图：

其中，左的绿色竖线代表 First Paint 时间 （比我们从视频中统计的时间都要早一点，但不影响对比的结果）

• Google 加载时，网页的 html文件尚未加载完时，浏览器就已经将除了图片之外的内容进行了输出。
• Dgcrane 加载时，网页的 html文件加载刚完成后，浏览器立马将除了图片之外的内容进行了输出。
• Avada 加载时，网页的 html文件加载刚完成后，浏览器并没有立马对页面进行输出。
• Demag 加载时，网页的 html文件加载刚完成后，浏览器也没有立马对页面进行输出。

浏览器对网页的渲染常识告诉我们，要想让网页随html文件加载完成后立马输出，必须满足三个条件：

• html 里面包含必备的 css —— 我们称之为 critical css。
• 网页的 css 文件，必须进行异步加载，就是非阻塞加载。
• 网页的 Js 文件，也必须进行异步或延迟加载，同样不能阻塞网页的渲染（Js文件异步加载后的执行，虽然会对页面渲染进行阻塞，但时间较短，可忽略不计）。

这四个网站中， Google 和 Dgcrane 都使用了 critical css 技术，并设法对页面全部的 css 文件及 Js 文件进行了非阻塞加载。使用 critical css 技术，必须配合对页面全部的 css 文件及 Js 文件进行了非阻塞加载。这个是非常重要的，不然你纵使做了critical css，因为 css 或是 js 文件的阻塞渲染，效果也出不来。大家经常用的淘宝、京东都使用了这些技术。虽然 critical css 并不是什么高深的东西，但为每个页面生成 critical css 还是一个很麻烦的事情，所以，除非特别在意网站速度的优化，一般的网站很少使用。不过，我们做的网站，不用问，这是标配。

针对 wordpress 网站。到现在为止，还没有能良好实现 critical css的插件。插件库里面，虽然也有很多关于critical css 的插件，但我们测试后发现都不靠谱，没有实际的使用价值。能实现异步加载全部 css 和 Js 文件的插件有吗？ 基本也没有，css 还好说，js 文件要分析他们之间的依赖关系，事情就复杂了。

我们再使用 Google pagespeed insight 平台，对这四个网站测试一下，结果对比如下。大家也可以自己测试，对比下看看

其中，Google 是双一百，很厉害；Dgcrane 也不错；Avada 及 Demag 就要差点了。看下优化建议，重要的就是，首屏内容中阻止呈现的 JavaScript 和 CSS。

同样的结论，要做到这一点，就一定要使用 critical css，同时非阻塞加载 Js 文件和 css 文件，这是我们速度优化的一个核心。

图片优化

HTTP Archieve 有个统计，图片内容已经占到了互联网内容总量的62%，也就是说超过一半的流量和时间都用来下载图片。从性能优化的角度看，图片也是优化的热点和之一，Google Page Speed 或者 Yahoo 的14条性能优化规则无不把图片优化作为重要的优化手段。

我们的图片优化细节

• 小图标全部矢量化，无锯齿，不惧放大。这是一个很小的细节，一般网站都忽略了，但我们倾力而为。做个对比，我们将网页都放大4倍，再看 Avada 和 Dgcrane 的 logo 变化；

• 使用 SVG Sprite 技术，将大部分 svg 文件进行合并，减少图片请求个数。想了解 SVG Sprite 技术，可看这篇介绍；
• 网站上所有的图片自动裁剪，并自动优化大小。

所谓图片优化，就是在不影响图片清晰度的前提下，尽量减小图片体积大小。一般网站，图片方面主要问题有两个：一是图片体积过大，没有经过优化；二是图片的尺寸和显示的尺寸不一致。

我们测评的这四个网站，其实都是优化做的不错的网站，在图片优化这方面都做的还不错，但是实际上，大多数的外贸网站，这方面做的都不够好，你可以通过 Gtmetrix 或是直接使用 Google 的 Pagespeed insihgt 检测下。

如果你的网站图片优化问题很大，推荐个工具：图片优化网站 Tinypng，还有一个针对 Wordpress 的 插件，可以把网站的图片优化一下。对比这些插件，我们开发的图片优化程序更加方便，你不需要在后台做任何操作，正常上传、使用，所有图片自动优化：

• 先找个需要优化的图片，就用建议优化的这个图片吧。

• 打开后台，上传上去，找到图片链接。http://www.hnxmx.cn/wp-content/uploads/2018/05/demag.jpg

• 再保存下这个图片查看，106k 减少到 12k，还可以吧。

字体优化

对比之前说的那些，字体优化就比较小众了，好吧，我们也做了。字体加载常见的两个问题：

• 大家在访问网站的时候，有没有遇到过，网站框架都出来了而文字却不显示的情况？在 Avada 和 Demag 网站加载过程中，都有这样的问题。如图所示

• 还有的时候，很多外贸网站使用了Google字体，在国内没法正常打开。

第二个问题，还是挺常见的。于是，很多人顾及这个问题，直接放弃了 Google 字体。实际上，在网站设计过程中，字体是非常重要的部分，要解决这个问题，可以使用第三方源，但我们调查了很多第三方的源，感觉都不够稳定，例如之前的中科大的源，后来也关闭了。为稳定的输出，我们将用到的 Google 字体直接进行本地化处理。

个问题，解决起来略微麻烦。为让字体没有任何延迟，迅速输出，就要执行 FOUT 字体加载方案。逻辑是，当网页输出时，如果字体文件还没有加载完时，直接使用通用字体进行显示；当字体加载完毕后，再对字体显示进行切换。如何做到 FOUT 字体加载，可参考这篇文章（Github的文章，估计需要翻墙访问）。

GTmetrix 列出来的一些优化项目

这些项目，从理论上讲都可以优化加载速度，但实际操作中，很多项目仅仅是可以改善评分，但对实际的加载速度影响甚微。下面对这些项目，根据实际的操作经验，进行简单的说明。

对优化加载速度有明显作用的

• Enable gzip compression 启用gzip压缩——基本的优化措施，能大幅优化 html、css、js 文件大小，需要做。
• Leverage browser caching 使用浏览器缓存——基本的优化措施，可显著提高网页重复加载速度，需要做。
• Optimize images 优化图片——基本的优化措施，可大幅减小图片文件大小，需要做。
• Serve scaled images 提供缩放后的图片——属于基本的前端优化，就是图片尺寸大小和显示大小要一致，有影响，需要做。

对优化加载速度作用或不明显，但属于基础的优化措施的，尽量做的

• Inline small CSS 内嵌小型 CSS——基本的优化措施，减少请求个数，影响不大。
• Inline small JavaScript 内嵌小型 JavaScript——基本的优化措施，减少请求个数，影响不大。
• Combine external JavaScript 合并外部的 JavaScript——基本的优化措施，减少请求个数，影响不大。
• Combine images using CSS sprites 使用精灵图合并小图片——属于前端的前端优化，有影响，尽量做。
• Combine external CSS 合并外部的CSS——基本的优化措施，减少请求个数，影响不大。
• Specify image dimensions 指定图片大小——属于基本的前端代码要求，影响不大，但一般需要做。
• Optimize the order of styles and scripts 优化样式表和脚本的排列顺序——基本的优化措施，有影响，尽量做。
• Prefer asynchronous resources 优先使用异步加载资源——基本的优化措施，有影响，尽量做。
• Minimize redirects 尽量减少重定向——基本的优化措施，有影响，尽量做。
• Minimize DNS lookups 减少DNS查询次数——基本的优化措施，影响不大。
• Serve resources from a consistent URL 同一资源由同一URl提供——属于前端代码优化，有影响，应该做。
• Specify a character set early 请指定字符集——属于前端代码优化，应该做。
• Avoid CSS @import 避免在CSS中使用import——属于前端代码优化，应该做。
• Avoid bad requests 避免出现错误的请求——属于前端代码优化，对速度影响不一定大，但需要做。
• Use efficient CSS selectors 使用的CSS选择符——属于前端代码优化，尽量做。

下面几个，偏服务器端设置

• Specify a Vary: Accept-Encoding header 请指定一个“Vary: Accept-Encoding”标头——基本的优化措施，尽量做。
• Specify a cache validator 请指定缓存有效期——基本的优化措施，尽量做。
• Enable Keep Alive 启用 HTTP Keep-Alive——基本的优化措施，尽量做。
• Minimize request size 尽量减少请求头的大小——基本的优化措施，尽量做。

对优化加载速度作用不明显，不做也不算问题的

• Parallelize downloads across hostnames 通过不同主机并行下载资源——如果有许多并行下载需求的话，可以试试，外贸小网站，影响不大。
• Minify HTML 压缩 HTML——基本的优化措施，优化 html 文件大小，影响不大，可不做。
• Minify CSS 压缩 CSS——基本的优化措施，优化 js 文件大小，影响不大，可不做。
• Minify JavaScript 压缩 JavaScript——基本的优化措施，优化 js 文件大小，影响不大，可不做。

其他的项目

• Remove unused CSS 删除没用的 CSS——属于前端代码优化，对已经做好的网站，可操作性不大。
• Put CSS in the document head 将 CSS 放在文档标头处——基本的优化措施，把需要的 css 前置没问题，但所有的 css 前置，有一定的争议。
• Remove query strings from static resources 将查询字符串从静态资源中删除——可能影响缓存，但不一定，视情况而定。

这些项目，大部分对评分影响较大，对实际的加载速度影响较小。像 Avada 这种的 Wordpress 主题，已经做的很了。当然，我们做的同样，中间有几项评分略低，是因为网站添加了统计代码、Online chat 插件造成的，而这些东西，是不属于原有网站的，谁加了都是这样，排除这些影响，评分会更。

服务器相关的优化

上面分析的更多的是网页代码方面的一些优化，下面说下服务器相关的优化。先对比下四个网站的html文件的加载速度：

我们能看到，dgcrane 在文件加载速度上有一定的优势（其实，这四个网站，这块做的都不错）。这块主要涉及三方面的因素：服务器、缓存技术、CDN。下面逐一分析：

服务器优化——只选大品牌，稳定为先

服务器选取的话，常见的有：Shared Hosting（共享主机）、VPS（虚拟主机）、Dedicated Hosting（独立主机）、Managed Hosting 四种，没有高低之分，也谈不上哪个更好。使用哪一种，主要是视自己的具体情况而定。不要听人说 VPS 比共享主机好，就赶紧换，实际上，很多 VPS 还不如共享主机好。

• Shared Hosting——共享主机：就是和别人的网站一起共享一个主机。坏处是，容易受别人影响，但实际上也没那么严重。好处是，里面的各种设置都挺全，设置简单，当然，还有价格便宜。玩的不多，像 Blue host、Hostgator 什么的，听说也都不错；
• VPS——虚拟主机：就是虚拟出来一个裸机。好处是，自己独占。坏处是什么都没有，需要自己去捯饬。虽然，配置个网站服务器环境也不是难事儿，不懂的人看着教程，打开putty，慢慢来也能搞定。但，注意你的时间成本。当然，你不在意的话，鼓捣起来，弄不好还会上瘾……品牌的话有：Linode、Vultr、Digital ocean 等，当然 Aws ec2 更牛了，但不推荐，配置略复杂；
• Dedicated Hosting——独立主机：这个就是真正的一台主机，一般来说都比较贵。不多说，我觉得用这种的都是专业的，这里的东西，你看是多余的，当然也有被忽悠买这种的……一般小网站，根本用不上；
• Managed Hosting：这个其实就是托管服务器，相当于 VPS 加上配置管理服务，比 VPS 要贵点，如 WP Engine。

没有基础的，可以是试下共享主机；有点基础的，可以试试 VPS。，还是推荐 Managed hosting，省心。总之，一定要用子的，不要太在意价格，为什么呢？一个网站，用心去做（这里不提那种过于低档的网站），自己立意、资料准备，起码要一个月；设计公司设计建设，起码一个月。为这个网站投入的价值，起码也要三万以上。如果你是SOHO，全自己做，代价更高，不信，你算算自己的工时。几万都投了，还在意五刀十刀的钱吗。网站是你的核心，服务器一定要用子的，稳定省心。

我们用的是 Aws ec2，因为我们用的是 Aws cloudfront，CDN节点和源站都是 Aws 的，他们通过 Aws 的骨干网进行连通，更稳定、更快速。

静态化缓存优化——把动态生成的页面静态化，是网站速度优化的不二法门

Wordpress 类网站，一般使用相关的缓存插件。Avada 推荐 W3TC，其他的如 WP Rocket、WP Super Cache 等都不错。这三个插件，我都用过，本质上没有多大的差异，效果也都差不多，真的差不多。所以，千万不要没事换来换去，感受哪个更好，没有意义。其中：

• W3TC 功能多，也麻烦，很多人看不懂，其实我也看不大懂。
• Wp Super Cache 简单，也适合多的人。
• WP Rocket 复杂度居中，各方面还是不错的，但不是免费的。花钱的话，感觉没那个。找破解的吧，有风险也不更新，不推荐。

还是推荐，简单的 Wp super cache。这些缓存插件的机制都类似，都没有摆脱对 php 程序的依赖。

如果，有条件的话，还是推荐直接使用服务器级别的缓存，不依赖php，服务器直接响应。对提升网站响应时间，还是有不错帮助的。而且，不局限于 Wordpress 做的网站。常见的技术有，Proxy Cache、Varnish Cache 、Squid Cache 等。如，Demag 网站用的是 Varnish cache；Dgcrane 网站用的是 Proxy cache；哪个好呢？Varnish 更专业一点，Proxy Cache 更简单一点。对于一般小网站，哪个顺手用哪个，差异不大。我们用的是简单的 Proxy Cache，并将缓存放入内存，速度还是杠杠的。

CDN优化——是否要用CDN及如何选取

一般的小外贸网站，是否使用 CDN，是存在争议的。我们的建议是：

• 如果你的网站有比较集中针对的地域，CDN 不用也罢。只要你把服务器，放的靠近你的目标区域，选个稳定的服务器，使用好缓存，基本就够用了。
• 如果你的网站，是面向全球，也没有什么特殊的针对性，CDN 还是很需要的。

CDN 品牌有很多，牛的是 Akamai，但基本不针对小网站。其他的有 Aws cloudfont、Cloudflare、Maxcdn 等，都不错。选 CDN 的时候，有一个错误的概念就是，全球节点多的CDN就厉害，忽略了一个重要的问题，就是CDN的命中率。如果访问的时候，总是没有命中，那你的CDN就基本没发挥作用。一般来说，节点越多，流量较小的话，命中率反而越低。我们的经验是，小流量网站 Cloudfont 的命中率还是不错的，能达到80%（Cloudfront 拥有众多的区域节点，可有效提高缓存命中率），但 Cloudfront 配置比较复杂，Cloudflare 配置简单，Maxcdn 中规中矩。而且，AWS Cloudfornt CDN 还有一个缺点，就是针对国内访问优化不够。虽然有很多亚洲节点，但由于天朝网络的特殊性，国内访问效果并不好，甚存在部分地方偶尔无法访问的问题。但其他国际行的 CDN，如 Cloudflare 、Maxcdn 等，针对国内访问效果也不行，也存在类似的问题。好在，外贸网站主要还是针对国外访问。

CDN的使用，还有一个问题：全站加速 or 动静分离？

• 动静分离，就是只对网页里面的静态文件进行 CDN 加速，一般还需要进行设置专门的二级域名，还有对html文件进行相应的改写，好处是逻辑简单，坏处是重要的html文件没有得到加速，如 Maxcdn。当然，很多大的网站，都是用动静分离进行 CDN 加速，而且，使用专门的二级域名进行CDN加速，也有自己好处，但针对小网站，能让html文件，也能使用CDN加速，是重要的。
• 全站加速，就是对所有文件进行加速，包括 html。不需要设置二级域名，不需要对 html 文件进行更改。但配置起来较复杂，很多 CDN 也不支持。Aws cloudfront 是没有问题的；Maxcdn是不支持的；Cloudflare 针对html的加速，也不好用。

上面的例子中的，Dgcrane 能快的完成 html 文件加载，就是因为我们使用CDN，进行了全站加速。我们的做法是，根据市场选服务器地址，然后再加 CDN，就是 Aws ec2 + Aws cloudfront。

说了这么多。倒不是说这些点是什么独门绝技，其实都是很普通的优化方法。我们只是想说，我们在很用心的做速度优化，让小网站也能拥有，只有大网站才做到的的速度优化。

，做个广告，一般我们工作室制作的网站，保守的说：

GTmetrix 测评 Pagespeed 及 Yslow 分数在85%以上
Webpagetest 测评 + √ ，speed index 排名前15%
Google 的 pagespeed insight 评分在90以上

如果你觉的我们做的还可以，有需求，请联系我们！