复杂渲染引擎架构与设计--9.预热计算
前面我们在《复杂渲染引擎架构与设计–5.分片计算》一文中介绍了分片计算，即将需要计算的内容进行拆分，拆分成约每 50 ms 一个的任务。 在这个方案中，我们维护了一个待计算区域，将页面中所有未完成的计算任务放在里面，等待异步每个计算任务进行计算。 全量计算的性能瓶颈《复杂渲染引擎
前端性能优化--预加载顺序设计
随着互联网的迅速发展，现在我们前端应用能做的事情也越来越多了。随之而来的便是复杂和大数据内容的网页渲染，因此很多时候我们为了尽快给用户看到网页内容，会将页面加载拆分成首屏和其他内容。 当首屏内容渲染完后，我们会进行后续内容的预加载处理。 页面预加载对于重文本、列表、表格等网页内容
前端性能优化--FPS页面流畅度
之前分享过不少关于前端卡顿检测的内容，实际上在前端应用里，FPS 也是我们常用的一个页面流畅度的指标。 除了前面介绍的卡顿检测之外，我们还可以使用 FPS 来辅助定义用户体验。 前端页面 FPS我们都知道，帧率（英语：frame rate）是用于测量显示帧数的度量。 FPS 则是
前端性能优化--JavaScript 引擎性能
# 或许你在做性能优化的时候有听说过——尽量避免使用delete，但是为什么呢？ 这涉及到 v8 引擎的几个概念：快属性（fast properties）、隐藏类（hidden Classes）、内联缓存（IC）等。讲述 v8 引擎的文章很多，因此本文会简单进行介绍，然后以此说
前端性能优化--二进制压缩数据内容
今天也是来介绍一种性能优化的具体方式，使用二进制存储特定数据，来降低内存占用、后台存储和传输成本。 二进制数据设计当我们需要描述某种数据的许多状态时，可以考虑使用二进制的方式优化。 简单来说，就是使用二进制数字1和0来表示单个状态，然后使用二进制数字来表示多种状态的组合，比如10
前端性能优化--代码习惯
大多数情况下，前端很少遇到性能瓶颈。但如果在大型前端项目、数据量百万千万的场景下，有时候一些毫不起眼的代码习惯也可能会带来性能问题。 今天来简单介绍几种，大家在写代码的时候也可以注意。 代码细节与性能减少函数拆解很多时候，为了提高代码复用率以及提升代码可读性，我们习惯地将一些相同
前端性能优化--享元模式
之前讲到性能优化，大多数介绍的都是耗时上的一些优化，比如页面打开更快、用户交互响应更快等。不过，在最开始的《前端性能优化–归纳篇》一文中有说过，前端性能优化可以从两个角度来衡量：时间和空间，今天介绍的享元模式则用于空间下内存占用的优化。 享元模式享元是一种设计模式，通过共享对象的
项目中的技术债务
身为一名程序员，我们经常会调侃自己每天的工作就是在屎山上拉屎。这里的屎山还有一个更好的名称，叫做技术债务。 技术债务是怎么产生的我参加过许多不同的项目，而基本上每个项目都会存在或多或少的历史债务。实际上，愿意给到资源去解决历史债务的团队，更是少之又少。 业务功能的快速迭代，往往意
前端性能优化--卡顿链路追踪
我们在上一篇《前端性能优化–卡顿心跳检测》一文中介绍过基于requestAnimationFrame的卡顿的检测方案实现，这一篇文章我们将会介绍基于该心跳检测方案，要怎么实现链路追踪，来找到产生卡顿的地方。 卡顿监控实现上一篇我们提到的心跳检测，实现的功能很简单，就是卡顿和心跳事
前端性能优化--JavaScript 数组解构
之前在给大家介绍性能相关内容的时候，经常说要给大家讲一些更具体的案例，而不是大的解决方案。 这不，最近刚查到一个数组的性能问题，来给大家分享一下~ 数组解构的性能问题ES6 的出现，让前端开发小伙伴们着实高效工作了一番，我们常常会使用解构的方式拼接数组，比如： 1234// 浅拷
前端性能优化--任务管理和调度
对于一个前端应用，最理想的性能便是任何用户的交互都不会被阻塞、且能及时得到响应。 显然，当我们应用程序里需要处理一些大任务计算的时候，这个理想状态是难以达到的。不过，努力去接近也是我们可以尽量去做好的。 任务调度与性能任务调度的出现，基本上是为了更合理地使用和分配资源。在前端应用
前端性能优化--R 树的使用
听说程序员里存在一个鄙视链，而前端则在鄙视链的最底端。这是因为以前大多数的前端工作内容都相对简单（或许现在也是如此），在大多数人的眼中，前端只需要写写 HTML 和 CSS，编写页面样式便完成了。 如今尽管前端的能力越来越强了，涉及到代码构建、编译等，但依然有十分丰富且成熟的工具
前端性能优化--卡顿心跳检测
对于重前端计算的网页来说，性能问题天天都冒出来，而操作卡顿可能会直接劝退用户。
前端性能优化--用户卡顿检测
前面跟大家介绍过前端性能卡顿的检测和监控，其中提到了requestAnimationFrame心跳检测等方式来检测代码执行耗时，从而判断是否存在卡顿。 而实际上我们观察一些用户反馈，会发现这样检测的效果并不是很理想。 用户感觉的“卡”一般来说，我们会根据代码检测的任务耗时超过一定
让你的长任务在 50 毫秒内结束
虽然之前有跟大家分享过不少卡顿相关的内容，实际上网页里卡顿的产生基本上都是由于长任务导致的。当然，能阻塞用户操作的，我们说的便是主线程上的长任务。 浏览器中的长任务可能是 JavaScript 的编译、解析 HTML 和 CSS、渲染页面，或者是我们编写的 JavaScript