前端性能优化:客户端从输入到展示讲解

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 性能优化的根本目的:  要思考的是用户使用网站的体验如何,而不是我们可以节省多少字节,只有准确感知用户的感受,我们才有必要谈毫秒、字节和请求数量等问题。针对优化注意事项: 防止过早优化:没必要在刚开始阶段就对一个细节进行放大型的优化,因为这样的成本很高,除了代码可读性方面的东西,甚至还可能会引入更多的bug,所以,针对这个问题,我们可以在上线和运营的时候进行监控,当快暴露到问题的时候,进行整体优化。

性能优化的根本目的:
  要思考的是用户使用网站的体验如何,而不是我们可以节省多少字节,只有准确感知用户的感受,我们才有必要谈毫秒、字节和请求数量等问题。

针对优化注意事项:

  • 防止过早优化:没必要在刚开始阶段就对一个细节进行放大型的优化,因为这样的成本很高,除了代码可读性方面的东西,甚至还可能会引入更多的bug,所以,针对这个问题,我们可以在上线和运营的时候进行监控,当快暴露到问题的时候,进行整体优化。
  • 本末倒置的关注:网站内容是最重要的,应该查看页面的每个部分,看是否满足网站页面的主要目的,暂时不需要将额外的注意力全部放到一些不关乎本质的东西上。

对于性能的分析:

  • 使用浏览器的性能分析工具,得到性能分析图表,最著名的就是反向火焰图表,针对浏览器的加载和渲染一目了然。
  • 投入使用之前缺乏压力测试和性能测试

 

性能优化(从用户输入网址到客户端展现,一步一步优化)
  1.   输入网址           ==> 告诉浏览器你要去哪里


  2.   浏览器查找DNS        ==> 网络世界是IP地址的世界,DNS就是ip地址的别名。从本地DNS到最顶级DNS一步一步的网上爬,直到命中需要访问的IP地址
    a.   DNS预解析 使用CDN缓存,加快解析CDN寻找到目标地址(dns-prefetch)

 

  3. 客户端和服务器建立连接   ==>建立TCP的安全通道,3次握手
    a.  CDN加速 使用内容分发网络,让用户更快的获取到所要内容
    b.  启用压缩 在http协议中,使用类似Gzip压缩的方案(对服务器资源不足的时候进行权衡)
    c.  使用HTTP/2协议 http2.0针对1.0优化了很多东西,包括异步连接复用,头压缩等等,使传输更快

 

  4.  浏览器发送http请求      ==> 默认长连接(复用一个tcp通道,短连接:每次连接完就销毁)
    a.  减少http请求 每个请求从创建到销毁都会消耗很多资源和时间,减少请求就可以相对来说更快展示内容
      1).  压缩合并js文件以及css文件
      2).  针对图片,可将图片进行合并然后下载,通过css Sprites切割展示(控制大小,太大的话反而适得其反)
    b.  使用http缓存 缓存原则:越多越好,越久越好。让客户端发送更少请求,直接从本地获取,加快性能。
    c.  减少cookie请求 针对非必要数据(静态资源)请求,进行跨域隔离,减少传输内容大小。
    d.  预加载请求 针对一些业务中场景可预加载的内容,提前加载,在之后的用户操作中更少的请求,更快的响应
    e.  选择get和post 在http定义的时候,get本质上就是获取数据,post是发送数据的。get可以在一个TCP报文完成请求,但是post先发header,再发送数据。so,考虑好请求选型。
    f.   缓存方案选型 递进式缓存更新(防止一次性丢失大量缓存,导致负载骤多)

 

  5.  服务器响应请求        ==> tomcat、IIS等服务器通过本地映射文件关系找到地址或者通过数据库查找到数据,处理完成返回给浏览器
    a.  后端框架选型    \
               ==> 更快的响应,前端更快的操作。
    b.  数据库选型和优化 /

 

  6.  浏览器接受响应 ==> 浏览器根据报文头里面的数据进行不同的响应处理
    a.  解耦第三方依赖 越多的第三方的不确定因素,会导致web的不稳定性和不确定性
    b.  避免404资源 请求资源不到浪费了从请求到接受的所有资源

 

  7.  浏览器渲染顺序 ==> a.HTML解析开始构建dom树
    b. 外部脚本和样式表加载完毕
      a).  尽快加载css,首先将CSSOM对象渲染出来,然后进行页面渲染,否则导致页面闪屏,用户体验差
      b).  css选择器是从右往左解析的,so类似#test a {color: #444},css解析器会查找所有a标签的祖先节点,所以效率不是那么高
      c).  在css的媒介查询中,最好不要直接和任何css规则直接相关。最好写到link标签中,告诉浏览器,只有在这个媒介下,加载指定这个css
    c. 脚本在文档内解析并执行
      a).  按需加载脚本,例如现在的webpack就可以打包和按需加载js脚本
      b).  将脚本标记为异步,不阻塞页面渲染,获得最佳启动,保证无关主要的脚本不会阻塞页
      c). 慎重选型框架和类库,避免只是用类库和框架的一个功能或者函数,而引用整个文件。
    d. HTML DOM完全构造起来
      a).  DOM 的多个读操作(或多个写操作),应该放在一起。原则:统一读、统一写。
    e. 图片和外部内容加载
      a).  对多媒体内容进行适当优化,包括恰当使用文件格式,文件处理、渐进式渲染等
      b).  避免空的src,空的src仍然会发送请求到服务器
      c).  避免在html内容中缩放图片,如果你需要使用小图,则直接使用小图
    f. 网页完成加载
      a).  服务端渲染,特别针对首屏加载很重要的网站,可以考虑这个方案。后端渲染结束,前端接管展示。

 


    a) 针对首屏展示优化

      1).  图片懒加载 针对展示只加载第一屏,等用户进行滚动的时候再进行加载。如果用户对下面内容不感兴趣,那么节省的请求。

      2).  浏览器本地缓存模块   可以通过按模块去划分,将页面的模块缓存到localStory中,每次请求核对模块版本号,丢失或者版本不一致重新请求,否则直接从本地拿(参考京东)

    b) javascript优化
      1).  减少对dom节点的查询,因为每次都会重新去索引这个集合或者元素。或者查询一次缓存起来,以待接下来使用
      2).  进行js操作DOM的时候,考虑清楚页面的重绘和重排,因为这些操作相对来说十分损耗性能的。
      3).  避免使用eval和Function构造,因为解析器会将这些内容先转换成可执行代码,然后再进行接下去的操作。
      4).  减少作用域链的查找,如果一个闭包函数使用到全局作用域的数据,那么每次局部作用域都会一层一层爬到最高作用域取得数据。
      5).  数据访问,对非引用类型数据访问和局部变量的访问是最快的。所以如果对引用类型的成员(对象的属性或者数组的成员)访问超过一次,则缓存
      6).  将前端可能会使用的一些算法函数写的更优化,在时间和空间复杂度上寻找到一个最优方案。
      7).  去除重复加载同一模块脚本
      8).  智能事件处理,比如在一个div下有10个按钮,可以在冒泡过程中捕获这个事件源,然后注册

    c)  css优化
      1).  删除无用规则
      2).  内联关键CSS
      3).  避免@imports和Base64
      4).  启用高性价比属性(如opacity over rgba())
      5).  避免重复性工作
      6).  不要一条条地改变样式,而要通过改变class,或者csstext属性,一次性地改变样式。
      7).  可将元素设为display: none(需要1次重排和重绘),然后N次操作,最后恢复显示
      8).  position属性为absolute或fixed的元素,重排的开销会比较小,因为不用考虑它对其他元素的影响。

    d)  图片优化(网络请求中80%都是静态资源的请求)
      1).  图片正确格式的选择
      2).  图片尺寸的选择,在低分辨率等状况下考虑降级处理(考虑响应式图片)
      3).  使用正确的工具进行优化(有损压缩、无损压缩)
      4).  能用css处理和代理的,优先考虑css实现(阴影,滤镜等)
      5).  正确使用data url,比如说多地使用的地方,不建议data url,可考虑缓存
      6).  考虑图片的懒加载和元素可见加载方案
      7).  图片的预加载,在正确的合理的设计节点进行图片的预加载


所有性能优化总结为三个层面优化:物理层面的优化,设计层面的优化,代码层面的优化

注:设计层优化最主要的核心:衡量如何花费最少代价实现页面功能
注:HTTP/2(超文本传输协议第2版,最初命名为HTTP 2.0),是HTTP协议的的第二个主要版本,HTTP/2的目标包括异步连接复用,头压缩和请求反馈管线化并保留与HTTP 1.1的完全语义兼容。Google Chrome、Mozilla Firefox、Microsoft Edge和Opera已支持HTTP/2,并默认启用。Internet Explorer自IE 11开始支持HTTP/2,但仅限于Windows 10 Beta,并默认情况激活。

 

github地址:   鄙人厚颜无耻要颗星,这样才有动力持续更新

问题补充路径:

  1. 博客留言

  2. gerry.zhong@outlook.com

  3.github留言

相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
21天前
|
缓存 前端开发 JavaScript
利用代码分割优化前端性能:策略与实践
在现代Web开发中,代码分割是提升页面加载性能的有效手段。本文介绍代码分割的概念、重要性及其实现策略,包括动态导入、路由分割等方法,并探讨在React、Vue、Angular等前端框架中的具体应用。
|
2月前
|
前端开发 JavaScript UED
深入了解前端性能优化:提高用户体验的关键
【10月更文挑战第9天】深入了解前端性能优化:提高用户体验的关键
51 5
|
14天前
|
搜索推荐 前端开发 定位技术
前端开发人员SEO优化技术方案
不同的搜索引擎提供了服务后台常见功能来优化网站搜索
41 2
|
23天前
|
Web App开发 缓存 监控
前端性能优化实战:从代码到部署的全面策略
前端性能优化实战:从代码到部署的全面策略
21 1
|
23天前
|
Web App开发 前端开发 JavaScript
前端性能优化实战:从代码到部署的全面指南
前端性能优化实战:从代码到部署的全面指南
23 1
|
26天前
|
编解码 前端开发 JavaScript
从入门到精通:揭秘前端开发中那些不为人知的优化秘籍!
前端开发是充满无限可能的领域,从初学者到资深专家,每个人都追求更快、更稳定、更用户体验友好的网页。本文介绍了四大优化秘籍:1. HTML的精简与语义化;2. CSS的优雅与高效;3. JavaScript的精简与异步加载;4. 图片与资源的优化。通过这些方法,可以显著提升网页性能和用户体验。
19 3
|
1月前
|
缓存 前端开发 JavaScript
前端性能优化:Webpack与Babel的进阶配置与优化策略
【10月更文挑战第28天】在现代Web开发中,Webpack和Babel是不可或缺的工具,分别负责模块打包和ES6+代码转换。本文探讨了它们的进阶配置与优化策略,包括Webpack的代码压缩、缓存优化和代码分割,以及Babel的按需引入polyfill和目标浏览器设置。通过这些优化,可以显著提升应用的加载速度和运行效率,从而改善用户体验。
49 6
|
1月前
|
缓存 监控 前端开发
前端工程化:Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第26天】前端工程化是现代Web开发的重要趋势,通过将前端代码视为工程来管理,提高了开发效率和质量。本文详细对比了Webpack和Gulp两大主流构建工具的选择与配置优化,并提供了具体示例代码。Webpack擅长模块化打包和资源管理,而Gulp则在任务编写和自动化构建方面更具灵活性。两者各有优势,需根据项目需求进行选择和优化。
69 7
|
1月前
|
缓存 前端开发 JavaScript
前端工程化:Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第27天】在现代前端开发中,构建工具的选择对项目的效率和可维护性至关重要。本文比较了Webpack和Gulp两个流行的构建工具,介绍了它们的特点和适用场景,并提供了配置优化的最佳实践。Webpack适合大型模块化项目,Gulp则适用于快速自动化构建流程。通过合理的配置优化,可以显著提升构建效率和性能。
39 2
|
2月前
|
JavaScript 前端开发 测试技术
前端全栈之路Deno篇(五):如何快速创建 WebSocket 服务端应用 + 客户端应用 - 可能是2025最佳的Websocket全栈实时应用框架
本文介绍了如何使用Deno 2.0快速构建WebSocket全栈应用,包括服务端和客户端的创建。通过一个简单的代码示例,展示了Deno在WebSocket实现中的便捷与强大,无需额外依赖,即可轻松搭建具备基本功能的WebSocket应用。Deno 2.0被认为是最佳的WebSocket全栈应用JS运行时,适合全栈开发者学习和使用。
121 7