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

2018年07月11日 / 外贸建站作者:gtyang

news img

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

为说明这些问题,我们使用 GTmetrix 平台,分别对四个网站,进行加载速度测评。这四个网站分别是:
测评环境为:
  • 测试平台 GTmetrix
  • 浏览器 Chrome
  • 网速 3G Mobile (1.6 Mbps/768 Kbps, 200ms) (为放大网页加载的差异,我们选在较慢网速进行测试。网速飞快的话,网站不做优化,打开也不慢,谈优化是没有意义的)
  • 地点 Vancouver, Canada
测评报告:
对比报告:

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

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

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

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

First Paint 时间除banner大图外,其他显示完全的时间首屏显示完全时间
Google1.75s-2.0s
Dgcrane1.5s2.25s3.5s
Avada3.75s3.75s16s
Demag6.0s-6.5s
大家看到 First Paint 时间差距还是挺大的,最快 1.5s 到最慢 6s。是什么原因造成的呢?请看下图:
news

其中,最左的绿色竖线代表 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 平台,对这四个网站测试一下,结果对比如下。大家也可以自己测试,对比下看看

GoogleDgcraneAvadaDemag
移动设备100996972
桌面设备100968979

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

news

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

图片优化

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

我们的图片优化细节
  • 小图标全部矢量化,无锯齿,不惧放大。这是一个很小的细节,一般网站都忽略了,但我们倾力而为。做个对比,我们将网页都放大4倍,再看 Avada 和 Dgcrane 的 logo 变化;
news
  • 使用 SVG Sprite 技术,将大部分 svg 文件进行合并,减少图片请求个数。想了解 SVG Sprite 技术,可看这篇介绍
  • 网站上所有的图片自动裁剪,并自动优化大小。

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

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

如果你的网站图片优化问题很大,推荐个工具:图片优化网站 Tinypng,还有一个针对 Wordpress 的 插件,可以把网站的图片优化一下。对比这些插件,我们开发的图片优化程序更加方便,你不需要在后台做任何操作,正常上传、使用,所有图片自动优化:
  • 先找个需要优化的图片,就用建议优化的这个图片吧。
news
  • 打开后台,上传上去,找到图片链接。http://www.hnxmx.cn/wp-content/uploads/2018/05/demag.jpg
news
  • 再保存下这个图片查看,106k 减少到 12k,还可以吧。

字体优化

对比之前说的那些,字体优化就比较小众了,好吧,我们也做了。字体加载常见的两个问题:
  • 大家在访问网站的时候,有没有遇到过,网站框架都出来了而文字却不显示的情况?在 Avada 和 Demag 网站加载过程中,都有这样的问题。如图所示
news
  • 还有的时候,很多外贸网站使用了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文件的加载速度:
html文件大小加载时间服务器缓存CDN
Google63.1KB1.61s--
Dgcrane16.5KB0.94sProxy CacheAWS Cloudfront
Avada38.4KB1.76s-Cloudflare
Demag5.1KB1.14sVarnish Cache-
我们能看到,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 测评 5A + √ ,speed index 排名前15%
Google 的 pagespeed insight 评分在90以上

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

复制成功