前端性能优化指南

Her
826 阅读24分钟

前言

谈及性能优化这个概念大多数人都会存在一种既熟悉又陌生的感觉，熟悉是因为性能优化这个概念涉及的范畴非常广，大家工作中或多或少都会接触到相关内容；说陌生是因为这个概念没有准确的定义，无法特指某一项具体技术，涉及的技术深度也可深可浅，并且没有完整的知识图谱或者系统性的文档供我们参考，大多是靠每个人在工作实践中的经验积累不断累积起来的自有知识库，小编也是根据多年的工作实践经验以及知识积累汇总起来这篇性能优化的指南，希望对你的工作提供有用的指导意义。

为什么要做性能优化

  1. 提升用户体验：较快的加载速度可以显著提升用户体验，减少用户的等待时间。提高页面交互的流畅性，减少卡顿现象，增强用户的满意度。
  2. 降低用户流失率：良好的性能和用户体验可以增加用户的留存率和转化率。有关数据表明，页面加载时间超过3秒会导致大量用户流失。
  3. 提高搜索排名：搜索引擎对加载速度较快的网站更为青睐，优化后的站点可以获得更高的搜索排名，从而带来更多的流量。
  4. 降低研发成本：通过资源压缩、合并请求、CDN等手段可以减少带宽使用，降低服务器负载，通过合理的缓存策略，也可以减少服务器的重复请求，降低服务器压力，从而降低运营成本。
  5. 提升品牌形象：快速且流畅的网站体验有助于提升品牌形象，增强用户对品牌的信任和忠诚度。

下面是一些真实的数据统计

  1. Google的数据
  • 性能优化对用户留存的影响：Google的研究表明，如果移动页面加载时间超过3秒，53%的用户会放弃访问 。
  • 加载时间与跳出率的关系：页面加载时间从1秒增加到3秒，跳出率增加32%；加载时间从1秒增加到5秒，跳出率增加90%；加载时间从1秒增加到6秒，跳出率增加106% 。
  1. Amazon的数据
  • 每100毫秒：Amazon的研究发现，每增加100毫秒的加载时间，其销售额将下降约1% 。
  1. Mozilla的数据
  • 2.2秒提升：Mozilla通过将页面加载时间减少2.2秒，下载量增加了15.4% 。

如何判定性能优化的好坏

从一名用户的角度或许他只能通过主观感受来判定一个网站的好坏，比如要等待2s或者5s才能看到页面，比如点击按钮后1s或者立刻就能给出交互反馈，作为研发人员来说我们需要把这些“感受”具象化，于是就有了一个性能评价系统，在统一的标准下，通过数据客观分析页面性能好坏，也就是下面的吸能优化指标。

性能优化指标定义

我们通常会通过以下页面性能指标来判定页面的加载性能：

  • FCP（First Contentful Paint）：页面上首个内容元素（指的是文本、图像（包括背景图像）、svg 元素或非白色的 canvas 元素）渲染完成时间，对用户感知快速加载至关重要。
  • LCP（largest contentful Paint）：页面上最大可见元素加载完成时间，关系到用户对整体页面加载完成度的感知。(FCP 只要任意内容绘制完成就触发，LCP 是最大内容渲染完成时触发)
  • TTI（Time to Interactive）：页面首次可交互时间。
  • FID（First Input Delay）：首次输入延迟时间，记录在 FCP 和 TTI 之间用户首次与页面交互时响应的延迟。
  • CLS（Cumulative Layout Shift）：累计位移偏移，记录了页面上非预期的位移波动。是整个页面声明周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。
  • SI（Speed Index）：衡量页面加载期间内容以视觉方式显示的速度。
  • TBT（Total Blocking Time）：总阻塞时间，是页面被阻塞响应用户交互的总时间。

指标的衡量标准

指标名称优秀良好需要改进
FCP[0、1800ms]（1800ms、3000ms]超过3000ms
LCP[0, 2500ms](2500ms, 4000ms]超过4000ms
TTI[0, 2500ms](2500ms, 3200ms]超过3200ms
FID[0, 100ms](100ms, 300ms]超过300ms
CLS[0, 0.1](0.1, 0.25]高于 0.25
SI[0, 3400ms][3400ms, 5800ms]超过5800ms
TBT[0, 200ms](200ms, 600ms]超过600ms

指标的检测方式

  1. 可以使用 PageSpeed Insights 在线网站或者 chrome 自带的 lighthouse 工具来进行性能测试，他俩都是在lighthouse工具的基础上开发的，检测结果一致。

截屏2024-07-01 上午10.48.27.png

  1. 另一个常用的在线检测网站是 Catchpoint
  • Catchpoint在全球范围内有多个测试点，可以从不同的地理位置对网站进行测试。
  • Catchpoint提供更全面和深度的监控和分析功能，包括多种协议支持和高级分析工具。

截屏2024-07-01 上午11.27.58.png

截屏2024-07-01 上午11.33.49.png

3.可以使用 Sentry 平台来监控线上整个站点的性能指标。Sentry是一个非常好用并且功能强大的线上监控平台，它不仅可以完成性能指标的监控，也可以对线上错误进行监控上报，甚至可以定制前端预警策略。推荐团队私有化部署sentry服务进行使用。(Sentry的性能监控功能是基于OpenTelemetry标准实现的，这是一套用于收集、处理和导出分布式系统性能数据的开源标准。Sentry通过集成OpenTelemetry，能够收集详细的性能数据并进行分析。)

截屏2024-07-01 上午11.36.51.png

截屏2024-07-01 上午11.38.43.png

如何提升性能指标

性能优化的手段有成千上万种，并且层出不穷，通过提炼和归类，可以常用并且重要的一些方法提炼成下面三大类：变小、变少、变快！！！

变小

gzip 压缩

  1. 在变小的方案中首当其冲的一定是文件压缩，也是成本最小，效果最明显的。

    我们通常会使用 gzip 压缩的方式来对 html、css、js 等文件进行压缩。

    既然效果这么好，我们为什么只对这些文件进行压缩而不对使用更多的图片文件一起使用 gzip 压缩？这个主要和gzip使用的压缩算法有关，它使用的 LZ77 算法与 Huffman 编码来压缩文件，对于重复度越高的文件可压缩的空间就越大，但是图片的重复度很低，压缩后效果并不理想，甚至可能会增大。针对于图片我们下面会讲到更具体的优化方案。

    通过对 webpack 或 vite 打包配置我们就可以开启 gzip 压缩生成 gz 文件。这里以webpack为例：

     const CompressionWebpackPlugin = require('compression-webpack-plugin');

 module.exports = {
   configureWebpack: config => {
     if (process.env.NODE_ENV === 'production') {
       config.plugins.push(
         new CompressionWebpackPlugin({
           filename: '[path][base].gz',
           algorithm: 'gzip',
           test: /\.(js|css|html|svg)$/,
           threshold: 10240,
           minRatio: 0.8,
           deleteOriginalAssets: false,
         })
       );
     }
   }
 };

    确认是否开启了gzip压缩，Etag中只有简单字符表示静态资源加载，而前面带 W/ 表示启动了服务在线压缩。

1021719821242_.pic.jpg

效果：压缩之后的文件体积会缩减 **70%** 左右。

截屏2024-07-01 下午3.54.10.png

Split chuncks 代码分割

2.按照工程优化顺序，在压缩了所有文件体积之后紧接着我们需要挑选优化之后仍然较大的文件进行分包加载，对于 vue 项目来说主要是减小 app.js 和 chunk-vendors.js 文件体积。

检测工具：对于 vue 项目可以添加--report命令： "report": "vue-cli-service build --report"，打包后会生成 report.html 文件，用来分析各文件的大小或者通过安装 webpack-bundle-analyzer 插件来分析指导优化。

截屏2024-07-01 下午4.27.51.png

split chunks 是 Webpack 提供的一种优化功能，用于将代码拆分成多个小块（chunks），以提高应用程序的加载性能和效率。通过 split chunks，可以将共享的代码模块提取到单独的文件中，减少重复代码和加快页面加载速度。

在代码分割技术我们经常使用的场景是路由懒加载方法。

使用方式：利用ES6的import()原生动态加载模块

// router 文件
component: () => import(/* webpackChunkName: "xxx" */ '@/xxx.vue')

webpackChunkName 作用是 webpack 在打包的时候，对异步引入的库代码（lodash）进行代码分割时，设置代码块的名字。

如果单个文件的体积过大（比如首页）或者引用了公共组件我们仍然可以进行代码分割采用组件按需加载方案来进一步减小文件体积。

使用方式：

<script>
const m1 = () => import(/* webpackChunkName: "m1" */ '@/components/m1');
export default {
  name: 'homeView',
  components: {
    m1
  }
}
</script>

分割前：

split.webp.webp 分割后：

split-chunks.webp

Tree shaking

3.通过使用 Tree shaking 技术进一步优化文件体积

57a2185d1300002a007c2b64.gif

Tree Shaking 是一种用于移除 JavaScript 上下文中的未引用代码 (dead-code)的技术。它依赖于 ES2015 模块语法的静态结构特性，通过在运行过程中静态分析模块之间的导入导出，确定 ESM 模块中哪些导出值未曾被其它模块使用，并将其删除，以此实现打包产物的优化。

配置方式：

  • Webpack：在生产模式下默认开启。如果想在开发环境启动 Tree shaking，需要配置：optimization.usedExports 为 true，启动标记
  • Rollup：天然支持 Tree shaking。

使用前提：确保您的代码使用 ES6 模块语法（即 import 和 export），因为 tree shaking 依赖于静态的模块依赖分析，而 ES6 模块是静态的。

示例：

// utils.js
export function usedFunction() {
  console.log('This function is used.');
}

export function unusedFunction() {
  console.log('This function is not used.');
}

// index.js
import { usedFunction } from './utils';

usedFunction();

unusedFunction 未被引用，在进行 tree shaking 后，unusedFunction 会被移除，从而减小打包后的文件大小。

变少

重绘和回流

  1. 减少重绘和回流

    浏览器渲染过程：

    1. 解析HTML： 浏览器首先解析HTML文档，生成DOM树（Document Object Model Tree）。 每个HTML标签被解析成DOM树中的一个节点。
    2. 解析CSS： 同时，浏览器解析CSS文件和嵌入式样式，生成CSSOM树（CSS Object Model Tree）。
    3. 构建渲染树： 浏览器将DOM树和CSSOM树结合，生成渲染树（Render Tree）。 渲染树包含每个将会被显示的节点及其样式信息，但不包含不显示的节点（如标签及其内容）。
    4. 布局： 浏览器计算每个渲染树节点的几何信息，即每个节点在屏幕上的位置和大小。这一步称为布局（Layout）或回流（Reflow）。
    5. 绘制： 浏览器遍历渲染树，并调用渲染器的绘制方法将内容绘制到屏幕上。这一步称为绘制（Painting）。

渲染原理.png

回流：涉及重新计算元素的位置和尺寸，影响整个DOM树或部分树。回流是高消耗的操作，尤其在包含大量节点的页面上，代价更高。

重绘：仅涉及元素外观的改变（如颜色、背景），虽然比回流开销小，但频繁的重绘仍会导致性能下降。

频繁的回流和重绘会导致页面卡顿，影响用户的交互体验。特别是在动画和滚动等需要流畅体验的操作中，这些开销尤为明显。

导致回流的操作: 任何改变元素几何属性（大小、位置、边距等）的操作都会触发回流。常见操作包括：

  • 改变元素的几何属性： width, height, margin, padding, border-width, top, left, bottom, right

  • 改变文档结构： 添加、删除或移动DOM元素 改变元素的display属性（如从none变为block）

  • 读取布局信息： offsetTop, offsetLeft, offsetWidth, offsetHeight clientTop, clientLeft, clientWidth, clientHeight scrollTop, scrollLeft, scrollWidth, scrollHeight

这些操作会强制浏览器刷新布局，从而触发回流。

导致重绘的操作: 重绘主要涉及视觉样式的改变，但不影响元素的布局。常见操作包括：

  • 改变颜色和背景： color, background, border-color visibility

  • 改变文本样式： font-size, font-weight text-decoration

  • 改变其他外观属性： box-shadow, outline opacity

防抖和节流

  1. 防抖和节流可以有效地减少事件触发的频率，从而提升网页的性能和响应速度。

防抖（Debouncing）:防抖是指在一段时间内，无论事件触发多少次，只执行最后一次操作。防抖机制会在事件触发后设定一个延迟时间，如果在这个延迟时间内没有再次触发事件，才会执行事件处理函数。如果在延迟时间内再次触发事件，则重新计时。

常用场景：

  • 输入框的联想搜索：在用户输入时，防止每个键的输入都触发一次搜索请求，而是在用户停止输入一段时间后才发送搜索请求。
  • 窗口大小调整：在用户调整浏览器窗口大小时，防止频繁触发重新布局或重绘，只在调整完成后执行一次操作。

节流（Throttling）：节流是指在一段时间内，无论事件触发多少次，只执行一次操作。节流机制会在事件触发后立即执行事件处理函数，然后在设定的时间间隔内忽略后续的事件触发，直到时间间隔结束才会再次执行。

常用场景：

  • 滚动监听：在用户滚动页面时，防止每次滚动都触发事件处理函数，只在一定时间间隔内执行一次操作。

虚拟滚动

  1. 通过虚拟滚动技术减少渲染DOM数。 我们的业务场景中经常会出现需要渲染长列表的场景，当渲染条数过多时，所需要的渲染时间会很长，滚动时还会造成页面卡顿，影响用户体验。这种情况下我们可以使用虚拟滚动来解决卡顿问题。

    虚拟滚动（Virtual Scrolling：指的是只渲染可视区域的列表项，非可见区域的不渲染，在滚动时动态更新可视区域，该方案常用于高效地渲染和管理大量数据列表或表格。

图例.jpg

下面是一个实战场景中使用虚拟滚动解决性能问题的案例，并封装了统一的npm插件供你直接使用：虚拟滚动实战案例

变快

静态资源使用CDN

  1. CDN（Content Delivery Network，内容分发网络）是一种分布式服务器系统，旨在通过将内容分发到离用户最近的服务器节点，从而加速内容交付。CDN通过将静态资源（如图片、视频、JavaScript、CSS文件等）缓存到全球各地的服务器上，实现了内容的快速传递和高可用性。

CDN的工作原理：

  • 内容缓存：当用户首次请求内容时，CDN会将该内容从源服务器拉取并缓存到最近的CDN节点。后续用户请求时，将直接从缓存节点返回内容。
  • 智能路由：CDN利用智能路由算法，将用户请求自动分配到最合适的服务器节点，以确保最快的响应速度和最佳的服务质量。
  • 负载均衡：CDN通过负载均衡技术，将用户请求分散到多个服务器节点上，确保每个节点的负载均衡，提高系统的整体性能和稳定性。
  • 地理分布：CDN在全球范围内部署了大量的节点，这些节点分布在不同的地理位置，确保用户无论身处何地，都可以快速访问内容。

资源加载

  1. 通过合理选择文件的加载方式可以显著提升性能。

    下面是几种需要重点说明的文件记载方式：

    1. 异步加载（async）：
      <script src="script.js"></script>

    特点:

    • 非阻塞渲染：不会阻塞HTML的解析和渲染，脚本会在后台加载。
    • 执行顺序不确定：脚本加载完成后立即执行，顺序无法保证。

    适用场景

    • 适用于不依赖于其他脚本或文档结构的独立脚本，如统计脚本、广告脚本等。

    1. 延迟加载（defer）
      <script defer src="script.js"></script>

    特点:

    • 非阻塞渲染：不会阻塞HTML的解析和渲染，脚本会在后台加载。
    • 执行顺序确定：在HTML解析完成后按照顺序依次执行。

    适用场景

    • 适用于依赖于文档结构且需要按顺序执行的脚本，比如 a.js 和 b.js，因为 b 依赖于 a，所以必须先引入 a，再引入 b。
     <script defer src="a.js"></script>
 <script defer src="b.js"></script>
    1. 预加载（preload）：
      <link rel="preload" href="script.js" as="script">

    特点:

    • 优先加载：浏览器会在加载HTML时优先下载这些资源，以便在需要时立即可用。
    • 资源提示：告诉浏览器这些资源在稍后将会被使用，从而提前加载。

    适用场景

    • 适用于需要提前加载但稍后才会使用的资源，如首屏的关键脚本。比如 vue2 项目打包生成的 index.html 文件，会自动给首页所需要的资源，全部添加 preload，实现关键资源的提前加载：

PRELOAD.png

4.  预获取（prefetch）：

```javascript
  <link rel="prefetch" href="script.js">
```

特点:

*   低优先级加载：浏览器会在空闲时间加载这些资源，以便在用户可能访问这些资源时更快加载。
*   未来导航优化：主要用于优化未来页面导航，将可能在未来需要的资源提前加载。

适用场景

*   适用于用户可能在未来需要但当前页面不需要立即使用的资源，如分页内容或下一步操作的资源。比如上图中 vue 项目路由懒加载页面的单独 chuncks 文件。

对比和选择：

  • 异步加载：适合独立且不依赖文档结构的脚本，提升页面加载速度。
  • 延迟加载：适合依赖文档结构的脚本，确保在HTML解析完成后执行。
  • 预加载：适合需要提前加载但稍后才会使用的资源。
  • 预获取：适合未来可能需要但当前不需要的资源。

骨架屏

  1. 骨架屏（Skeleton Screen）是一种在页面内容尚未完全加载之前显示的占位符界面。它展示了页面的基本结构和布局，让用户在等待内容加载时有一个视觉上的反馈，避免白屏效果。骨架屏通常用灰色或浅色的方块和线条表示将要加载的文本和图像位置。特别是在移动端设置中是一项很常见的性能优化手段，对于FP、FCP性能指标有较大提升作用。

各大主流UI库均可提供骨架屏组件，并且也可以自定义实现，原理和实现方案比较简单。

skeleton.png

skeleton2.png 借用骨架屏问题再补充一个在项目实战中遇到的问题，它的解决方案已经超脱了正常技术手段，作为一个趣味案例与大家共享。

问题背景：问题发生在一款面向学龄前儿童的趣味教学类app，因为面向的用户群体是儿童，所以整体设计风格色彩比较多样，不同页面色彩调性有所区别，并且页面背景复杂，每个页面都有自己专属的背景图，页面布局也相对复杂多样。

问题现象：从产品线到线上用户都反馈页面渲染较慢，白屏现象比较明显，影响用户体验。

解决历程： 我们先后尝试了资源压缩、图片尺寸和格式优化、骨架屏、懒加载、页面进场动画优化、代码逻辑和体积优化等方案，虽然优化完的数据比之前要大大提升，但是从视觉效果上还是能明显感受到白屏页面的过渡现象。

最终方案： 最终的解决方案是在上面的这些方案的基础上增加新开 webview 时设置下一个页面的背景颜色，这样就能去除白屏感官印象，减少人眼的视觉跳变感官印象：当用户从第一个页面（黄色背景）跳转到第二个页面（蓝色）时，如果中间又出现另一个高对比度变化的颜色（白色），视觉上的跳变就会很明显。人眼对颜色的变化非常敏感，尤其是高对比度的颜色变化（如白色到蓝色）。这种快速的颜色变化会让用户感觉到明显的“跳变”，即使这种变化在技术上只是几毫秒。

107_1719911793.gif

PWA

  1. PWA（Progressive Web App）是一种结合了网页和移动应用特性的新型应用模式，旨在提供类似于原生应用的用户体验。PWA利用现代Web技术（如Service Workers、Web App Manifest）来增强网页的功能和性能，使其具备离线访问、推送通知、快速加载等特点。

    PWA的核心技术之一：Service Workers

    • Service Workers是一种独立于网页运行的脚本，能够拦截和处理网络请求，提供离线缓存和后台同步等功能。
    • 主要作用：离线支持、网络请求拦截与缓存、推送通知等。

来看一个真实案例的使用收益： 通过 Chrome 中的 Application 可以查看网页的 Service Workers 信息

1081719914331_.pic.jpg

查看 Network，可以发现大量的文件已经是从 Service Worker 缓存中请求的：

1091719914435_.pic.jpg

说明网站已经应用了pwa下面来看一下数据表现 以同一个index.js文件为例，从Service Worker中加载耗时25ms：

1111719914625_.pic.jpg

强刷之后请求同一文件耗时189ms：

1121719914658_.pic.jpg

使用PWA技术带来的收益:

  • 提升性能：通过离线缓存和快速加载，提高页面响应速度，增强用户体验。
  • 提高可访问性：用户可以在无网络或网络不稳定的情况下访问应用的离线缓存内容。
  • 增强用户体验：PWA提供类似于原生应用的体验，包括离线访问、推送通知、添加到主屏幕等。

SSR 服务端渲染

  1. SSR（Server-Side Rendering）：是指在服务器端生成页面的HTML内容，然后将其发送到客户端进行渲染。与客户端渲染（CSR，Client-Side Rendering）相比，SSR可以加快初次加载时间（FCP）和提高SEO性能。

SSR技术的原理：

  1. 客户端请求：用户在浏览器中请求一个页面。
  2. 服务器端渲染：服务器接收到请求后，通过渲染引擎（如Node.js）生成页面的HTML内容。
  3. 发送HTML到客户端：服务器将生成的HTML内容发送到客户端。
  4. 客户端渲染：浏览器接收到HTML后，解析和渲染页面，然后继续加载和执行JavaScript代码。

Vue、React框架都已经存在成熟的同构框架（Nuxt.js、Next.js）来更简单的实现ssr服务端渲染（同构应用在初次加载时使用SSR生成页面内容，随后在客户端使用JavaScript接管页面的渲染和更新）。

缺点：

  • 开发、维护成本高：SSR需要在服务器端和客户端之间同步状态和数据，这增加了开发的复杂性。
  • 服务端压力大：每个用户请求都需要服务器生成HTML内容，这比静态文件的请求更耗费资源。为处理高并发和负载，可能需要更多的服务器和更强大的硬件资源，增加了基础设施成本。

图片的处理

关于图片的处理比较特殊，第一是图片的使用场景最广对性能指标的影响较大，第二是涉及到的优化方法涵盖了上面所说的变小、变少、变快三大类方案所以集中讲解比较清晰。

图片懒加载

  1. 懒加载对于需要加载大量图片的页面来说是必须要使用的技术，主要原理是仅在图片即将进入视口（viewport）时才加载它们，从而减少初始页面加载时间和带宽消耗。

converted_video_resized.gif

原理：

  • 初始加载时不加载图片：在页面初始加载时，图片标签的src属性设置为占位符图像或为空，实际的图像地址存储在其他属性（如data-src）中。

  • 检测图片进入视口：使用JavaScript监听滚动事件或使用Intersection Observer API来检测图片何时进入视口。

  • 加载实际图片：当图片即将进入视口时，JavaScript将data-src属性的值赋给src属性，触发浏览器加载实际图片。

    检测图片进入视口的实现方案有两种：

    1. 使用 Intersection Observer API。
    2. 使用滚动事件和节流来实现懒加载。 自定义插件时优先使用 Intersection Observer 这种更高效的 api，在不兼容的浏览器中使用滚动事件的监听来兼容处理，三方插件推荐常用的 vue-lazyload 实现方案已升级成以上方案。

格式选择

  1. 图片格式选择 本地图片： 图片格式及其压缩算法和应用场景各有不同，以下是一些常见的图片格式以及它们的特性、压缩方式和推荐的应用场景：

    1. JPEG

      • 压缩算法：有损压缩，优化了色彩和亮度组件。
      • 应用场景：适用于色彩丰富的照片或渐变图像。广泛用于网站上的照片展示。
      • 建议：使用渐进式JPEG可以在图像加载时先显示低质量的全图，逐渐增加清晰度，改善用户感知的加载速度。

    2. PNG

      • 压缩算法：无损压缩，使用DEFLATE算法。
      • 应用场景：适合需要透明背景、图标或者图形的图像。常用于网站的LOGO、按钮和小图标。
      • 建议：工程中多个图标文件的使用情况下建议使用雪碧图的方式调用。 截屏2024-07-04 上午10.29.58.png

    3. WebP

      • 压缩算法：支持无损和有损压缩，压缩效率高于JPEG和PNG。
      • 应用场景：适合任何类型的网页图像，尤其是在需要优化性能和减少带宽消耗的情况下。
      • 建议：优先使用WebP，因为它通常比JPEG小30%以上，同时支持透明度，是现代Web应用的优选。

    4. SVG

      • 压缩算法：XML格式的文本文件，可以通过GZIP等工具进一步压缩。
      • 应用场景：适合图标、图表和其他矢量图形，可无限放大而不失真。
      • 建议：每个项目或者每个团队都应该建立自己的字体图标库（iconfont）如阿里字体图标库来减少请求数。 截屏2024-07-04 上午10.28.12.png

    远程图片： 针对接口返回的图片注意要进行代码压缩，必要场景添加智能剪裁，按需选用图片尺寸：如下例通过改变尺寸数值可调整图片尺寸。

    size.pic.jpg

实施建议

  • 优先级排序：根据你的应用特性，确定哪些优化措施最能提升性能。例如，如果你的网站图片较多，优先考虑图片优化策略如懒加载和选择合适的图片格式。
  • 监控与评估：利用工具如sentry进行定期的性能评估。监控真实的用户交互数据，以便更准确地识别性能瓶颈。
  • 持续优化：将性能优化纳入日常开发流程，每次更新迭代时都考虑性能影响。培养团队的性能意识，鼓励采用最佳实践。

总结

希望这些性能优化的策略和技巧能帮助你构建更快、更流畅的应用。上面讲到的这些处理方法虽然会给你紧张的研发工作带来更大的时间压力，但是他们确实是日常工作中必要做的一环，它们是你页面性能质量的基本保障，也是培养你写出高质量代码，构建高质量工程的基石，每一步优化，虽小，但都是向提升用户体验和业务成功迈进的一小步,"不积跬步，无以至千里"。希望你今天又前进了一步。

avatar
文章
阅读
粉丝