从案例分析如何优化前端性能

Web 的现状:网页性能提升指南

2017/09/21 · 基础技术 ·
性能

原文出处: Karolina
Szczur
   译文出处:碧青_Kwok   

互联网发展非常迅速,所以我们创造了Web平台。通常我们会忽视连通性等问题,但用户们却不会视而不见。一瞥万维网的现状,可以发现我们并没有用同情心、变通意识去构建它,更不要说性能了。

所以,今天的Web是什么状态呢?

在这个星球上的74亿人中,只有46%可以上网。平均网络速度上限为7Mb/s。更重要的是,有93%的互联网用户正在通过移动设备进行访问——若不适配移动设备将引起用户反感。通常情况下,数据比我们假设的更昂贵——可能需要1到13小时才能购买500MB的数据包(德国
vs. 巴西;更有趣的统计数据参见 Ben
Schwarz
Beyond the Bubble: The Real
World
Performance
)。

我们的网站也不是完美的——平均网站是原始Doom游戏的大小(约3
MB)(请注意,为了统计准确,应使用中位数,阅读 Ilya
Grigorik

优秀“平均页面”是一个神话,中档网站大小目前为1.4MB)。图像可以轻松占用1.7
MB的带宽,而JavaScript平均值也有400KB的体积。这不仅是Web平台的问题,原生应用程序可能更糟,还记得为了获取错误修复版本,而下载200MB安装包的情景吗?

技术人员经常会发现自己处于特权状态。随着最新的高端笔记本电脑、手机和快速有线互联网连接,很容易让我们忘记,这些并不是每个人都有的条件(实际上,真的很少)。

如果我们从特权和缺乏同情的角度来构建网络平台,那么将导致排他性的糟糕体验。

考虑到设计和开发的性能,我们怎样才能做得更好?


从案例分析如何优化前端性能

2016/08/30 · 基础技术 ·
性能

原文出处:
css-tricks   译文出处:王下邀月熊   

De
Voorhoede
工作的日子里,我们一直在追寻为用户构建高性能的前端解决方案。不过并不是每个客户会乐于遵循我们的性能指南,以至于我们必须一遍又一遍地跟他们解释那些保证他们能够战胜竞争对手的性能策略的重要性。最近我们也重构了自己的官方主页,使其能够拥有更快地响应速度与更好地性能表现。
图片 1

优化所有资源

理解浏览器如何分析和处理资源,是显著提高性能的最强大但未充分利用的方式之一。事实证明,浏览器在嗅探资源方面非常出色,同时解析并确定其优先级。这里是关键请求的来源。

如果请求中包含用户视口中呈现内容所必需的资源,则该请求至关重要。

对于大多数网站,它将是HTML、必要的CSS、logo、网络字体,也可能是图片。在许多情况下,几十个其他不相关的资源(JavaScript、跟踪代码、广告等)影响了关键请求。幸运的是,我们能够通过仔细挑选重要资源并调整优先级来控制这种行为。

通过“我们可以手动强制调高资源的优先级,确保所需的内容按时呈现。这种技术可以显著改善“交互时间”指标,从而使最佳的用户体验成为可能。

图片 2

关键请求对许多人来说,似乎仍然是一个黑匣子,可共享资料的缺乏并不能改变现状。幸运的是,Ben
Schwarz

发表了关于这个问题的非常全面并平易近人的文章——关键请求。另外,请参阅Addy的文章,在Chrome中的预加载、预取和优先级(Preload,
Prefetch and Priorities in
Chrome
)。

图片 3

[在Chrome开发人员工具中启用优先级]

要跟踪在请求优先级处理方面的情况,请使用Lighthouse性能工具和关键请求链审核工具,或查看Chrome开发人员工具中“网络”选项卡下的请求优先级。

性能调优始于设计

在前端项目中,我们常常与产品经理以及UI设计讨论如何在美感与性能之间达到平衡,我们坚信更快地内容呈现是好的用户体验的不可分割的一部分。在我们自己的网站中,我们是以性能优于美感。好的内容、布局、图片与交互都是构成你网站吸引力的不可或缺的部分,不过这些复杂的元素的使用往往也意味着页面加载速度的增加。设计的核心即在于决定我们网站需要呈现哪些内容,往往这里的内容会指图片、字体这样的偏静态的部分,我们首先也从对于静态内容的优化开始。

通用性能清单

  1. 积极地缓存
  2. 启用压缩
  3. 优化关键资源的优先级
  4. 使用CDN(Content Delivery Networks)

Static Site Generator

为了演示与测试方便,我们基于NodeJS搭建了一个混合使用MarkDown与JSON作为配置的静态网站生成器,其中一个简单的博客类型的网站的配置信息如下:

JavaScript

{ “keywords”: [“performance”, “critical rendering path”, “static site”,
“…”], “publishDate”: “2016-08-12”, “authors”: [“Declan”] }

1
2
3
4
5
{
  "keywords": ["performance", "critical rendering path", "static site", "…"],
  "publishDate": "2016-08-12",
  "authors": ["Declan"]
}

而其内容为:

JavaScript

# A case study on boosting front-end performance At [De
Voorhoede](https://www.voorhoede.nl/en/) we try to boost front-end
performance… ## Design for performance In our projects we have daily
discussions…

1
2
3
4
# A case study on boosting front-end performance
At [De Voorhoede](https://www.voorhoede.nl/en/) we try to boost front-end performance…
## Design for performance
In our projects we have daily discussions…

下面,我们就这个静态网站,进行一些讨论。

图片优化

图片通常占网页传输的大部分有效载荷,因此图片优化可以带来最大的性能提升。有许多现有的策略和工具可以帮助我们删除额外的字节,但是首先应考虑的问题是:“图片对于我想传达的信息和效果至关重要吗?”。如果可以消除它,不仅可以节省带宽,而且还节省了请求。

在某些情况下,可以通过不同的技术实现类似的结果。比如CSS就具有艺术方向的一系列属性,例如阴影、渐变、动画及形状,允许我们构造适当风格的DOM元素。

Image Delivery

图片是网站的不可或缺的部分,其能够大大提升网站的表现力与视觉效果,而目前平均大小为2406KB的网页中就有1535KB是图片资源,可见图片占据了静态资源多么大的一个比重,这也是我们需要重点优化的部分。
图片 4

选择正确的格式

如果不能舍弃图片,确定哪种格式更合适就很重要了。首先要在矢量和光栅图形之间做出选择:

  • 矢量图形:分辨率独立,通常体积更小。非常适合logo、icon和简单的图形,包括基本形状(线,多边形,圆和点)。
  • 光栅图形:呈现更详细的信息,比较适合相片。

做出首个决定后,可以选择以下几种格式:JPEG、GIF、PNG–8、PNG–24,或最新的
WEBP 与 JPEG-XR
格式。有了这么多的选项,如何确保我们做出正确的选择?以下是找出最佳格式的基本方法:

  • JPEG:颜色非常丰富的图片(例如照片)
  • PNG–8:色彩相对单一的图片
  • PNG–24:局部透明的图片
  • GIF:动图

Photoshop可以通过各种设置,例如降低质量、降低噪音或色彩数量来优化以上每一种格式。确保设计师了解上述性能实践,并能够使用正确的方式优化相应格式的图片。如果您想了解更多如何处理图片,请阅读
Lara Hogan 的好文 Designing for
Performance

WebP

WebP
是面向现代网页的高压缩低损失的图片格式,通常会比JPEG小25%左右。然后WebP目前被很多人忽视,也不常使用。截止到本文撰写的时候,WebP目前只能够在Chrome,
Opera and Android
(大概占用户数的
50%)这些浏览器中使用,不过我们还是有办法以JPG/PNG来弥补部分浏览器中不支持WebP的缺憾。

试用新格式

图像格式有几个较新的玩家,即WebP、JPEG 2000 和
JPEG-XR。它们都是由浏览器厂商开发的:Google 的 WebP,Apple 的 JPEG 2000
和 Microsoft 的 JPEG-XR。

WebP
是最受欢迎的竞争者,支持无损和有损压缩,这使得它非常灵活。无损的 WebP
比 PNG 小26%,比 JPG 小25-34%
。WebP
有着74%的浏览器支持,它可以安全地进行降级,最多可节省1/3的传输字节。JPG
和 PNG 可以在 Photoshop
和其他图像处理应用程序以及命令行界面(brew install webp)中转换为WebP。

如果你想探索其他格式之间的视觉差异,推荐 Github 上这个很赞的
Demo

picture标签

使用picture标签可以方便的对于WebP格式不支持的情况下完成替换:

XHTML

<picture> <source type=”image/webp” srcset=”image-l.webp”
media=”(min-width: 640px)”> <source type=”image/webp”
srcset=”image-m.webp” media=”(min-width: 320px)”> <source
type=”image/webp” srcset=”image-s.webp”> <source
srcset=”image-l.jpg” media=”(min-width: 640px)”> <source
srcset=”image-m.jpg” media=”(min-width: 320px)”> <source
srcset=”image-s.jpg”> <img alt=”Description of the image”
src=”image-l.jpg”> </picture>

1
2
3
4
5
6
7
8
9
<picture>
  <source type="image/webp" srcset="image-l.webp" media="(min-width: 640px)">
  <source type="image/webp" srcset="image-m.webp" media="(min-width: 320px)">
  <source type="image/webp" srcset="image-s.webp">
  <source srcset="image-l.jpg" media="(min-width: 640px)">
  <source srcset="image-m.jpg" media="(min-width: 320px)">
  <source srcset="image-s.jpg">
  <img alt="Description of the image" src="image-l.jpg">
</picture>

这里我们使用了 picturefill by Scott
Jehl
作为Polyfill库来保证低版本的浏览器中能够支持picture标签,并且保证跨浏览器的功能一致性。并且我们还使用了img标签来保证那些不支持picture的浏览器能够正常工作。

用工具和算法进行优化

即使使用了高效的图像格式,也不应跳过后处理优化。这一步很重要。

如果您选择了尺寸相对较小的
SVG,它们也是可以再次压缩的。SVGO
是一个命令行工具,可以通过剥离不必要的元数据来快速优化
SVG。另外,如果您喜欢Web界面或受操作系统的限制,请使用 Jake
Archibald

SVGOMG。因为 SVG 是基于 XML
的格式,它也可以在服务器端进行 GZIP 压缩。

ImageOptim
是大多其他图像类型的最好选择。包括 pngcrush、pngquant、MozJPEG、Google
Zopfli等,它在一个全面的开源包中捆绑了一大堆优秀的工具。ImageOptim
可以以 Mac OS 应用程序、命令行界面和 Sketch
插件形式,轻松地实现到现有的工作流程中。对于那些在 Linux 或 Windows
上的场景,大多数 ImageOptim 的 CLI 都可以在您的平台上使用。

如果您倾向于尝试新兴的编码器,Google 今年早些时候发布了
Guetzli——源自
WebP 和 Zopfli 的开源算法。Guetzli
可以比任何其他可用的压缩方法生成35%更小体积的
JPEG
。唯一的缺点是:处理时间慢(CPU 每处理百万像素需要1分钟)。

选择工具时,请确保它们生成所需的结果并适应团队的工作流程。理想情况是,将优化过程自动化,这样就不会产生漏掉的情况。

图片多格式生成

现在我们已经可以通过设置不同的图片尺寸、格式来保证图片的分发优化,不过我们总不希望每次要用一张图片的时候就去生成6个不同的尺寸/实例。我们希望有一种抽象的方法可以帮我们自动完成这一步,为我们自动生成不同的格式/尺寸,然后自动插入合适的picture元素,在我们的静态网站生成器中是这么做的:

  • 首先是要gulp
    responsive
    来生成不同尺寸的图片,该插件同样会输出WebP格式的图片
  • 压缩生成好的图片
  • 用户只需要在MarkDown中编写![Description of the image](image.jpg)即可
  • 我们自定义的MarkDown渲染引擎会在处理过程中自动使用picture元素替换这些img标签

响应式图片

十年前,我们使用一种分辨率,就可以为所有人服务,但时代变化太快,现今的响应式
Web
已非往日可比。这也是为什么我们必须要特别留心,去精心优化视觉资源,确保它们适应各种视口设备。幸运的是,感谢
Responsive Images
社区小组
,我们可以完美使用 picture
元素和 srcset 属性(二者都有85%+支持率)。

SVG Animation

我们的网站中也存在着很多的Icon以及动画性质图片,这里我们是选择SVG作为Icon与Animation的格式,主要考虑有下:

  • SVG是矢量表示,往往比位图文件更小
  • SVG自带响应式功效,能够根据容器大小进行自动缩放,因此我们不需要再为了picture元素生成不同尺寸的图片
  • 最重要的一点是我们可以使用CSS去改变其样式或者添加动画效果,关于这一点可以参考CodePen上的这个演示
    点击预览

    图片 5

srcset 属性

srcset在分辨率切换方案中效果最佳——即当我们需要根据用户的屏幕密度和大小显示图像时。基于srcsetsize属性中的一组预定义规则,浏览器将选择最佳图片,相应地提供给视口。这项技术可以带来很大的带宽和请求节省,特别是对于移动用户。
图片 6
[srcset 使用示例]

Custom Web Fonts

我们首先回顾下浏览器是如何使用自定义字体的,当浏览器识别到用户在CSS中基于@font-size定义的字体时,会尝试下载该字体文件。而在下载的过程中,浏览器是不会展示该字体所属的文本内容,最终导致了所谓的Flash of Invisible Text现象。现在很多的网站都存在这个问题,这也是导致用户体验差的一个重要原因,即会影响用户最主要的内容浏览这一操作。而我们的优化点即在于首先将字体设置为默认字体,而后在自定义的Web
Font下载完毕之后对标准字体再进行替换操作,并且重新渲染整个文本块。而如果自定义的字体下载失败,整个内容还是能保证基本的可读性,不会对用户体验造成毁灭性的打击。
图片 7

首先,我们会为需要使用到的Web
Fonts创建最小子集,即只将那些需要使用的字体提取出来,而并不需要让用户下载整个字体集,这里推荐使用Font
squirrel webfont
generator
。另外,我们还需要为字体的下载设置监视器,即保证能够在字体下载完毕之后自动回调,这里我们使用的是fontfaceobserver,它会为页面自动创建一个监视器,在侦测到所有的自定义Web
Fonts下载完毕后,会为整个页面添加默认的类名:

CSS

html {font-family: Georgia, serif;} html.fonts-loaded {font-family:
Noto, Georgia, serif;}

1
2
html {font-family: Georgia, serif;}
html.fonts-loaded {font-family: Noto, Georgia, serif;}

不过现在CSS的font-display属性也原生提供了我们这种替换功能,更多详情可见font-display属性。

picture 元素

picture元素和media属性旨在使艺术设计变得容易。通过为不同情形提供不同图片(通过媒体查询进行测试),无论什么分辨率,我们都能始终将图像中最重要的元素保持在焦点。
图片 8
[picture 元素使用示例]

请务必阅读 Jason GrigsbyResponsive
Images
101
指南,以便对这两种方法进行彻底的阐述。

JS 与 CSS 的懒加载

总的来说我们希望所有的资源能够尽可能快地加载完毕,不过往往为了保证首页加载的速度,我们会考虑将部分非首屏需要的JS/CSS文件进行延迟加载,或者对于重复的视图使用浏览器本地缓存。

使用图片 CDN 进行分发

视觉优化的最后一步是分发。所有资源都可以从使用 内容分发网络
中受益,但还有一些针对图片优化的特定工具,例如
Cloudinary
imgx。使用这些服务的好处远远超过了减少服务器上的流量,并显着降低了响应延迟。

CDN可以很好的解决重图片网站的复杂度,包括响应式服务与图片优化。虽然产品不同(价格也是如此),但是大多数方案都是根据设备和浏览器,调整大小、裁剪来确定哪种格式最适合用户。甚至更多——它们可以压缩、检测像素密度、水印、识别面部,并允许后置处理能力。借助这些强大的功能,和将参数附加到URL的能力,以用户为中心的图片服务变得十分容易。

Lazy Load JS

目前来说,我们的网站都是偏向于静态,并不需要太多的JavaScript介入,不过考虑到日后的扩展空间,我们还是构建了一套完整的JS的工作流。众所周知,如果将JS直接放置到head标签中,其会阻塞整个页面的渲染。对于该点,最简单的方式就是将会阻塞渲染的JS脚本移动到页面的尾部,在整个首屏渲染完毕之后再进行加载。另一个常用的手段就是依然保持JS文件位于head标签中,不过为其添加一个defer的属性,这保证了浏览器只会先将该脚本下载下来,然后等到整个页面加载完毕再执行该脚本。
另一个需要注意的是,因为我们并不使用类似于jQuery这样的第三方依赖库,而更多的依赖于浏览器原生的特性,因此我们希望在合适的浏览器内加载合适版本的JS代码,其效果大概如下:

XHTML

<script> // Mustard Cutting if (‘querySelector’ in document &&
‘addEventListener’ in window) { document.write(‘<script
src=”index.js” defer><\/script>’); } </script>

1
2
3
4
5
6
<script>
// Mustard Cutting
if (‘querySelector’ in document && ‘addEventListener’ in window) {
  document.write(‘<script src="index.js" defer><\/script>’);
}
</script>

图像性能清单

  1. 选择正确的图片格式
  2. 尽可能使用矢量图形
  3. 如果变化不明显,则降低图片质量
  4. 使用新格式图片
  5. 使用工具与算法优化
  6. 学习srcsetpicture
  7. 使用图片 CDN

Lazy Load CSS

正如上文所述,我们的网站偏向于静态展示,因此首屏的最大问题就是CSS文件的加载问题。浏览器会在head标签中声明的所有CSS文件下载完毕之前一直处于阻塞状态,这种机制很是明智的,不然的话浏览器在加载多个CSS文件的时候会进行重复的布局与渲染,这更是对于性能的浪费。
为了避免非首屏的CSS文件阻塞页面渲染,我们使用loadCSS这个小的工具库来进行异步的CSS文件加载,它会在CSS文件加载完毕后执行回调。不过,异步加载CSS也会带来一个新的问题,如果我们将所有的CSS全部设置为了异步加载,那么用户会首先看到单纯的HTML页面,这也会给用户不好的体验。那么我们就需要在异步加载与首屏渲染之间找到一个平衡点,即首先加载那些必要的CSS文件。
我们一般将首屏渲染中必要的CSS文件成为Critical
CSS,即关键的CSS文件,代指在保证页面的可读性的前提下需要加载的最少的CSS文件数目。Critical
CSS的选定会是一个非常耗时的过程,特别是我们网站本身的CSS样式设置也在不停变更,我们不可能完全依赖于人工去提取出关键的CSS文件,这里推荐Critical这个辅助工具能够帮你自动提取压缩Critical
CSS。下图的一个对比即是仅加载Critical CSS与加载全部CSS的区别:

图片 9

上图中红色的线,即是所谓的折叠分割点。

Web 字体优化

自定义字体是一项非常强大的设计工具。但是能力伴随着很多责任。现有68%的网站在使用
Web字体,这种类型的资源是性能杀手之一
(平均轻松可达100KB,取决于变体和字体的数量)。

即使体积不是最大的问题,不可见文本闪动(FOIT)也算是。当Web字体加载中或加载失败时,会发生FOIT,这会让空白页面,从而导致内容无法访问。首先仔细检查我们是否需要Web字体可能是值得的。如果真是这样,有一些策略可以帮助我们减轻对业务的负面影响。

服务端与缓存

高性能的前端离不开服务端的支持,在我们的实践中也发现不同的服务端配置同样会影响到前端的性能。目前我们主要使用Apache
Web Server作为中间件,并且通过HTTPS来安全地传递内容。

选择正确的格式

有4种网络字体格式:EOT、TTF、WOFF 和最近的 WOFF2。TTF 和 WOFF
被广泛使用,拥有超过90%的浏览器支持率。根据支持情况,最有可能安全地使用WOFF2,并在旧版浏览器降级使用
WOFF。使用WOFF2的优点是,一套定制的预处理和压缩算法(如Brotli),并有大约30%的文件大小减少和改进的解析能力。

@font-face中定义网页字体的来源时,请使用format()提示来指定应使用哪种格式。

如果您使用 Google Fonts 或 Typekit
来提供字体,这两种工具都实施了一些策略来优化其性能。Typekit
现在可以异步地为所有套件提供服务,防止 FOIT
以及允许其JavaScript套件代码的10天延长缓存期限(而不是默认10分钟)。Google
Fonts 可以根据用户设备自动提供最小的文件。

Configuration

我们首先对于合适的服务端配置做了些调研,这里推荐是使用H5BP Boilerplate
Apache
Configuration
作为配置模板,它是个不错的兼顾了性能与安全性的配置建议。同样地它也提供了面向其他服务端环境的配置。我们对于大部分的HTML、CSS以及JavaScript都开启了GZip压缩选项,并且对于大部分的资源都设置了缓存策略,详见下文的File
Level Caching章节。

审核字体范围

无论是否自主托管,字体数量、字体体积和样式,都将显著影响您的性能预算。

理想情况下,我们只需要一种包括常规和粗体的字体。如果您不确定如何选择字体范围,请参考
Lara Hogan 的 Weighing Aesthetics and
Performance

HTTPS

使用HTTPS可以保证站点的安全性,但是也会影响到你网站的性能表现,性能损耗主要发生在建立SSL握手协议的时候,这会导致很多的延迟,不过我们同样可以通过某些设置来进行优化。

  • 设置HTTP Strict Transport
    Security请求头可以让服务端告诉浏览器其只允许通过HTTPS进行交互,这就避免了浏览器从HTTP再重定向到HTTPS的时间消耗。
  • 设置TLS false
    start允许客户端在第一轮TLS中就能够立刻传递加密数据。握手协议余下的操作,譬如确认没有人进行中间人监听可以同步进行,这一点也能节约部分时间。
  • 设置TLS Session
    Resumption,当浏览器与服务端曾经通过TLS进行过通信,那么浏览器会自动记录下Session
    Identifier,当下次需要重新建立连接的时候,其可以复用该Identifier,从而解决了一轮的时间。

这里推荐扩展阅读下Mythbusting HTTPS: Squashing security’s urban legends
by Emily Stark

使用Unicode范围子集

Unicode范围子集允许将大字体分割成较小的集合。这是一个相对先进的策略,特别是在处理亚洲语言的时候,可能会带来显着的节省(你知道中文字体有平均数为
20,000
个字形吗?)。第一步是将字体限制为必要的语言集,例如拉丁语,希腊语或西里尔语。如果仅使用Web字体做Logo类使用,则应使用Unicode范围描述符,来选择特定字符。

Filament Group
发布了一个开源命令行工具,可以根据文件或URL生成必要字形列表的 glyph
hanger
。或者,基于 Web 的
Font Squirrel Web Font
Generator

提供高级子集和优化选项。如果在字体选择器界面中内置了使用Google Fonts 或
Typekit 选择语言子集,则使基本子集更容易。

Cookies

我们并没有使用某个服务端框架,而是直接使用了静态的Apache Web
Server,不过Apache Web
Server也是能够读取Cookie并且进行些简单的操作。譬如在下面这个例子中我们将CSS缓存信息存放在了Cookie中,然后交付Apache进行判断是否需要重复加载CSS文件:

XHTML

<!– #if expr=”($HTTP_COOKIE!=/css-loaded/) ||
($HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != ‘0d82f.css’
)”–> <noscript><link rel=”stylesheet”
href=”0d82f.css”></noscript> <script> (function() {
function loadCSS(url) {…} function onloadCSS(stylesheet, callback)
{…} function setCookie(name, value, expInDays) {…} var stylesheet =
loadCSS(‘0d82f.css’); onloadCSS(stylesheet, function() {
setCookie(‘css-loaded’, ‘0d82f’, 100); }); }()); </script>
<style>/* Critical CSS here */</style> <!– #else
–> <link rel=”stylesheet” href=”0d82f.css”> <!– #endif
–>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<!– #if expr="($HTTP_COOKIE!=/css-loaded/) || ($HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != ‘0d82f.css’ )"–>
 
<noscript><link rel="stylesheet" href="0d82f.css"></noscript>
<script>
(function() {
  function loadCSS(url) {…}
  function onloadCSS(stylesheet, callback) {…}
  function setCookie(name, value, expInDays) {…}
 
  var stylesheet = loadCSS(‘0d82f.css’);
  onloadCSS(stylesheet, function() {
    setCookie(‘css-loaded’, ‘0d82f’, 100);
  });
}());
</script>
 
<style>/* Critical CSS here */</style>
 
<!– #else –>
<link rel="stylesheet" href="0d82f.css">
<!– #endif –>

这里Apache
Server中的逻辑控制代码就是有点类似于注释形式的<!-- #,其主要包含以下步骤:

  • $HTTP_COOKIE!=/css-loaded/ 检测是否有设置过CSS缓存相关的Cookie
  • $HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != '0d82f.css'检测缓存的CSS版本是否为当前版本
  • If <!-- #if expr="..." --> 值为true
    我们便能假设该用户是第一次访问该站点
  • 如果用户是首次浏览,我们添加了一个<noscript>标签,里面还包含了一个阻塞型的<link rel="stylesheet">标签。添加该标签的意义在于我们在下面是使用JavaScript来异步加载CSS文件,而在用户禁止JavaScript的情况下也能保证可以通过该标签来正常加载CSS文件。
  • <!-- #else -->
    表达式在用户二次访问该页面时,我们可以认为CSS文件已经被加载过了,因此可以直接从本地缓存中加载而不需要重复请求。

上述策略同样可以应用于Web Fonts的加载,最终的Cookie如下所示:
图片 10

建立字体加载策略

字体是阻塞渲染的——因为浏览器必须首先构建 DOM 和
CSSOM;在使用与现有节点相匹配的CSS选择器之前,浏览器并不会下载Web字体。这种行为会明显延迟文本呈现,通常会导致前面提到的不可见文本闪动(FOIT)。在较慢的网络和移动设备上,FOIT会更加显着。

实施字体加载策略,可防止用户无法访问您的内容。通常,选择无样式文本闪动(FOUT)是最简单和最有效的解决方案。

font-display是提供非 JavaScript 依赖解决方案的新 CSS
属性。不幸的是,它仅有部分支持(Chrome 和 Opera),目前正在 Firefox 和
WebKit 中开发。尽管如此,它可以并且应该与其他字体加载机制结合使用。
图片 11
[font-display 属性实践]

幸运的是,Typekit 的 Web Font
Loader
Bram
Stein
的 Font Face Observer
可以帮助管理字体加载行为。此外,网页字体性能专家 Zach
Leatherman

发布了字体加载策略综合指南,这将有助于为您的项目选择正确的方法。

File Level Caching

在上文可以发现,我们严重依赖于浏览器缓存来处理用户重复访问时资源加载的问题,理想情况下我们肯定希望能够永久地缓存CSS、JS、Fonts以及图片文件,然后在某个文件发生变化的时候将缓存设置为失效。这里我们设置了以https://www.voorhoede.nl/assets/css/main.css?v=1.0.4形式,即在请求路径上加上版本号的方式进行缓存。不过这种方式的缺陷在于如果我们更换了资源文件的存放地址,那么所有的缓存也就自然失效了。这里我们使用了gulp-rev以及gulp-rev-replace来为文件添加Hash值,从而保证了仅当文件内容发生变化的时候文件请求路径才会发生改变,即将每个文件的缓存验证独立开来。

字体性能清单

  1. 选择正确的格式
  2. 审核字体范围
  3. 使用Unicode范围子集
  4. 建立字体加载策略

Result

上面我们介绍了很多的优化手段,这里我们以实验的形式来对优化的结果与效果进行分析。我们可以用类似于PageSpeed
Insights
或者WebPagetest来进行性能测试或者网络分析。我觉得最好的测试你站点渲染性能的方式就是在限流的情况下观察页面的呈现效果,Google
Chrome内置了限流的功能:
图片 12
这里我们将我们的网络环境设置为了50KB/S的GPRS网络环境,我们总共花费了2.27秒完成了首屏渲染。上图中黄线左侧的时间即指明了从HTML文件开始下载到下载完成所耗费的时间,该HTML文件中已经包含了关键的CSS代码,因此整个页面已经保证了基本的可用性与可交互型。而剩下的比较大的资源都会进行延时加载,这正是我们想要达到的目标。我们也可以使用PageSpeed来测试下网站的性能,可以看出我们得分很不错:
图片 13
而在WebPagetest中,我们看出了如下的结果:
图片 14

JavaScript 优化

目前,JavaScript 的平均大小为446
KB
,已经使其成为第二大的资源类型(第一为图片)。

我们可能没有意识到,我们所爱的JavaScript隐藏着更加严峻的性能瓶颈。

Roadmap

优化之路漫漫,永无止境,我们在未来也会关注以下几个方面:

  • HTTP/2:我们目前已经开始尝试使用HTTP/2,而本篇文章中提到的很多的优化的要点都是面向HTTP/1.1的。简言之,HTTP/1.1诞生之初还是处于Table布局与行内样式流行的时代,它并没有考虑到现在所面对的2.6MB大小,包含200多个网络请求的页面。为了弥合这老的协议的缺陷,我们不得不连接JS与CSS文件、使用行内样式、对于小图片使用Data
    URL等等。这些操作都是为了节约请求次数,而HTTP/2中允许在同一个TCP请求中进行多个并发的请求,这样就会允许我们不需要再去进行大量的文件合并操作。
  • Service
    Workers:这是现代浏览器提供的后台工作线程,可以允许我们为网站添加譬如离线支持、推送消息、后台同步等等很多复杂的操作。
  • CDN:目前我们是自己维护网站,而在真实的应用场景下可以考虑使用CDN服务来减少服务端与客户端之间的物理距离,从而减少传输时延。

    2 赞 5 收藏
    评论

图片 15

监控JavaScript的流量

优化交付只是解决网页膨胀的第一步。JavaScript
下载后,必须由浏览器进行解析、编译和运行。快速浏览一些流行的网站,显而易见的是,gzip
压缩的 JS 在解压之后至少变大三倍。事实上,我们正在发送一大堆代码。
图片 16
1MB JavaScript 在不同设备上的解析时间。图片由 Addy Osmani 和他的
JavaScript Start-up
Performance

文章提供。

分析解析和编译时间,对于理解应用程序是否准备好进行交互至关重要。这些耗时根据用户设备的硬件能力而异。解析和编译会很容易在低端手机上高出2-5倍Addy的研究证实,在常规手机上,一个应用程序将需要16秒才能达到交互式状态,而在桌面电脑上为8秒。分析这些指标至关重要,幸运的是,我们可以通过
Chrome DevTools 来完成。
图片 17
[在 Chrome 开发工具中查看解析和编译过程]

请务必阅读 Addy Osmani 对 JavaScript
启动性能
的详细说明。

摆脱不必要的依赖

现代软件包管理器的工作方式,可以轻而易举地掩盖依赖关系的数量和大小。webpack-bundle-analyzer
Bundle Buddy
是很好的可视化工具,帮助识别出代码重复、最大性能问题和过时的、不必要的依赖。

图 webpack bundle analyzer
实践
(译者注:原gif太大,只能用外链了)

通过 VS
Code

Atom
中的Import Cost扩展,我们可以使导入依赖成本更加明显。

图 VS Code
Import Code扩展

实现代码分割

只要有可能,我们就应只提供用户体验所必需的资源。向用户发送一个完整的
bundle.js
文件,包括他们可能永远看不到的交互效果处理代码,并不太理想(假设在访问着陆页时,去下载处理整个应用程序的
JavaScript)。同样,我们不应普遍提供针对特定浏览器或用户代理的代码。

Webpack,最受欢迎的模块打包器之一,天生具备代码分割支持。最简单的代码分割可以按页面实现(如用于着陆页的home.js,联系人页面的contact.js等),Webpack
还提供了一些高级策略,如动态导入及延迟加载,值得一看。

考虑框架选择

JavaScript 前端框架日新月异。根据2016年的 JavaScript
调查
,React
是最受欢迎的选择。仔细审视架构选择,可能会发现,您可以使用更为轻量级的替代方案,例如
Preact(请注意,Preact 并不是一个完整的 React
重新实现,只是一个高性能,功能更轻的虚拟
DOM
库)。类似地,我们可以将较大的库更换成更小的版本——moment.js换成date-fns(或者在特定情况,删除moment.js中未使用的
locales
)。

在开始一个新项目之前,有必要确定什么样的功能是必需的,并为您的需求和目标选择最具性能的框架。有时这可能意味着选择写更多的原生
JavaScript。

JavaScript 性能清单

  1. 监控 JavaScript 流量
  2. 摆脱不必要的依赖
  3. 实现代码分割
  4. 考虑框架选择

性能追踪,前进之路

我们已经讨论了一些策略,在大多数情况下会对我们正在建立的产品用户体验产生积极的变化。性能可能是一个棘手的问题,有必要长期地跟踪我们调整的结果。

以用户为中心的性能指标

卓越的性能指标,旨在尽可能接近描绘用户体验。以往的onLoadonContentLoadedSpeedIndex对「用户多快能与页面交互」给出的信息非常少。当聚焦到传输资源时,量化地感知性能十分困难。好在,有一些时间可以全面地描述内容的可视性和互动性。

这些指标是首次渲染(First Paint),首次有意义渲染(First Meaningful
Paint),视觉完整(Visually Complete)和可交互时间(Time to
Interactive)。

图片 18

  • 首次渲染:浏览器从白色屏幕到第一次视觉呈现的变化。
  • 首次有意义渲染:文字,图像和主要内容都已可见。
  • 视觉完整:视口中的所有内容都可见。
  • 可交互时间:视口中的所有内容都是可见的,可以与之进行交互(JavaScript
    主线程停止活动)。

这些时间直接对应于用户的实际体验,因此可以作为重点进行追踪。如果可能,将它们记录全部,否则选择一两个来更好地监控性能。其他指标也需要留意,特别是我们发送的字节数(优化和解压缩)。

设置性能预算

所有这些上报数字可能会很快变得混乱和不易理解。没有可操作的目标和对象,很容易迷失我们最初的目的。几年前,Tim
Kadlec

写过关于性能预算的概念。

遗憾的是,并没有一个万能的神奇公式。性能预算通常归结为竞争分析和产品目标,而这是每个业务所各异的。

设定预算时,重要的是要达到明显的差异,通常是至少改善20%。实践和迭代您的预算,利用
Lara Hogan
方法新设计与性能预算作为参考。

试用性能预算计算器或Chrome扩展浏览器卡路里,以帮助创建预算。

持续监控

监控性能不应该是手动的。市面上有很多强大的工具,还可以提供全面的报告。

Google Lighthouse
是一个可以审核性能、可访问性、渐进式网络应用程序等的开源项目。您可以在命令行中或直接在
Chrome Developer Tools 中使用Lighthouse。
图片 19
[Lighthouse 运行一次性能审查]

对于持续的追踪,选择选择
Calibre,它可以提供性能预算、设备仿真、分布式监控和许多其他功能,无需我们仔细构建自己的性能套件即可获得。
图片 20
[Calibre 报表]

无论您在追踪什么,请确保使整个团队或组织能够透明地访问数据。

性能是一项分担责任,远远超过开发人员团队——我们都应对所创建的用户体验负责,不管是什么角色或职级。

倡导速度和建立协作流程,以便在产品决策或设计早期阶段,尽早暴露可能遇到的瓶颈,是非常重要的。

建立性能意识和同情心

关心性能不仅仅是一个业务目标(但是如果您需要通过销售统计数据来进行销售,那么可以通过PWA统计)。这是关于基本的同情和用户体验放在第一位。

作为技术专家,我们的责任是,不要让用户的注意力和时间放在等待页面上,而已可以更开心地花费在其他地方。我们的目标是建立意识到时间和人们关注的工具

提倡性能意识应该是每个人的目标。让我们抱着性能和同情心,为大家建立一个更好、更有意义的未来吧。

1 赞 1 收藏
评论

图片 15