性能优化

title: 前端性能优化01 date: 2020-01-15 09:02:52 tags: 前端性能优化 categories: 前端性能优化 目标 理解减少http请求数量和减少请求资源大小两个优化要点 掌握压缩与合并的原理 掌握通过在线网站和fis3两种实现压缩与合并的方法 浏览器的一个请求从发送到返回都经历了什么？ HTML压缩 一个简单的计算： google的流量，占到整个互联网的40%，如果google每1MB请求减少一个字节，每年可以节省500TB流量 如何进行html压缩 使用在线网站进行压缩 nodejs提供了html-minifier工具 后端模板引擎渲染压缩 CSS压缩 处理原则 无效代码删除 CSS语义合并 如何进行CSS压缩 使用在线网站进行压缩 使用html-minifier对html中的css进行压缩 使用clean-css对css进行压缩 JS压缩与混乱 处理原则 无效字符的删除 剔除注释 代码语义的缩减和优化 代码保护 如何进行JS压缩和混乱 使用在线网站进行压缩 使用html-minifier对html中的js进行压缩 使用uglifyjs2对js进行压缩 文件合并 优点 文件与文件之间有插入的上行请求，增加了N-1个网络延迟 受丢包问题影响更严重 keep-alive 经过代理服务器时可能会被断开 缺点 首屏渲染问题 缓存失效问题 解决办法

原文地址：https://mp.weixin.qq.com/s/jf9_8KADzNtkDyoxE8-HBg 上了一定规模的系统，特别是To C的系统，性能优化或多或少都会被逼着去做一下。否则，系统便无法支撑业务的发展，技术成了拖后腿，不是引领业务了。 一旦线上出现了性能问题，就会很棘手。因为它和业务功能上的Bug不同，后者的分析和解决思路更清晰，只要日志记录到位，沿着一条已知的业务逻辑线，很容易就能找到问题根源。 而性能问题就会复杂的多，导致的因素有很多，甚至会是多种因素共同作用下的结果。比如，代码质量低下、业务发展太快、架构设计不合理等等。 而且一般情况下，性能问题处理起来比较耗时，涉及到的分析链路可能会很长，特别是自己小组之外的上下游系统，很多人不愿意干，或者说有心无力。最多采用一些临时性的补救手段，碰碰运气。比如，扩容增加机器、重启大招、……。 有些临时性的补救措施，有时候不但不能解决问题，还会埋下新的隐患。 比如，从表象上看到某个程序因为给的资源不足导致产生性能问题。临时增加更多资源给它，可能从表面上看，问题是解决了。但是实则可能是因为程序内部对资源的使用上存在不合理的地方，增加资源只是延缓问题发作的时间，而且还可能会侵占其它程序的运行资源。 为了避免陷入如此的窘境，我们应当尽量提前进行性能优化，未雨绸缪。甚至最好是将它作为一个周期性的工作来进行。

2、JVM字节码 前面我们通过tomcat本身的参数以及jvm的参数对tomcat做了优化，其实要想将应用程 序跑的更快、效率更高，除了对tomcat容器以及jvm优化外，应用程序代码本身如果写的效率不高的，那么也是不行的，所以，对于程序本身的优化也就很重要了。 对于程序本身的优化，可以借鉴很多前辈们的经验，但是有些时候，在从源码角度方面 分析的话，不好鉴别出哪个效率高，如对字符串拼接的操作，是直接“+”号拼接效率高还是使用StringBuilder效率高？ 这个时候，就需要通过查看编译好的class文件中字节码，就可以找到答案。 我们都知道，java编写应用，需要先通过javac命令编译成class文件，再通过jvm执行，jvm执行时是需要将class文件中的字节码载入到jvm进行运行的。 2.1、通过javap命令查看class文件的字节码内容 首先，看一个简单的Test1类的代码： 通过javap命令查看class文件中的字节码内容： 查看Test1.txt文件，内容如下： Classfile /F:/code/itcast‐jvm/itcast‐jvm‐ test/target/classes/cn/itcast/jvm/Test1.class Last modified 2018‐9‐27; size 577 bytes MD5 checksum

性能优化： 一、减少请求资源大小或者次数　 1、尽量和并和压缩css和js文件。（将css文件和并为一个。将js合并为一个） 　　原因：主要是为了减少http请求次数以及减少请求资源的大小 　　打包工具： 　　webpack 　　gulp 　　grunt .　　.... 2、尽量所使用的字体图标或者SVG图标来代替传统png图 　　因为字体图标或者SVG是矢量图，代码编写出来的，方大不会变形，而且渲染速度快 3、采用图片的懒加载（延迟加载） 　　目的为了，减少页面第一次加载过程中http的请求次数 　　具体步骤： 　　　　1、页面开始加载时不去发送http请求，而是放置一张占位图 　　　　2、当页面加载完时，并且图片在可视区域再去请求加载图片信息 4、能用css做的效果，不要用js做，能用原生js做的，不要轻易去使用第三方插件。 　　避免引入第三方大量的库。而自己却只是用里面的一个小功能 5、使用雪碧图或者是说图片精灵 　　把所有相对较小的资源图片，绘制在一张大图上，只需要将大图下载下来，然后利用 　　图片定位来讲小图展现在页面中（background-position:百分比，数值） 6、减少对cookie的使用（最主要的就是减少本地cookie存储内容的大小），因为客户端 操作cookie的时候，这些信息总是在客户端和服务端传递。如果上设置不当，每次发送

文章目录 微信小程序数据 定时器 页面生命周期与页面路由 注意 微信小程序数据 我们知道微信小程序通过setData来进行页面数据的刷新，这个刷新就是进行绑定数据的刷新。我们进行分数检测的时候，可能出现下面的提示： 也就是说，数据中应该分为两部分，一部分是绑定在页面的，一部分是未绑定页面的。只有对进行页面刷新的时候，调用setData来进行页面绑定的数据的刷新 非绑定的不要使用setData 定时器 进行测分的时候有时会提示： 我们一般会调用setTimeout来执行一个延时操作，官方介绍： 返回一个number，是定时器的编号，可以传递给clearTimeout函数来进行取消定时器 页面生命周期与页面路由 生命周期参考 页面路由参考 我们发现onUnload生命周期，在大部分情况下都会执行： 所以， 如果我们是使用wx.navigateTo的时候，可以在onHide方法中执行清空定时器函数； 其他的可以在onUnload方法中执行清空定时器函数 注意 官方提示： 来源： CSDN 作者： snotJam 链接： https://blog.csdn.net/u010513497/article/details/103990953

1. 性能优化原则 多使用内存、缓存或其他方法 减少CPU计算量，减少网络加载耗时 （适用于所有编程的性能优化——空间换时间） 2. 从何入手 （1）让加载更快 减少资源体积，压缩代码 减少访问次数：合并代码，SSR服务器端渲染，缓存 使用更快的网络：CDN （2）让渲染更快 CSS放在head，JS放在body最下面 尽早开始执行JS，用DOMContentLoaded触发 懒加载（图片懒加载，上滑加载更多） 对DOM查询进行缓存 频繁DOM操作，合并到一起插入DOM结构 节流throttle，防抖debounce（体验性优化，让渲染更加流畅） 3. 缓存 静态资源加hash后缀，根据文件内容计算hash 文件内容不变，则hash不变，则url不变 url和文件不变，则会自动触发http缓存机制，返回304 4. SSR（Server Side Render） 服务器端渲染：将网页和数据一起加载，一起渲染 非SSR（前后端分离）：先加载网页，再加载数据，再渲染数据 早先的JSP、ASP、PHP都是SSR，现在的Vue、React用node做SSR 5. 懒加载 < img id = " img1 " src = " preview.png " data-realsrc = " abc.png " /> < script type = " text/javascript " >

一、使用mysql慢查询日志对有效率问题的sql进行监控 1）开启慢查询 show variables like ‘slow_query_log’;//查看是否开启慢查询日志 set global slow_query_log_file=‘/mysql/‘; //设置慢查询日志的位置 set global log_queries_not_using_indexes=on;//设置没有使用索引的sql语句 set global long_query_time=1;//设置超过1秒的sql语句进行记录。 注意：这里设置了long_query_time后，会发现设置不成功，可能是一个bug，需要重新开启一个终端，再查询一下设置，会发现生效了。 2）查看慢查询日志的格式 # Time: 151115 6:35:08 # User@Host: root[root] @ localhost [] # Query_time: 0.007896 Lock_time: 0.006150 Rows_sent: 200 Rows_examined: 200 SET timestamp=1447540508; select * from actor; 3）工具一：mysqldumpslow mysqldumpslow -t 3 /var/lib/mysql/localhost-centos6-slow

本文将从三部分展开介绍，逐步为读者呈现一套清晰的前端性能优化方案。 1、介绍一套合理有效的参考模型(RAIL性能模型) 2、给出一套实用的性能测试手段 3、给出基于此标准的性能提升方案（结合我们自己项目中的业务实例） 一、 参考模型 web性能优化，这是大家耳熟能详的东西了。一说到性能优化，大家可能马上就会想到从一些时间节点切入，例如： 首字节时间 白屏时间 首屏时间 用户可交互时间 DOMContentLoaded时间（页面所有内容解析完成时触发） onLoad时间（等待页面所有资源加载完成时触发） 不同的人会有不同的衡量标准，有的比较重视白屏时间，有的比较关注首屏时间，这并非是完全一致的。 而除此之外，我们可能会考虑其他方面的性能优化问题，例如： DOM渲染 60FPS动画 Javascript Benchmarks （JS基准） 手段不少，标准也很多，从这些方向着手，都会起到一定的效果， 但问题在于众多的标准往往就会导致没有标准 。 我们几乎没有人可以把时间完全投入在优化上，因此，我们需要一个标准，来告诉我们现在要去优化什么东西，或者什么东西暂时不需要优化。 想要建立一套合理有效的参考模型，就不得不谈及性能优化要解决的痛点。 那就是慢 。 所有的手段都是为了规避慢的体验 比如，一个DOM操作很慢、一个网页加载很慢、加载一个<script>很慢、JS动画很慢

更多内容关注公众号：SAP Technical 各位可以关注我的公众号：SAP Technical SAP系统提供了许多性能调优的工具，在本篇博客中，我将介绍下最常用的三种工具也即SM50, ST05, SAT. 1.工具概况 SM50 / SM66 通过这两个T-code, 可以查看当前SAP AS实例上面的工作进程，当某一工作进程长时间处于running的状态时，可以直接跳转到相应的程序位置进行查看和分析。 ST05 ST05是最常见的一个performance trance的工具，可以进行SQL、Buffer、Enqueue、RFC 、HTTP等多种类型的追踪， 通常我们使用ST05踪程序运行过程中的DB访问情况。 SAT SAT是SE30的新版本，是非常好用的一种ABAP性能分析工具，可以按照不同的类型统计程序的运行状况，这也是我本人较为喜欢使用的一个T-code。 2.工具的使用方法 2.1 SM50 / SM66 工作进程监视器 为了避免其他无关进程的干扰，通常在使用SM50 / SM66时，我们首先会过滤出与自己相关的process - 然后，在SM50中，找到并选中相关的目标程序的process，通过Administration >> Program >> Debugging即可跳转到相关的程序位置。 通过SM50中的debug跳转找到的位置，说明SAP AS

简要： 整个在浏览器的渲染过程中（页面初始化，用户行为改变界面样式，动画改变界面样式等）reflow(回流)和repaint(重绘) 会大大影响web性能，尤其是手机页面。因此我们在页面设计的时候要尽量减少reflow和repaint。 什么是reflow和repaint（原文链接：http://www.cnblogs.com/Peng2014/p/4687218.html） reflow：例如某个子元素样式发生改变，直接影响到了其父元素以及往上追溯很多祖先元素（包括兄弟元素），这个时候浏览器要重新去渲染这个子元素相关联的所有元素的过程称为回流。 reflow：几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显 示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲 染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。 repaint： 如果只是改变某个元素的背景色、文 字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器 repaint（重绘）。 repaint 的速度明显快于 reflow 下面情况会导致reflow发生 1：改变窗口大小 2：改变文字大小 3：内容的改变