网页加载速度是衡量一个网页好坏的重要标准，网页遗弃率随网页加载时间的增加而增加。据说近一半的用户希望网页加载时间不超过 2s，超过 3s 一般就放弃该网页。时间就是生命，干等着，谁愿意平白无故地 +1s 呀，所以今天来整理下具体如何加快网页。

本文不再更新，原文链接：https://blog.error.work/qd/89.html

HTML

1、压缩 HTML：

HTML 代码压缩，将注释、空格和新行从生产文件中删除。

为什么：

删除所有不必要的空格、注释和中断行将减少 HTML 的大小，加快网站的页面加载时间，并显著减少用户的下载时间。

2、删除不必要的注释：

确保从您的网页中删除注释。

为什么：

注释对用户来说是没有用的，应该从生产环境文件中删除。可能需要保留注释的一种情况是：保留远端代码库（keep the origin for a library）。

3、删除不必要的属性：

像 type="text/javascript" or type="text/css" 这样的属性应该被移除。

为什么：

类型属性不是必需的，因为 HTML5 把 text/css 和 text/javascript 作为默认值。没用的代码应在网站或应用程序中删除，因为它们会使网页体积增大。

4、在 JavaScript 引用之前引用 CSS 标记：

确保在使用 JavaScript 代码之前加载 CSS。

为什么：

在引用 JavaScript 之前引用 CSS 可以实现更好地并行下载，从而加快浏览器的渲染速度。

5、最小化 iframe 的数量：

仅在没有任何其他技术可行性时才使用 iframe。尽量避免使用 iframe。

6、DNS 预取：

一次 DNS 查询时间大概在 60-120ms 之间或者更长，提前解析网页中可能的网络连接域名

<link rel="dns-prefetch" href="http://example.com/">

CSS

1、压缩:

所有 CSS 文件都需要被压缩，从生产文件中删除注释，空格和空行。

为什么：

缩小 CSS 文件后，内容加载速度更快，并且将更少的数据发送到客户端，所以在生产中缩小 CSS 文件是非常重要，这对用户是有益的，就像任何企业想要降低带宽成本和降低资源。

2、Concatenation:

CSS 文件合并（对于 HTTP/2 效果不是很大）。

<!-- 不推荐 --> <link rel="stylesheet" href="foo.css"/> <link rel="stylesheet" href="bar.css"/> <!-- 推荐 --> <link rel="stylesheet" href="foobar.css"/>

为什么：

如果你还在使用 HTTP/1，那么你就需要合并你的文件。不过在使用 HTTP/2 的情况下不用这样（效果待测试）。

3、非阻塞：

CSS 文件需要非阻塞引入，以防止 DOM 花费更多时间才能渲染完成。

<link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="global.min.css"></noscript>

为什么：

CSS 文件可以阻止页面加载并延迟页面呈现。使用 preload 实际上可以在浏览器开始显示页面内容之前加载 CSS 文件。

4、减小 CSS 类 (class) 的长度：

class 的长度会对 HTML 和 CSS 文件产生（轻微）影响。

为什么：

甚至性能影响也是有争议的，项目的命名策略会对样式表的可维护性有重大影响。如果使用 BEM，在某些情况下可能会写出比所需要的类名更长的字符。重要的是要明智的选择名字和命名空间。

5、删除不用的 CSS：

删除未使用的 CSS 选择器。

为什么：

删除未使用的 CSS 选择器可以减小文件的大小，提高资源的加载速度。

JavaScript

1、JS 压缩：

所有 JavaScript 文件都要被压缩，生产环境中删除注释、空格和空行（在 HTTP/2 仍然有效果）。

为什么：

删除所有不必要的空格、注释和空行将减少 JavaScript 文件的大小，并加快网站的页面加载时间，提升用户体验。

2、非阻塞 JavaScript：

使用 defer 属性或使用 async 来异步加载 JavaScript 文件。

<!-- Defer Attribute --> <script defer src="foo.js"> <!-- Async Attribute --> <script async src="foo.js">

为什么：

JavaScript 阻止 HTML 文档的正常解析，因此当解析器到达 script 标记时（特别是在 内），它会停止解析并且执行脚本。如果您的脚本位于页面顶部，则强烈建议添加 async 和 defer，但如果在 标记之前加载，没有太大影响。但是，使用这些属性来避免性能问题是一种很好的做法。

图片资源

1、图像优化：

在保证压缩后的图片符合产品要求的情况下将图像进行优化。

为什么：

优化的图像在浏览器中加载速度更快，消耗的数据更少。

怎么做：

尽可能尝试使用 CSS3 效果（而不是用小图像替代）尽可能使用字体图片使用 SVG使用编译工具并指定 85 以下的级别压缩。

2、图像格式：

适当选择图像格式。

为什么：

确保图片不会减慢网站速度

怎么做：

使用 Lighthouse 识别哪些图像可以使用下一代图片格式（如 JPEG 2000m JPEG XR 或 WebP）。 比较不同的格式，有时使用 PNG8 比 PNG16 好，有时候不是。

3、使用矢量图像 VS 栅格/位图：

可以的话，推荐使用矢量图像而不是位图图像。

为什么：

矢量图像（SVG）往往比图像小，具有响应性和完美缩放功能。而且这些图像可以通过 CSS 进行动画和修改操作。

4、图像尺寸：

如果已知最终渲染图像大小，请在 上设置宽度和高度属性。

为什么：

如果设置了高度和宽度，则在加载页面时会保留图像所需的空间。如果没有这些属性，浏览器就不知道图像的大小，也无法为其保留适当的空间，导致页面布局在加载期间发生变化。 避免使用 Base64 图像： 你可以将微小图像转换为 base64，但实际上并不是最佳实践。

5、懒加载：

图像懒加载（始终提供 noscript 作为后备方案）。

为什么：

它能改善当前页面的响应时间，避免加载一些用户可能不需要或不必要的图像。

怎么做：

使用 Lighthouse 可以识别屏幕外的图像数量。 使用懒加载图像的 JavaScript 插件。

6、响应式图像：

确保提供接近设备显示尺寸的图像。

为什么：

小型设备不需要比视口大的图像。建议在不同尺寸上使用一个图像的多个版本。

怎么做：

为不同的设备设置不同大小的图像。 使用 srcset 和 picture 为每个图像提供多种变体（variants）。

服务部署

1、页面大小 < 1500 KB：

(理想情况 < 500 KB) 尽可能减少页面和资源的大小。

为什么：

理想情况下，应该尝试让页面大小 <500 KB，但 Web 页面大小中位数大约为 1500 KB（即使在移动设备上）。根据你的目标用户、连接速度、设备，尽可能减少页面大小以尽可能获得最佳用户体验非常重要。

怎么做：

以上前端性能清单中的所有规则将帮助你尽可能地减少资源和代码。

2、Cookie 大小：

如果您使用 cookie，请确保每个 cookie 不超过 4096 字节，并且一个域名下不超过 20 个 cookie。

为什么：

cookie 存在于 HTTP 头中，在 Web 服务器和浏览器之间交换。保持 cookie 的大小尽可能低是非常重要的，以尽量减少对用户响应时间的影响。

怎么做：

消除不必要的 cookie

3、最小化 HTTP 请求：

始终确保所请求的每个文件对网站或应用程序至关重要，尽可能减少 http 请求。

4、使用 CDN 提供静态文件：

使用 CDN 可以更快地在全球范围内获取到你的静态文件。

5、正确设置 HTTP 缓存标头：

合理设置 HTTP 缓存标头来减少 http 请求次数。

6、启用 GZIP 压缩：

启用gzip后可以相应的减轻带宽压力。

7、分域存放资源：

由于浏览器同一域名并行下载数有限，利用多域名主机存放静态资源，增加并行下载数，缩短资源加载时间

8、减少页面重定向

HTTPS

1、HSTS：

开启 HSTS 可以有效防范攻击，保证用户始终访问到网站的加密链接，保护数据传输安全，同时省去 301/302 跳转时间，大大提升网站安全系数和用户体验。

为什么：

如果在网站设置当用户访问域名的时候强制 https 进行 301 或者 302 跳转，但是这个过程中使用到 HTTP 因此容易发生劫持，受到第三方的攻击。 HSTS 是国际互联网工程组织 IETF 正在推行一种新的 Web 安全协议，网站采用 HSTS 后，用户访问时无需手动在地址栏中输入 https://，浏览器会自动采用 HTTPS 访问网站地址，从而保证用户始终访问到网站的加密链接，保护数据传输安全。

怎么做：

HSTS 主要是通过服务器发送响应头的方式控制浏览器操作；

只需在服务器响应头中添加：

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age，单位是秒，用来告诉浏览器在指定时间内，这个网站必须通过 HTTPS 协议来访问。也就是对于这个网站的 HTTP 地址，浏览器需要先在本地替换为 HTTPS 之后再发送请求。includeSubDomains，可选参数，如果指定这个参数，表明这个网站所有子域名也必须通过 HTTPS 协议来访问。preload，可选参数，一个浏览器内置的使用 HTTPS 的域名列表。

设置 max-age 参数，最长建议设置 6 个月； 当用户下次使用 http 访问，客户端就会进行内部 307 跳转；

例子：

Apache 上启用 HSTS

$ vim /etc/apache2/sites-available/hi-linux.conf # 开启HSTS需要启用headers模块 LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so <VirtualHost *:80> ServerName www.hi-linux.com ServerAlias hi-linux.com ... #将所有访问者重定向到HTTPS,解决HSTS首次访问问题。 RedirectPermanent / https://www.hi-linux.com/ </VirtualHost> <VirtualHost 0.0.0.0:443> ... # 启用HTTP严格传输安全 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" ... </VirtualHost>

重启 Apache 服务

$ service apche2 restart

Nginx 上启用 HSTS

$ vim /etc/nginx/conf.d/hi-linux.conf server { listen 443 ssl; server_name www.hi-linux.com; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; ... } server { listen 80; server_name www.hi-linux.com; return 301 https://www.hi-linux.com$request_uri; ... }

重启 Nginx 服务

$ service nginx restart

IIS 启用 HSTS

要在 IIS 上启用 HSTS 需要用到第三方模块，具体可参考：https://hstsiis.codeplex.com/

测试设置是否成功：

设置完成了后，可以用 curl 命令验证下是否设置成功。如果出来的结果中含有 Strict-Transport-Security 的字段，那么说明设置成功了。

$ curl -I https://www.hi-linux.com HTTP/1.1 200 OK Server: nginx Date: Sat, 27 May 2017 03:52:19 GMT Content-Type: text/html; charset=utf-8 ... Strict-Transport-Security: max-age=63072000; includeSubDomains; preload X-Frame-Options: deny X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff ...

对于 HSTS 以及 HSTS Preload List，建议是只要不能确保永远提供 HTTPS 服务，就不要启用。因为一旦 HSTS 生效，之前的老用户在 max-age 过期前都会重定向到 HTTPS，造成网站不能正确访问。唯一的办法是换新域名。

2、HTTP/2

HTTP/2 相比 HTTP/1 而言提供了更加高效的传输方式，解决了 HTTP/1.x 中存在的很多问题，协议增加了二进制帧控制层，大多数改动都封装在这一层。HTTP/2 到底有多快，有一个 HTTP 1.1 VS HTTP/2 的演示 demo：https://http2.akamai.com/demo

怎么做：

要使用 Server Push，有 3 种方案可供选择：

自己实现一个 HTTP/2 服务器；使用支持 Server Push 的 CDN；使用支持 Server Push 的 HTTP/2 服务器。

第一种方案并非是指从零开始实现一个 HTTP/2 服务器，仅仅是指从程序入手，直接对外暴露一个支持 HTTP/2 的服务器。大多数情况下，我们会使用现成的 HTTP/2 库。比如 node-http2，或者是 Go 1.8 的 net/http。

第二和第三种方案通过设置响应头或者修改 HTTP 服务器的配置文件，告知 HTTP 服务器要推送的资源，让 HTTP 服务器完成资源的推送。

第一种方案更灵活，可以编程决定推送的资源和推送的时机；第二和第三种方案更简单，但是缺乏一定的灵活性。

2016 年 4 月底，CloudFlare 宣布支持 HTTP/2 Server Push。官方介绍及教程：https://blog.cloudflare.com/using-http-2-server-push-with-php/ ，简单来说要启用 Server Push，只需要在响应里加入一个特定格式的 Link 头：

Link: </style.css>; rel=preload; as=stylesheet

同样是上面的例子，配置 Nginx 添加 Link 头。当然，你也可以用别的 HTTP 服务器，甚至直接用 PHP 之类的后端语言做这件事。

server { server_name server-push-test.codehut.me; root /path/to/your/website; add_header Link "</style.css>; rel=preload; as=stylesheet"; }

PHP 只需在头部添加：

header("Link: <{$uri}>; rel=preload; as=image", false);

PHP 推送多个不同类型：

header('Link: </style.min.css>; rel=preload; as=style, </jquery.js>; rel=preload; as=script, </logo.png>; rel=preload; as=image, </images/ad.png>; rel=preload; as=image, <favicon.png>; rel=preload; as=image;');

具体实现可查看：https://segmentfault.com/a/1190000009993902