浏览器内核
浏览器内核webkit
webkit是 水果 发起的开源浏览器引擎，有众多的实现：Qt，chromium，android，safari。
主要包括：
- WebCore
- JavascriptCore（默认js引擎）
排版渲染引擎，根据javascript提供的桥接接口，提供给Javascript访问DOM的能力。结合浏览器加载url流程理解，html描述--->css--->js访问Dom结构。
javascript引擎
google出名的V8引擎， 性能更优，替换掉了JavascriptCore。
- 已经用在了android（4.4开始），chromium等。
- nodejs也用的v8引擎。
tip
- chromium---开源 浏览器
- chrome ---非开源 浏览器
- chromium类似是chrome的试验版浏览器。出新功能先尝试，后移植到chrome上。
- android开源，里面浏览器用的是chromium。
渲染 术语
- SSR: 服务端渲染 serve-side Rendering ,就是在服务器上，将客户端或者通用应用程序渲染成HTML。
- CSR：Client-side Rendering，也就是在浏览器中渲染App。通常使用DOM。
- Prerender：预渲染，也就是在构建时，运行客户端应用程序，这样将它的初始状态捕获为静态HTML。
- Isomorphism：同构。指的是服务端渲染SSR时，或者Native渲染时，复用浏览器端的Javascript组件。
- TTFB：（time to first byte）首字节时间。也就是从点击链接到接收到第一个字节内容之间的时间。
- FP: （首次绘制）first paint。第一次有像素对用户可见。
- FCP: 首次内容绘制 （first contentful paint）。也就是请求内容（文章正文等）变得可见的时间。
- TTI: Time to interactive。页面变的可交互的时间（事件绑定等）。
SSR
指在服务器中生成整个页面的HTML，以此相应请求的技术。
避免了在客户端上，进行数据获取的额外往返（round-trips）和模板处理。
- 更利于SEO
- 爬虫不会执行任何脚本（google据说另外）。 用MVVM这类框架，dom元素都是根据js动态生成的，供爬虫脚本抓取的会比较少。 不利于Seo
- 服务端渲染，返回给客户端的已经是执行了javascript脚本的最终HTML。 爬虫可爬。
- 更利于首屏渲染
- 直接返回的是html字串，返回时间更短。 尤其针对像单页应用，加载东西不会那么多，首页白屏时间短。
缺点：在服务器上生成页面会有一定的耗时，可能会导致较慢的首字节时间TTFB
eg：Netflix服务器渲染，相对于静态的落地页面，同时为交互繁重的页面预拉取JS，为这些重要客户端页面提供更快的加载能力。
大多都是hydration：
- React 使用renderToString() ,或者Next.js
- VUE 使用官方渲染指南，或者Nuxt
- Angular 有Universal
静态渲染
staticRendering，静态渲染在构建时进行，并提供快速的FP FCP 和TTI。
与SSR的区别，它还致力于实现始终如一的快速首字节时间。因为界面的HTML不必动态生成，通常情况下，静态渲染，意味着为每个URL提前生成HTML文件，通过预先 生成HTML响应，可将静态html部署到多个CDN来利用边缘缓存，也就是页面静态化。页面静态化的选择很多，
无需执行太多js，区别 预渲染页面
提前为每个url生成单独的html文件 （也是缺点）
页面静态化的工具：gatsby、Jekyl 和 Metalsmith（静态）
静态渲染 和 预渲染 之间的区别：
静态渲染页面，无需执行太多客户端JS就可以交互，而预渲染也改进了单页面的FP或者FCP，由于是单页面应用，因此，必须等待客户端启动过程，通过这样来使页面真正具有可交互性。
测试方法：
- 禁用javascript并加载创建的网页。
- chrome DevTool减慢网络速度，测：在页面变的可交互之前，已经下载了多少javascript。
预渲染：通常需要更多的javascript来实现交互，并且往往这些javascript，比静态渲染使用的渐进增强方法更加复杂。
CSR客户端渲染
The PRPL pattern： （这种模式待定）
- Push critical resources for the initial URL route.
- Render initial route.
- Pre-cache remaining routes.
- Lazy-load and create remaining routes on demand.
使用HTTP/2 ServerPush 或 <link rel=preload> 可以更快的提供关键脚本和数据，助解析器更快的完成工作。
缺点：
随着项目变大，javascript库增多，polyfill和第三方代码更多，这些代码会竞争处理能力，并通常必须在渲染页面内容之前完成处理。 需考虑代码分割，并确保延时加载javascript。
交互性比较少的页面，建议考虑服务端渲染SSR来做。
通用渲染Rehydration
将 服务器渲染 和 CSR 结合起来。
缺点：
明显，用户体验。 会对可交互时间，产生负面影响。 即使改善了首次绘制。
由于js特性，Rehydration问题往往比延迟交互更复杂。
当前解决方案：
为了不让本地js再去请求数据，将ui相应数据序列化，将数据以script标签的形式存放在html文件中，结果是生成的html文档中会有大量重复的片段。
方案评估：
mobile-friendly test，可帮助你测测试你选择的方法是否符合预期。帮助展示google爬虫徐然页面的预览，执行javascript的后序列化的html内容，以及渲染过程中，发生的错误。
静态渲染和服务端渲染：尤其适用于对js交互性较低的场景。
PWA
Progressive Web App : 渐进式增强WEB应用
pwa包含的核心功能和特性如下：
- Web App Manifest
- Service Worker
- Cache API 缓存
- Push&Notification 推送与通知
- Background Sync 后台同步
- 响应式设计
Umi SSR
serverless server-side rendering
