因为最近项目中通过Chrome的Lighthouse工具来分析了一下页面性能，发现页面的FCL(First Content Loading)需要5s左右，性能是相当的差，本文是自己在谷歌上搜索相关资源的时候找到的一些好的文章，自己也有英语六级的水平，长期在外企工作，所有希望翻译总结出来希望对大家有所帮助
HTTP/2和HTTP/1.1的区别
- 多路复用(Multiplexing)https://blog.cloudflare.com/http-2-for-web-developers/
HTTP/2是将多个资源请求通过一个TCP链接来传输，而不需要像HTTP/1.1那样每一个资源请求来简历一个TCP链接
HTTP/2采用TCP请求头压缩，HTTP/1.1是不压缩TCP请求头的，头部里面带有很多无用的信息 - 服务端推送(Server Push)https://www.makeuseof.com/tag/ways-improve-websites-pagespeed-using-http2/
HTTP/2: 会将页面需要的CSS / Javascript等资源文件同步推送到浏览器端当浏览器请求一个页面地址返回HTML的时候，这样减少了HTTP请求的数量，加快了页面记载的时间
浏览器支持情况
说了这么多区别和HTTP/2的好处，那哪些浏览器支持HTTP/2应用层传输协议呢？
针对HTTP/2Web优化的最佳实践
翻译一下这篇文章的后面部分，针对HTTP/2Web优化的最佳实践
- 不要合并文件(Stop Concatenating Files)
在HTTP1.1的时候为了减少HTTP请求，我们会将一个页面的的css,js尽可能的打包到一个文件里面，输出一个css和js文件，大家可以去看一下webpack的打包过程，最终一个页面输出的就一个css / js文件
HTTP/2是希望能够将频繁更改和改动很少的文件分离开，然后让CDN(cache delivery network)或者浏览器缓存尽可能多的提供可复用的内容
- 不要是用行内资源(Stop Inlining Assets)
原来我们为了减少HTTP的请求，会将部分图片资源直接通过base64编码嵌入到页面中
但是现在HTTP/2,将利用上面提到的服务端推送，将页面可能需要的图片，css / js直接在客户端请求HTML文件的时候就一起推送到客户端，就像下面这段对话<html> <head> <style> body { font-size: 18px; color: #999; } </style> </head> <body> <img src="https://img-blog.csdnimg.cn/2022010617555966988.png"> <script>console.log('Hello, World!');</script> </body> </html>
"Hold on, you’re going to need this image and this CSS file to render that HTML page you just requested." -
停止是用不同的三级域名(Stop Sharding Domains)
因为在HTTP/1.1的时候是希望能够尽可能多的并行请求多个资源文件，但是每个域名下面最多可以请求3-8个请求，所以就会将资源放在不同的域名服务器上，但是HTTP/2是支持多路复用，所以没有必须这样分开存放，这样反而会影响资源加载的效率
-
一些更好的实践仍然是可以参考的(Some Best Practices Are Still Best Practices)
Fortunately, not everything about web optimization changes in HTTP/2. There’s still several HTTP/1.1 best practices that carry over to HTTP/2. The rest of this article discusses techniques that you should be leveraging regardless of whether you’re optimizing for HTTP/1.1 or HTTP/2. -
持续减少DNS的域名解析查询(Keep Reducing DNS Lookups)
Before a browser can request your website’s resources, it needs to find the IP address of your server using the domain name system (DNS). Until the DNS responds, the user is left staring at a blank screen. HTTP/2 is designed to optimize how web browsers communicate with web servers—it doesn’t affect the performance of the domain name system.
Since DNS queries can be expensive, especially if you have to start your query at the root nameservers, it’s still prudent to minimize the number of DNS lookups that your website uses. DNS prefetching via a
<link rel='dns-prefetch' href='...' />line in your document’s<head>can help, but it’s not a one-size-fits all solution. -
持续使用CDN做缓存(Keep Using a Content Delivery Network)
It takes around 130ms for light to travel around the circumference of the earth. That’s latency that you can’t get rid of—it’s just physics. The imperfect nature of fiber optic cables and wireless connections, as well as the topology of the global Internet means that it actually takes closer to 300-400ms to transmit a network packet from your computer to a server that’s halfway around the world. User’s can perceive latency as small as 100ms, and the only way to get around the laws of physics is to put your web assets geographically closer to your visitors via a CDN.
-
持续利用浏览器端来缓存资源，结合上面的不合并文件来增加命中率(Keep Leveraging Browser Caching)
You can take content delivery networks one step further by caching assets in the user’s local browser cache. This avoids any kind of data transfer over the network, aside from a 304 Not Modified response.
-
保持最小HTTP请求的大小(Keep Minimizing the Size of HTTP Requests)
Even though HTTP/2 requests are multiplexed, it takes time to transmit data over the wire. Accordingly, it’s still beneficial to reduce the amount of data you need to transfer. On the request end, this means minimizing the size of cookies, URL and query strings, and referrer URLs as much as possible.
-
保持最小HTTP响应的大小(Keep Minimizing the Size of HTTP Responses)
Of course, this holds true in the opposite direction. As a web developer, you want to make your server’s response as small as possible by minifying HTML, CSS, and JavaScript Files, optimizing images for the web, and compressing resources with gzip.
-
持续消除没有必要的重定向(Keep Eliminating Unnecessary Redirects)
HTTP 301 and 302 redirects are sometimes a fact of life when migrating to a new platform or re-designing your website, but they should be eliminated wherever possible. Redirects result in an extra round trip from the browser to the server, and this adds unnecessary latency. You should be particularly wary of redirect chains where it takes more than a single redirect to get to the destination URL.
Server-side redirects like 301 and 302 responses aren’t ideal, but they aren’t the worst thing in the world, either. They can still be cached locally, so a browser can recognize the URL as a redirect and avoid an unnecessary round trip. Meta refreshes (e.g.,
<meta http-equiv="refresh"...), on the other hand, are much more costly because they can’t be cached, and they can have performance issues in certain browsers.
1217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
