最近有空把公司的项目升级到webpack5，顺手记录下一些改造的流程。

同为程序员，在细分工种下，前端和其他方向的一个最大的区别就是除了写代码之外，还要和视觉层面上的图形打交道，对我来说这也是前端最大的魅力，因为我深知图形之美以及其奥妙之处。不过并不是所有前端都会深入图形领域，但对于所有前端来说有一门图形相关的入门课倒是必修的，那就是图标管理了。

入职一星期，做了几个项目组的常规需求，顺便过了一下小组项目的整体代码，发现的一个比较明显的问题就是由于项目本身的特点，前端的重复业务逻辑比较多，导致有大量copy&paste出现，应该需要一个减少重复逻辑上投入人力的方案。就是本文想谈到的一个思想了——完全声明式编程。

如果把一个应用比作人体，数据就相当于人体中的血液。无处不在，同样也无比重要。通过监控数据并分析其中带给我们的信息，能为应用的迭代或改进提供可靠的依据。

目前最主流的前端方案都是以组件为基本单位构建一个单页应用程序，通过REST API和后端交互，最终将所有前端代码打包为静态资源部署，如果有SEO需求，会采用服务端渲染方案，前后端分别打包再做同构。这套方案确实能应付绝大多数中小型应用场景，但量变会产生质变，随着业务发展，前端会越来越臃肿，可能组件=>应用的结构会慢慢演变成组件=>服务=>应用，不同的服务由不同的项目组负责开发，甚至会有接入完全不同技术栈的服务的需求，作为这个大型单页应用的一部分，至此不同服务之间就会有不小的沟通成本，代码编译打包性能，开发体验也会迅速下降，急需一种更有层次的解耦方案。受到后端微服务的启发，前端微服务架构也就应运而生。

相比于Vue的高度封装和自动化，React给予了开发者更高的自由度，但相对的，就要更注重性能优化相关的问题，这里就以React为入口总结一下前端应用开发中需要注意的一些常规性能优化点。

我们知道常规单页应用最终都会被webpack打包为若干js，css，入口html和各种静态资源，从http请求到入口html资源到整个应用准备完成经历了不少阶段，这篇文章就按照时间顺序分别介绍其中可优化的点。

目前浏览器已经提供了不少存储相关的API，比如localStorage,application cache等，以及各种缓存相关的策略，memory cache, disk cache等。这些方案各有优缺点，但无论哪种方案要实现精确的强缓存都存在难度，不可避免的耦合缓存检测相关的代码到主代码中。而基于Service Worker的缓存解决方案可以将检测与缓存逻辑和主代码完全解耦，并利用浏览器本身的特性平滑的控制缓存文件。

这篇文章用来梳理Webpack使用各个流程中常用的一些插件并长期更新，以便以后使用的时候能够快速索引。

前端性能优化的关键无非就是两个"快"——资源下载更快，资源解析更快。前端的预加载技术给予了我们精准控制浏览器下载资源行为的能力，即可以让我们合理安排资源下载逻辑来完成性能优化。

有时候我们打开一个网页会发生卡顿，动画不流畅的现象，没有耐心的用户可能等不到页面加载完成就关闭这个网页了。而决定一个网页的流畅度的原因，除了用户自身的网速外，网页性能也是一个很重要的指标。如何尽可能的优化也是开发者需要关注的问题，尽可能的减少重绘和重排就是方法之一。那么什么是重绘和重排呢？

前端性能优化中，缓存是非常重要的一部分。一个优秀的缓存策略可以很好的降低带宽，节省成本，并且提升用户体验。下面就分别来分析总结在web中常用的缓存类型。