前端性能优化--数据指标体系
常常进行前端性能优化的小伙伴们会发现，实际开发中性能优化总是阶段性的：页面加载很慢/卡顿 -> 性能优化 -> 堆叠需求 -> 加载慢/卡顿 -> 性能优化。 这是因为我们的项目往往也是阶段性的：快速功能开发 -> 出现性能问题 -> 优化性能
有趣的 PerformanceObserver
之前在研究小伙伴遗留代码的时候，发现了PerformanceObserver这玩意，不看不知道，越看越有意思。 其实这个 API 出了挺久了，机缘巧合下一直没有接触到，直到最近开始深入研究前端性能情况。 PerformanceObserver其实单看PerformanceObse
前端性能优化--卡顿的监控和定位
卡顿大概是前端遇到的问题的最棘手的一个，尤其是卡顿产生的时候常常无法进行其他操作，甚至控制台也打开不了。
从面试角度了解前端基础知识体系
这两年大裁员过后，带来了一系列的人员变动，常常面临着不受宠的被辞退了，能干的人跑了，剩下的人在努力维护着项目。于是乎老板们才发现人好像又不够了，然后又开始各种招人。机会一直都有，重要的还是得努力提升自己的能力，才能在这场战斗中存活下来。 前端开发中相对基础的一些内容，主要围绕着
复杂渲染引擎架构与设计--8.元素与事件
前面提到了渲染引擎的几种渲染方式，如果我们要在与用户交互的过程中识别到具体的元素，又该如何处理呢？
复杂渲染引擎架构与设计--7.离屏渲染
前面我们介绍了增量渲染的解决方案，其中有提到复用 Canvas 进行性能优化的解决方案。 本文我们将结合 Canvas 的能力提出进一步的优化方案：离屏渲染。
复杂渲染引擎架构与设计--6.增量渲染
对于渲染引擎来说，如果每次都进行完整内容的计算和绘制，在低端机器或是负责页面的时候可能会出现卡顿。 因此，我们可以考虑设计一套增量渲染的能力，来实现改多少、重绘多少，减少每次渲染的耗时，提升用户的体验。
复杂渲染引擎架构与设计--5.分片计算
前面《渲染计算》一文中，我们提到了对于长耗时的渲染计算的优化方案，其中便包括了将大的计算任务拆分为小任务的方式。 本文我们以在线表格为例子，详细介绍下如何对长耗时的计算进行任务拆解。
复杂渲染引擎架构与设计--4.渲染计算
前面《收集与渲染》一文中，我们简单提到说在一些复杂场景下，从服务端获取的数据还需要进行计算，比如依赖 Web 浏览器的计算，亦或是游戏引擎中的碰撞检测。 本文我们详细针对复杂计算的场景来考虑渲染引擎的优化。
复杂渲染引擎架构与设计--3.底层渲染适配
前面我们介绍了复杂渲染引擎中，使用的收集和渲染、以及插件等架构设计。至于底层具体的绘制实现，前面提到的多是 Canvas，实际上我们还可以适配不同的绘制引擎。
大型前端项目的常见问题和解决方案
或许你会感到疑惑，怎样的项目算是大型前端项目呢？我自己的理解是，项目的开发人员数量较多（10 人以上？）、项目模块数量/代码量较多的项目，都可以理解为大型前端项目了。 在前端业务领域中，除了大型开源项目（热门框架、VsCode、Atom 等）以外，协同编辑类应用（比如在线文档）、
复杂渲染引擎架构与设计--2.插件的实现
上一篇《收集与渲染》文章中，我们提到收集与渲染的拆分设计，对后续的业务拓展会更方便。 本文将介绍渲染插件的设计，渲染插件可用于各种新特性的拓展绘制。
复杂渲染引擎架构与设计--1.收集与渲染
对于一般的渲染引擎来说，我们可以简单地拿到待渲染的数据，然后直接通过 Canvas/DOM/SVG 来将需要渲染的图形和内容渲染出来。 而在复杂场景下，比如需要自行排版的文本、表格和图形类，光是将要渲染的数据计算出来，便容易面临性能瓶颈，而对于样式多样、结构复杂的内容来说，绘制过
如何进行前端职业规划
我们还没离开校园的时候，就已经知道要对自己未来的职业发展进行规划。但并没有人会来教会我们这些，而我们在一股脑扎进工作里以后，又常常因为忙也好因为懒也好，觉得目前状态还可以，就把职业规划也扔脑后了。 当我们想起来要考虑下自己未来工作方向的时候，常常是因为遇到了瓶颈。大多数人都是在遇
为什么项目复盘很重要
当开发的个人能力成长到一定程度时，日常工作不再是缝缝补补、修修 bug、打打下手。 开发时间足够长时，我们常常会以项目的形式参与到具体的开发中，可能会负责项目的主导，或是作为核心开发负责某个模块、某个技术方案的落地。 在项目进行的每个阶段，我们都可以通过同样的方式去提升自己：