- 原文地址:10x Performance Increases: Optimizing a Static Site
- 原文作者:JonLuca De Caro
- 译文出自:掘金翻译计划
- 本文永久链接:github.com/xitu/gold-m…
- 译者:Starrier
- 校对者:dandyxu、Hopsken
提高 10 倍性能:优化静态网站
几个月前,我在国外旅行,想给朋友看我个人(静态)网站上的一个链接。我试着浏览我的网站,但花费的时间比我预期的要长。网站绝对没有任何动态内容–只有动画和一些响应式设计,而且内容始终保持不变。 我对结果感到震惊,DOMContentLoaded 要 4 s,整个页面加载要 6.8 s。有 20 项关于静态网站的请求(总数据的 1MB)被转移。我习惯了从洛杉矶到我在旧金山的服务器之间用 1 GB/s 的低延迟互联网连接,这使得这个怪物看起来像闪电一样快。在意大利,8 MB/s 的速度让情况变得完全不同。
这是我第一次尝试优化。到目前为止,每次我想添加一个库或者资源时,我都只是将它引入并使用 src=”” 指向它。从缓存到内联,再到延迟加载,对任何形式的性能我都没有给予关注。
我开始寻找有相似经历的人。不幸的是,许多有关静态优化的文献很快就过时–那些来自 2010 或者 2011 年的建议,要么是在讨论库,要么做一些根本不再试用的假设,要么就是不断地重复某些相同的准则。
不过我确实找到了两个很好的信息源 – 高性能浏览器网络和 Dan Luu 类似的静态网站优化经历。尽管在剥离格式和内容方面还不如 Dan,但是我确实成功地让我的页面加载速度提高了大约 10 倍。DOMContentLoaded 大约需要五分之一秒,而整个页面加载只有 388 ms(实际上有点不准确,下文将解释延迟加载的原因)。
过程
过程的第一步是对网站进行分析梳理,我想弄清楚哪些地方花费了最长的时间,以及如何最好地并行化一切。我运行了各种工具来分析我的网站,并在世界各地测试它,包括:
- tools.pingdom.com/
- www.webpagetest.org/
- tools.keycdn.com/speed
- developers.google.com/web/tools/l…
- developers.google.com/speed/pages…
- webspeedtest.cloudinary.com/
其中一些提供了改进建议,但当静态站点有 50 个请求时,您只能做这么多 — 从 90 年代遗留下来的间隔 gif 到不再使用的资源(我加载了 6 种字体但只使用了 1 种字体)。
我的网站时间线 — 我在 Web Archive(译者注:一家提供网站历史快照的服务商)上测试了这个却没有截取原始图片,可是它看起来和我几个月前看到的还是很相似。
我想改进我所能控制的一切 — 从 JavaScript 的内容和速度到实际的 Web 服务器(Ngnix)和 DNS 设置。
优化
简化与合并资源
我注意到的第一件事是,不管是对于 CSS 还是 JS,我都向各种网站发起十几个请求(没有任何形式的 HTTP keepalive),其中还有一些是 https 请求。这增加了对各种 CDN 或 服务器的多次往返,一些 JS 文件正在请求其他文件,这导致了上面所示的阻塞级联。
我使用 webpack 将所有资源合并到一个 js 文件中。每当我对内容进行更改时,它都会自动简化并将我的所有依赖项转换为单文件。
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
const ZopfliPlugin = require("zopfli-webpack-plugin");
module.exports = {
entry: './js/app.js',
mode: 'production',
output: {
path: __dirname + '/dist',
filename: 'bundle.js'
},
module: {
rules: [{
test: /\.css$/,
loaders: ['style-loader', 'css-loader']
}, {
test: /(fonts|images)/,
loaders: ['url-loader']
}]
},
plugins: [new UglifyJsPlugin({
test: /\.js($|\?)/i
}), new ZopfliPlugin({
asset: "[path].gz[query]",
algorithm: "zopfli",
test: /\.(js|html)$/,
threshold: 10240,
minRatio: 0.8
})]
};
复制代码
我尝试了各种不同的配置。现在,这个 bundle.js 文件在我网站的 <head>
中,并且处于阻塞状态。它的最终大小是 829 kb,包括每个非图像资源(字体、css、所有的库、依赖项以及 js)。绝大多数字体使用的是 font-awesome,它们占 829 kb 中的 724。
我浏览了 Font Awesome 库,除了我要使用的 fa-github、fa-envelope 和 fa-code 三个图标外,其他的所有图标都已经删除。我使用叫做 fontello 的服务来提取我需要的图标。新的大小只有 94 kb。
按照目前网站的构建方式,如果我们只有样式表,它看起来是不正确的,所以我接受了单个 bundle.js 的阻塞特性。加载时间为 118 ms,比之前提高了一个数量级。
这也带来了一些额外的好处–我不再指向第三方资源或 CDN,因此用户不需要:(1)执行对该资源的 DNS 查询,(2)执行 https 握手,(3)等待该资源被完整地下载。
虽然 CDN 和分布式缓存对于大规模的分布式网站可能是有意义的,但对于我的小型静态网站来说却没有意义。是否需要优化这额外的 100 ms 左右时间是值得权衡的。
压缩资源
我加载了一个 8 MB 大小的头像,然后以 10% 的宽高比显示它。这不仅仅是缺少优化,这几乎是忽略了用户对带宽使用。
我使用 webspeedtest.cloudinary.com/ 来压缩所有的图像 — 它还建议我切换到 webp,但我希望尽可能多的与其他浏览器进行兼容,所以我坚持使用 jpg。尽管完全有可能建立一个只将 webp 交付给支持它的浏览器系统,但我希望尽可能地保持简单,添加抽象层的好处似乎并不明显。
改进 Web Server — HTTP2, TLS 等
我做的第一件事是过度到 https — 一开始,我在 80 端口运行 Ngnix,只服务于来自 /var/www/html 的文件。
server{
listen 80;
server_name jonlu.ca www.jonlu.ca;
root /var/www/html;
index index.html index.htm;
location ~ /.git/ {
deny all;
}
location ~ / {
allow all;
}
}
复制代码
首先设置 https 并将所有 http 请求重定向到 https。我从 Let’s Encrypt (一个刚开始签署通配符证书的伟大组织!wildcard certificates )那里获得了自己的 TLS 证书。
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name jonlu.ca www.jonlu.ca;
root /var/www/html;
index index.html index.htm;
location ~ /.git {
deny all;
}
location / {
allow all;
}
ssl_certificate /etc/letsencrypt/live/jonlu.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/jonlu.ca/privkey.pem; # managed by Certbot
}
复制代码
只要添加 http2 的指令,Ngnix 就能够利用 HTTP 最新特性的所有优点。注意,如果要利用 HTTP2(以前的 SPDY),您必须使用 HTTPS,在这里阅读更多内容。
您还可以利用 HTTP2 push 指令,使用 http2 push images/Headshot.jpg;
注意:启用 gzip 和 TLS 可能会使您面临 BREACH 风险。由于这是一个静态网站,而 BREACH 实际的风险很低,所以保持压缩状态让我感觉舒服。
利用缓存和压缩指令
仅通过使用 Ngnix 还能完成什么呢?首先是缓存和压缩指令。
我之前一直都是发送未经压缩的原始 HTML。只需要一个单独的 gzip;是的,我就可以从 16000 字节减少到 8000 字节,减少 50%。
实际上,我们能够进一步改进这个数字,如果将 Ngnix 的 gzip 静态设置为开启,它会事先查找所有请求文件的预压缩版本。这与我们上面的 webpack 配置结合在一起 — 我们可以在构建时使用 ZopflicPlugin 预压缩所有文件!这节省了计算资源,并允许我们在不牺牲速度的情况下最大限度地实现压缩。
此外,我的站点变化很少,所以我希望尽可能长时间地缓存资源。这样,在以后的访问中,用户就不需要重新下载所有资源(特别是 bundle.js)。
我更新的服务器配置如下所示。请注意,我不会涉及我所做的所有更改,例如 TCP 设置更改、gzip 指令和文件缓存。如果您想了解更多,请阅读这篇关于 Ngnix 调优的文章。
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 30000;
events {
worker_connections 65535;
multi_accept on;
use epoll;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# Turn of server tokens specifying nginx version
server_tokens off;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
include /etc/nginx/mime.types;
default_type application/octet-stream;
add_header Referrer-Policy "no-referrer";
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /location/to/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
ssl_certificate /location/to/fullchain.pem;
ssl_certificate_key /location/to/privkey.pem;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;
gzip_min_length 256;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
复制代码
以及相应的服务器块
server {
listen 443 ssl http2;
server_name jonlu.ca www.jonlu.ca;
root /var/www/html;
index index.html index.htm;
location ~ /.git/ {
deny all;
}
location ~* /(images|js|css|fonts|assets|dist) {
gzip_static on; # 告诉 Nginx 首先查找所有请求文件的压缩版本。
expires 15d; # 15 day expiration for all static assets
}
}
复制代码
延迟加载
最后我的实际网站有一个小的变化,它所带来的优化是不可忽视的。有 5 张图片直到您按下相应选项卡后才能看到,但它们是与其他所有内容同时加载的(因为它们位于 <img src=”…”>
标签中)。
我编写了一个简短的脚本,用 lazyload 类修改每个元素的属性。只有单击相应的框后才会加载这些图像。
$(document).ready(function() {
$("#about").click(function() {
$('#about > .lazyload').each(function() {
// set the img src from data-src
$(this).attr('src', $(this).attr('data-src'));
});
});
$("#articles").click(function() {
$('#articles > .lazyload').each(function() {
// set the img src from data-src
$(this).attr('src', $(this).attr('data-src'));
});
});
});
复制代码
因此一旦文档完成加载,它将修改 <img>
标签,使他们从 <img data-src=”…”>
转到 <img src=”…”>
然后将其加载到后台。
未来的改进
还有一些其他的更改可以提高页面加载速度 — 最显著的是使用 Service Workers 缓存并拦截所有请求,让站点甚至脱机运行,在 CDN 上缓存内容,这样用户就不需要在 SF 中对服务器进行完整的往返操作。这些都是有价值的改变,但对于个人静态网站来说并不是特别重要,因为它是一个在线简历(关于我)的页面。
结论
这使我的页面加载时间从第一次加载的 8 s 提高到 350 ms,之后的页面加载速度达到了 200 ms。我真的建议阅读高性能浏览器网络 – 您可以很快就阅读完它,它提供了对现代互联网的一个非常好的概述,并在互联网模型的每一层都进行了优化。
我遗漏了什么事情吗?是否有任何违反最优做法?或者可以改善我的叙述内容甚至是其他方面?请随时指正 — JonLuca De Caro!
掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。