-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
web优化 #43
Comments
优化场景
|
开发网页? 用户体验 | 可访问性 | 安全性 => 跟呼吸一样自然和简单 以用户为中心的性能指标 User-centric Performance Metrics
关键渲染路径(critical rendering path)
个数: 减少个数 消除/使其变得不重要 => 压缩/优化, 最小化传输字节 |
缓存避免不必要的缓存开销 对第三方的tree shaking, 还不如直接cdn化的呢 工程化/性能优化/安全 largish: 稍大的 <-- somewhat large document.body.childNodes[0].appendChild(component()); 浏览器区分资源还是通过url的 window/global/self <==> browser/node.js/serviceWorker 尝试去拉取并安装sw |
事实: 网络能力和设备能力总是不对称的
对低端网络,传输大小至关重要 两个指标:
|
服务器开启gzip,是回报率很高的一项劳作的啊 gzip后,体积反而变得更大?原本就高度压缩的了,内容比gzip所依赖存储压缩信息的成本还高 tree shaking的好处?:
自有资源和第三方资源: 第三方资源成为我们的单点故障? =》 也就是该资源不可用的时候,影响我们网页的性能和用户体验 基于文本的资源 css像素和设备像素的对应关系: 设备像素越丰富,展示的效果越细腻
如果使用光栅图片,那么设置srcset、picture =》 提供图片的多个变体 svg?也是基于文本的资源的啊,也应该剔除注释、元信息、minified、gzipped 浏览器为光栅图片(不管什么格式)的每个像素始终占据4个字节的内存(rgba四通道信息) 图片的格式选择:
三个能力:动画、透明度、浏览器支持度 多数cdn都会提供自动化图片优化服务 图片仍然是网络暴涨的原因 嘿嘿嘿, 图片优化是个精细活啊。。。 link下进行preconnect一个cdn站点,tcp消耗,tls消耗
|
预提取和预加载 预提取总是地风险的, 不会浪费用户流量 预提取/预加载技术: |
webpack的optimization.splitChunks下的智能代码分割 |
|
页面具有高可交互性,并且运行顺滑: 滚动应该像手指的滑动一样快 高性能网站和应用?
|
来来来,研究下为啥会出现卡顿感。。。(我只是分享我的发现和总结) 卡顿、===》 用户体验 我们在意的是用户体验的效果的啊 如果处于交互状态,完全是js领导化的啊 布局、绘制、合成 渲染优化?这项工作是要浏览器配合的呢 sticky scrolling, 粘黏滚动 => 页面滚动跟手指滑动一样的快的效果的啊 布局和绘制是可选的啊,在渲染流水线(rendering pipeline)里面 最后的最后再走合成路线, 将他们合并回来 paint-only属性举例: background-image, text color, shadow, background-color 这个页面有几个图层的呢, 需要通过compositor进行合并页面的啊 渲染流水线的第一个阶段: 可以引起视觉变化的统一(js、css改变、webanimation api) 渲染流水线,除了第一阶段和最后一阶段,其他的都是可选的啊
关键渲染路径?:浏览器获取资源到将它们渲染成页面的整个流程 |
BIG DEAL
资源优化
|
一帧结束的标识:像素被绘制到屏幕就好了的啊 js当然需要在一帧的开头进行尽可能早的执行:
raf?make js code run at the right point of every frame`
|
16ms? 浏览器每一帧也有内部工作要做,所以6ms给浏览器作为时间预算,那么我们就只有10ms了的啊 js代码在占据渲染流水线的时间,至多3/4的啊
|
js问啥要在渲染流水线的最前面?因为js会导致后面的任何一个渲染流水线子阶段重新执行的啊
为什么React是RIC? |
function animate() {
// Do something super rad here
requestAnimationFrame(animate);
}
requestAnimationFrame(animate) |
raf, 最低版本IE9, setTimeout来作为polyfill的效果的啊。并不是一个理想的fallback,但是可以工作的啊 可怕的可怕的啊,JS的代码都跑在帧里面的正确时间的啊 need to fill all the work inside 16ms need to fill all the work inside 16ms =》 js => style => layout => paint => composite js代码很容易在一帧里面超出一开始的时间预算 framework/library? => they has their work to do ,而不是单单你写的那些代码了的啊。哈哈 timeline? |
and interact with the site long-running JavaScript 通过Performance来查找长时间运行的JS代码的啊 sort fn? actually the built-in one is great! Performance下的各种形式的火焰图的效果和形式的啊。flame view 主线程和worker线程互不干扰, 但是可以相互通信 main: consumeData(result) postMessage(params) web worker对跑长时间js的任务来说, 无限价值的形式的啊。 spawn出一个新的ww线程 |
async,乱序。不依赖其他脚本 + 不操作DOM |
https://github.com/berwin/Blog/issues
w3c webperf会员大佬博客
嗨,送你一张Web性能优化地图
问题
如何进行系统性地页面优化
「前端进阶」从多线程到Event Loop全面梳理
从浏览器多进程到JS单线程,JS运行机制最全面的一次梳理
俚语
页面优化
浅谈script标签中的async和defer
The text was updated successfully, but these errors were encountered: