PageSpeed 学习 [3]

06 Dec 2017

Complete guide to rails performance

Optimizing the Front-end

用Chrom DevTool的Performance对todomvc-turbolinks.herokuapp.com进行reload录制

然后放大注意看这两个地方

00D4FA66-374E-4FE5-A9D3-63B983669CFE

第一个就是request css ,第二个就是request js

这是因为js与css的记载都被设置为了异步

<script src="/assets/application.js" async="async" data-turbolinks-track="true"></script>

Remove Render-Blocking JavaScript 浏览器如果在head中发现有js需求,就会先去请求这个js,然后再下载,再执行,再回来继续渲染html

Adding Interactive with JavaScript 要解决js的render-blocking问题,就要:

  • asynchronous
  • eliminate any unnecessary JavaScript from the critical rendering path

JavaScript在浏览器中交互的特性:

  • can query and modify the Dom and the CSSOM (可以对DOM和CSSOM进行更改)
  • execution blocks on the CSSOM (可以打断CSSOM的执行,有点优先级更高的感觉)
  • blocks DOM construction unless explicitly declared as async. (也可以打断DOM的construction过程)

our script is executed at the exact point where it is inserted in the document. When the HTML parser encounters a script tag, it pauses its process of constructing the DOM and yields control to the JavaScript engine; after the JavaScript engine finishes running, the browser then picks up where it left off and resumes DOM construction.

javascript一样也是遵从html 从上到下读取的顺序,当HTML Parser 遇到了一个script tag,就会暂停下来,然后进入并启动JS Engine,等JS Engine运行完毕以后,浏览器才会回来继续DOM的construction。

当HTML Parser从上到下解析的时候,遇到了inline js,然后就停下来加载并运行js,正好这段js需要去改一些CSS的内容,而恰巧需要被改的CSS还没有被加载出来,那么js也会停下来(DOM construction依然保持暂停),两者一起等待下载并constructing CSSOM,知道需要的被加载出来,再回来执行js,js执行完了,再回来执行DOM

Optimize CSS Delivery 不要内嵌太大多css 只有在html加载完以后,才会开始加载CSS。

css在head中被读取到并发送请求下载获得css,但不会执行解析,一定是等到html解析完以后再解析css 而js则会使得某些css先进行解析。

css被下载以后的路径为: converted -> tokenized -> lexed -> constructed This process is usually the case of any “Recalculate Styles” bars. 这个过程就会造成 Recalucate Style bar 再performance工具中 如果太多Recalculate Style bar那么就说明你的css有问题,需要优化

有些时候css没有下载完就有Recalculate Style bar,可能是因为,使用了浏览器自带的css

Layout 每一次改变geometry of an element都会出发一次 layout event 而每次有改变以后,浏览器就需要整体重新计算一次 所以,脏乱差的html与css,js都会导致有过多多余的layout计算 在performance里就叫做Layout Thrashing

Avoid Large, Complex Layouts and Layout Trashing “geometric properties” 的改变就会造成layout重新计算 比如 width, height, left, top, css triggers这里有完整的列表 所以要尽量防止去改变这些数值

尽量使用性的Flexbox技术,来构建html

防止forced synchronous layout 4FABA3B3-3298-4C87-92C0-C6AD030BEB1E

会因为js的运行,强行让浏览器提前做layout的工作。

防止layout thrashing 比如你用js写一个循环,每一轮循环都做一次geometric properties的改变 这是非常糟糕的做法

其它

Network latency: 网络延迟 Race Condition: 竞争危害,混乱情况

一个暂时的小总结

优化的方向

  • 服务端后台优化,加快响应速度
  • 从request/response本身入手
    • 减少请求次数:合并css/js,小图拼成大图,缓存assets里的静态内容
    • 减少request/response的大小, 通过gzip压缩纯文本,图片是否有在gif、png、jpg中选择正确合适的格式
    • 减少物理距离:用CDN
  • 从加快浏览器渲染速度的角度考虑
    • 避免js blocking render,通过把js放最下饭,或asynchronous异步,或defer延迟加载
    • 拆分出第一屏需要的尽量少的css
    • 为静态资源设立独立域名(图片一个域名下的6个reqeust的限制)
    • 避免inline js与css
    • lazy load(不现实的内容先不加载)
  • 用户体验:
    • 第一屏最初加载的时候只加载和显示需要显示的内容,之后再加载别的
    • 预加载用户可能查看的资源

Critical Rendering Path FD5771E3-E2F8-4E50-B3FE-5E6EFF9D7A39

DOM与CSSOM的解析顺序: Characters -> Tokens -> Nodes -> DOM

能用Performance工具

  • 找到request的点
  • Parse HTML的条 和css parse bar
  • 找到css,js请求的点
  • 找到Recalculate Style与 Layout bar
  • 一但读到script 就会download script 然后 Evaluate the script

图片优化

Progressive JPEG

Progressive JPEG - Optimus 渐进式jpeg(progressive jpeg)图片及其相关 « 张鑫旭-鑫空间-鑫生活