web optimation 1-2

[dlrandy]

web 的优化基本上是指一个web的load speed

高速的web可以改善体验 电商网站一般都是2s内加载完

多一秒就会减少7% 的用户 还会影响在引擎里的搜索结果的位置

web 性能的问题在于web browser和web server的通信方式

延迟：包括request 到server的时间 ，server 响应收集数据的时间，server 返回数据到request的时间，可选的浏览器加载response的时间。

在http/1和browser通信的过程中，有一个head-of-line blocking （请求阻塞的问题） 。这是因为browser限制了一次可以发送request的数量（一般是6个）。 当有一个或者多个request正在进行，其他的已经完成的时候， 新的请求也必须等到上次的六个全部完成之后才能发送。

http/2很大的解决了head-of-line blocking 的问题。http/2可以回退到http/1的 ，在client不支持的时候。

提高web 优化的一些挑战就是做好web需求和快速serve content间的平衡

为了优化website，要能够识别需要改善的区域。这就要分析页面request数量，页面包含的数据量，页面 加载这些数据需要的时间

响应式的网站同样的网络 在不同的设备上加载的时间应该是不一样的，因为有时候为了适应不同的DPI需要使用不同的资源，比如图片

web优化的最简单的第一步就是减小传输数据的量。 可以压缩html,js,css,imag（tinypng）； 减少request请求数只适合http/1协议的； 这一步基本就是移出空白和不需要的字符。压缩的时候，要注意保留原文件 npm install minifier html-minify -g minify -o dest.min.css src.css

当然也可以在server段开启压缩 当然前段压缩后的资源还是可以交给server进行压缩的

server的压缩流程： 用户发送一个request（,header里带有Accept-Encoding来告诉server浏览器接受的压缩格式）如果server理解压缩格式的话，response里的Content-Encoding就会有使用的压缩方法。gzip现代浏览器都支持。

不同的server需要不同的步骤来配置资源的压缩的

注意有些资源是不需要的压缩，一旦压缩反而坏事，比如（jpeg，或者mp3），因为这些文件在编码的时候已经被压缩了，在进行一次压缩反而使得文件变大。

避免压缩的那些在编码的时候已经压缩了的文件类型： woff, woff2. jpeg / gif / avi / mpeg / mp3 注意jpeg和jpg是不一样的，jpeg是压缩过的，当然你说你可以简单的把.jpg改成.jpeg没有影响，

webp是可以压缩的，electron里可以使用。

npm install --save tinify

注意任何的压缩都是有损的

[dlrandy]

优化网站一般散步： 通过chrome dev tool 分析页面的重量； 减小文本类资源的size； server段进一步减小； 优化图片资源

[dlrandy]

使用 assessment tools

学习一些能够识别性能问题的工具 pagespeed insights https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.gochen.cc%2F&tab=desktop 它会分析网站然后给出如何改善性能和用户体验的建议 它分析网站的两个标准： 1、above-the-fold time(首屏时间) 2、加载整个页面的时间

inline css被认为是反模式，但是它减少了http请求，这个在http/1上是很有用的，会增加页面的渲染速度。 critical css 在http/1上是一个高效的技术，但是http2的server push修复了这个反模式。

首屏的内容不该等待后续资源的加载。所以要defer或者async load 阻塞的资源 ，或者直接在html里内置这些资源的重要部分。 https://www.smashingmagazine.com/2015/08/understanding-critical-css/

使用Google Analysis进行批量报告： 使用GA去获取PageSpeed Insights数据 （多个页面）可以给出整个网站的性能

[dlrandy]

take stock of 总结评估

[dlrandy]

Latency和TTFB不一样。TTFB不包括DNS lookup和连接到web server花费时间

和性能相关的header（response）比如Content-Encoding：Gzip，cache-control

除了页面的加载性能，还有页面的渲染性能

最初的渲染和渲染后的交互性都很重要

页面的渲染过程 解析html成DOM---》解析Css成CssDOM--》lay out 元素（render tree）--》打印页面

[dlrandy]

chrome的控制台模拟手机的时候，可以控制设备类型和DPR等

远程调试手机页面： Android： USB线插上哈 小米6打开开发者模式(setting-->我的设备-->全部参数-->MIUI版本(连续点击)) Chrome控制台seeting里找到remote devices-->Discover devices，port forwars chrome://inspect/#devices 检查手机接收请求； 手机浏览器打开调试的页面。然后在desktop的chrome的inspect/#devices,找到调试的url，点击inspect

IOS： USB线插上哈 safari里找到develop(没有 就找safari的preference) 点击develop里的某某的iphone iphone找到setting-->高级-->web inspector iPhone的safari打开调试的页面 再回到develop里找到某某的iphone-->点击监控的页面 iphone刷新

[dlrandy]

chrome里查看一个操作执行的时间可以使用 console.time('xxoo') operation console.timeEnd('xxoo')

页面性能最基本的目标就是最小化浏览器加载和渲染页面花费的时间

Jank：交互和动画的效果卡顿或是渲染的不流畅。 引起Jank的原因是单一的帧占用了太多的CPU时间。 一个帧是每秒显示时间的一个帧里浏览器做的工作(loading,scripting, painting, rendering)

掉帧可能是因为scrip触发的太频繁，loading事件太久，以及其他引起低效或者多余的rendering和painting操作。

最优的帧率是每秒60帧(60FPS), 这个取决于硬件和页面的复杂度

因为一秒相当于60FPS或者1000ms，可以简单的认为每帧16.66ms，但是每个帧里有浏览器的开销，所以，Google推荐每帧有10ms的预算

在时间线上标记点，需要使用console.timeStmp(laebl),相当于高速公路上的里程碑。可以在控制台或者js里调用这个方法.这个会在timeline上打一个小竖杠。