前端性能

我们知道，动画其实是由一帧一帧的图像构成的。有 Web 动画那么就会存在该动画在播放运行时的帧率。而帧率在不同设备不同情况下又是不一样的。 有的时候，一些复杂或者重要动画，我们需要实时监控它们的帧率，或者说是需要知道它们在不同设备的运行状况，从而更好的优化它们，本文就是介绍 Web 动画帧率（FPS）计算方法。 流畅动画的标准 首先，理清一些概念。FPS 表示的是每秒钟画面更新次数。我们平时所看到的连续画面都是由一幅幅静止画面组成的，每幅画面称为一帧，FPS 是描述“帧”变化速度的物理量。 理论上说，FPS 越高，动画会越流畅，目前大多数设备的屏幕刷新率为 60 次/秒，所以通常来讲 FPS 为 60 frame/s 时动画效果最好，也就是每帧的消耗时间为 16.67ms。 当然，经常玩 FPS 游戏的朋友肯定知道，吃鸡/CSGO 等 FPS 游戏推荐使用 144HZ 刷新率的显示器，144Hz 显示器特指每秒的刷新率达到 144Hz 的显示器。相较于普通显示器每秒60的刷新速度，画面显示更加流畅。因此144Hz显示器比较适用于视角时常保持高速运动的第一人称射击游戏。 不过，这个只是显示器提供的高刷新率特性，对于我们 Web 动画而言，是否支持还要看浏览器，而大多数浏览器刷新率为 60 次/秒。 直观感受，不同帧率的体验： 帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅

1.页面整体性能 通过浏览器提供的 window.performance.timing 方法，我们能够得到网页每个处理阶段的精确时间。打开一个页面后，这些信息会被浏览器记录下来，我们直接在控制台输出，就可以查看结果 PerformanceTiming 接口包含了当前页面中与时间相关的信息。 可以通过只读属性Performance.timing 获得实现该接口的一个对象。 var timing = window.Performance.timing; console.log(timing); 详情如下： https://developer.mozilla.org... PerformanceTiming 接口不包含任何继承属性。 PerformanceTiming.navigationStart 只读 是一个无符号long long 型的毫秒数，表征了从同一个浏览器上下文的上一个文档卸载(unload)结束时的UNIX时间戳。如果没有上一个文档，这个值会和PerformanceTiming.fetchStart相同。 PerformanceTiming.unloadEventStart 只读 是一个无符号long long 型的毫秒数，表征了unload事件抛出时的UNIX时间戳。如果没有上一个文档，or if the previous document, or one of the

本文主要考虑客户端性能、服务器端和网络性能，内容框架来自Yahoo Developer Network，包含 7 个类别共 35 条前端性能优化最佳实践，在此基础上补充了一些相关或者更符合主流技术的内容。 主流技术的内容 前端性能的一个重要指标是页面加载时间，不仅事关用户体验，也是搜索引擎排名考虑的一个因素。 来自Google的数据表明，一个有10条数据0.4秒能加载完的页面，变成30条数据0.9秒加载完之后，流量和广告收入下降90%。 Google Map 首页文件大小从100KB减小到70-80KB后，流量在第一周涨了10%，接下来的三周涨了25%。 亚马逊的数据表明：加载时间增加100毫秒，销量就下降1%。 以上数据更说明「加载时间就是金钱」，前端优化主要围绕提高加载速度进行。 一、页面内容 1. 减少HTTP请求数 Web 前端 80% 的响应时间花在图片、样式、脚本等资源下载上。最直接的方式是减少页面所需资源，但并不现实。所以，减少HTTP请求数主要的途径是： 合并JS/CSS文件。服务器端（CDN）自动合并，基于Node.js的文件合并工具，通过把所有脚本放在一个文件中的方式来减少请求数。 使用 CSS Sprite 将背景图片合并成一个文件，通过 background-image 和 background-position 控制显示 行内图片 （Base64编码）

转自公众号文章，觉得不错，拿来收藏： https://mp.weixin.qq.com/s?__biz=MzAwNDcyNjI3OA==&mid=2650843337&idx=2&sn=681c3fcbc5fdb56bbf5978921e7e5de5&chksm=80d383a0b7a40ab68f571fcd5830c69fc3d3d0ac4c9a4482cf2582a0031ce8e366e0f5215f45&mpshare=1&scene=23&srcid=0117luqxTMWcfbQiO5OgNNN3&sharer_sharetime=1579270274111&sharer_shareid=49e276b2e624f54fc5b024238a201770#rd 背景 性能优化是所有前端人的追求，在这条路上，方法多种多样。这篇文章，说一下利用浏览器的一些API，可以怎样进行自定义性能指标及上报。 PS：后面会出一篇利用chrome开发者工具进行性能分析的哦，敬请期待～ 自定义性能指标介绍 自定义性能指标这里，主要要介绍的是 Performance 接口,这个接口可以获取到当前页面中与性能相关的信息。主要包含了Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing

转自http://blog.csdn.net/five3/article/details/7686715 web前端性能： 即是web用户在访问一个页面时所要花费的时间总和。即一个完全意义上的用户响应时间，相对于服务器的响应时间而言还会包括更多的内容和影响因素。那么一个web页面的完整请求包括了哪些部分的时间总和就是web前段性能分析和优化所需要了解的基础知识，先了解一下用户从浏览器访问一个url后到页面完全展示所有内容的整个过程吧。 页面的请求过程： 1、浏览器的url请求 2、递归寻找DNS服务器 3、连接目标IP并建立TCP连接 4、向目标服务器发送http请求 5、web服务器接收请求后处理 6、web服务器返回相应的结果【无效、重定向、正确页面等】 7、浏览器接收返回的http内容 ================================前端解析分割线=========================================== 8、开始解析html文件，当然是自上而下，先是头部，后是body 9、当解析到头部css外部链接时，同步去下载，如果遇到外部js链接也是下载【不过js链接不建议放在头部，因为耽误页面第一展现时间】 10、接着解析body部分，边解析边开始生成对应的DOM树，同时等待css文件下载 11、一旦css文件下载完毕

昨天参加37互娱的笔试时有个这样的问题： 说说你所知道的提高前端开发效率的工具或方法？ 说实话，确实知道的不多，于是从网上搜了下，挺不错，故转载之： http://www.jianshu.com/p/cdf777f13ff6 内容分发网络（CDN） CDN 可以帮你把网站的资源分发到世界各地，有助于提高网站的响应速度，当然，这对于那些特殊地区的用户是收效甚微的。 CloudFlare CloudFlare 的强大之处在于它可以成为你的 DNS 服务器（CDN 只是它所有服务的一个组成部分），这样对你的网站发起的所有请求都会经过它。 CloudFlare 的 CDN 在过去十五年的设计和发展中，并没有一味的守旧和固步自封。我们的专利技术中充分利用了最新的技术进步，包括并不限于硬件、web 服务器和网络路由。换言之，我们创新的建设了下一代的 CDN。新的 CDN 配置简单、价格低廉，其性能也一定比你使用过的任何传统 CDN 都要优秀。 MaxCDN CSS-Tricks 当前就在使用 MaxCDN 托管所有的静态资源。它可以无缝地融合 WordPres 和 W3 的所有缓存资源，所以我们无需做什么特别处理，即可将资源移入 CDN，并能保证链接的准确性。 对于一个博客来说，考虑到其中的大文件主要是 JavaScript、CSS 和图片，而不是视频等类型，这带宽占用的可真多。 我们的

1.文件优化 图片优化 一些修饰类图片可用CSS代替 将多个图标文件整合到一张图片中 （CSS Sprite） 选择正确的图片格式： gif无损压缩，适合logo、线条等小型简单图像 jpeg适合照片、渐变图像 PNG-8相对于GIF来讲有对alpha透明通道的支持，PNG-24会比JPEG，GIF，PNG-8占用更多的存储空间 svg适合简单的平面矢量形状，复杂的渲染时需要较多计算。 计算图片大小  对于一张 100 _ 100 像素的图片来说，图像上有 10000 个像素点，如果每个像素的值是 RGBA 存储的话，那么也就是说每个像素有 4 个通道，每个通道 1 个字节（8 位 = 1 个字节），所以该图片大小大概为 39KB（10000 _ 1 * 4 / 1024）。 其他文件优化 静态资源使用 CDN加载 重要的CSS文件放head中,其他可以放底部或动态加载 将耗时的js代码使用 Web Workers 执行 <script>标签 放在底部，避免阻塞渲染 动态脚本加载，向DOM中插入<script>标签 给标签加上 defer或async defer ，表示该文件会并行下载，但是会放到 HTML 解析完成后顺序执行。 没有任何依赖的JS文件可以加上async，表示加载和渲染后续文档元素的过程将和 JS 文件的加载与执行并行无序进行。 2.懒执行、懒加载、预加载、预渲染

DNS查询也消耗响应时间，如果我们的网页内容来自各个不同的domain (比如嵌入了开放广告，引用了外部图片或脚本)，那么客户端首次解析这些domain也需要消耗一定的时间。DNS查询结果缓存在本地系统和浏览器中一段时间，所以DNS查询一般是对首次访问响应速度有所影响。下面是我清空本地dns后访问网页dns的查询请求。 避免页面跳转 当客户端收到服务器的跳转回复时，客户端再次根据服务器回复中的location指定的地址再次发送请求，例如以下跳转回复。 HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html 当客户端遇到这种回复的时候，用户只能等待客户端再次发送请求，有的网站甚至会一直跳n次，跳到他想带你去的地方…当然在这个时候用户看不到任何页面内容，只有浏览器的进度条一直在刷新。 80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等)。减少请求次数是缩短响应时间的关键！可以通过简化页面设计来减少请求次数，但页面内容较多可以采用以下技巧。 1. 捆绑文件: 现在有很多现成的库可以帮你将多个脚本文件捆绑成一个文件，将多个样式表文件捆绑成一个文件，以此来减少文件的下载次数。例如在asp

最近在研究页面渲染及web动画的性能问题，以及拜读 《CSS SECRET》 （CSS揭秘）这本大作。 本文主要想谈谈页面优化之 滚动优化 。 主要内容包括了为何需要优化滚动事件，滚动与页面渲染的关系，节流与防抖，pointer-events:none 优化滚动。因为本文涉及了很多很多基础，可以对照上面的知识点，选择性跳到相应地方阅读。 滚动优化的由来 滚动优化其实也不仅仅指滚动（scroll 事件），还包括了例如 resize 这类会频繁触发的事件。简单的看看： var i = 0; window.addEventListener('scroll',function(){ console.log(i++); },false); 输出如下： 在绑定 scroll 、resize 这类事件时，当它发生时，它被触发的频次非常高，间隔很近。如果事件中涉及到大量的位置计算、DOM 操作、元素重绘等工作且这些工作无法在下一个 scroll 事件触发前完成，就会造成浏览器掉帧。加之用户鼠标滚动往往是连续的，就会持续触发 scroll 事件导致掉帧扩大、浏览器 CPU 使用率增加、用户体验受到影响。 在滚动事件中绑定回调应用场景也非常多，在图片的懒加载、下滑自动加载数据、侧边浮动导航栏等中有着广泛的应用。 当用户浏览网页时，拥有平滑滚动经常是被忽视但却是用户体验中至关重要的部分。当滚动表现正常时

好的设计应该简单，而且始终可以提供最佳性能。 一、优化原因 谷歌的数据表明，一个有10条数据0.4秒可以加载完的页面，在变成30条数据加载时间为0.9秒后，流量和广告收入减少了20%。当谷歌地图的首页文件大小从100kb减少到70~80kb时，流量在第一周涨了10%，接下来的三周涨了25%。 腾讯的前端工程师根据长期的数据监控也发现页面的一秒钟延迟会造成9.4%的PV的下降，8.3%跳出率的增加以及3.5%转化率的下降。 可以看出，性能优化商业上来说很重要。 但是，更重要的还是屏幕前我们的用户，让用户在使用产品时有更快更舒适的浏览体验，这算是一种前端工程师的自我修养。 二、优化目标 以让用户满意为目标呈现网页是终极的目标。当然页面速度要快，不过快只是构成满意的一个因素。 我们使用Google团队提出的RAIL模型作为优化的目标。 目前国内包括腾讯在内的团队都在使用这个评估方案。 Response:100ms内响应； Animation:10ms内生成一帧； Idle:最大程度增加空闲时间； Load：1000ms内呈现内容； 1）以用户为中心 User-centered 用户是性能优化的中心，一切性能优化皆是为了用户获得更佳的体验。 那么，我们的用户如何评价性能延迟： 0-16ms 用户可以感知每秒渲染 60 帧的平滑动画转场。也就是每帧 16 毫秒 留给应用大约 10