开发web前端需具备什么性能测试_web前端有哪些性能测试

　　Web前端开发是从网页制作演变而来的，名称上有很明显的时代特征。那么，你知道web前端有什么性能吗?下面由学习啦小编为大家整理的web前端性能测试，希望大家喜欢!

　　web前端性能测试

　　1. 测试目的

　　通过主要功能页面的前端性能测试，从前端分析引起页面响应缓慢的原因，并根据优化建议对其进行优化，提升前端性能，从而达到提升系统整体性能的目的。

　　2. 测试范围

　　主要对用户常用的页面进行测试，至少包括：首页、各分类页、搜索结果页等，此处我们只以首页为例进行测试和分析。

　　3. 测试方法

　　利用YSlow、PageSpeed等工具进行测试，因该网站是第三方的并不是我们自己的，所以无法进行埋点测试。其他的测试方法大家可自行练习。

　　4. WEB端测试结果分析

　　通过YSlow、PageSpeed等工具的测试后，综合结果并不算好，属于较差的情况，其中YSlow给出的评级是F(最差)，具体结果分析如下：

　　l 存在较多的HTTP请求。其中有16个external Javascript scripts，7个external stylesheets，18个external background images，这些都可以尝试进行合并。

　　l 未使用CDN。

　　l 未指定失效时间。部分CSS、JS和图片等静态资源未指定失效时间，尤其像logo这样的不经常变化的图片应该指定Expires headers，可指示浏览器从本地磁盘中加载以前下载的资源，而不是通过网络加载。

　　l 未启用压缩。部分CSS、JS和图片等静态资源未启用压缩，为这些资源资源启用压缩可将其传送大小减少135.2 KiB (68%)。

　　l 未优化图片。适当地设置图片的格式并进行压缩可以节省大量的数据字节空间。尤其是对类似客服电话.jpg这样的图片。对这些图片资源进行优化后可将其大小减少282.1 KiB (47%)。

　　l 不要在HTML中进行图片缩放。本网站有11个图片进行了缩放。YSlow给出的建议是：你希望展现多大的图片，原始的图片大小就应该是多大，图片不要比期望的尺寸小，也不要比需要的尺寸大。

　　比如，如果我们要求现实一个200x200的图片，而我们的原始图片只有100x100，访问的时候浏览器需要等待图片完全下载完毕之后才知道图片的实际尺寸，然后才会判断图片是否满足预定的尺寸大小，如果大了就要缩小，如果小了就要放大。换句话说：图片下载完毕之前，浏览器无法正确给出判断，而且图片的清晰度也可能受到影响。

　　5. 移动端测试结果分析

　　移动端发现的问题以及需要优化的资源同4.WEB端测试结果分析中的内容，除此之外，还有如下内容需要进行优化：

　　l 字体大小无法自适应，在移动端不清晰。

　　l 页面中并未设置视口。该网页在移动设备上的呈现尺寸将与在桌面浏览器中一样，因此系统会将其缩小到适合在移动屏幕上显示的尺寸。可以在Header区增加类似如下的代码：

　　在实际应用中还要注意优先级的排序，在时间充裕时，可以优化所有内容;当时间紧急时，可以通过优化优先级高且属于公共资源的元素来缩短前端页面的响应时间。

　　web网站前端性能测试

　　响应报文的状态码如下：

　　1：信息响应类，表示接收到请求并继续处理

　　2：处理成功响应类，表示动作被成功接收、理解和接收

　　3：重定向响应类，表示为了完成指定的动作，必须接收进一步处理

　　4：客户端错误，表示客户请求包含语法错误或不能正确的执行

　　5：服务端错误，表示服务器不能正确执行一个正确的请求

　　与前端性能相关的头信息：

　　1、accept-encoding：告诉服务器所接受的页面的编码方式，gzip使用gzip压缩，deflate不压缩，压缩可以减少下载所需的时间。

　　2、connection：因为HTTP是费面向连接的，无状态的协议，每一个HTTP请求都会经过“建立连接--请求页面或资源--获得资源--断开连接”的过程。对于小的资源可能建立连接的时间都会超过对资源的处理时间，为了减少时间引入了持久连接。当浏览器和服务器约定好后，当某个资源传输完成后并不立即断开连接，而是等待一段时间，在这段时间内若传输其他的资源就复用该连接，否则就关闭。当值为keep-alive时有持久连接。

　　3、expires：用于只是返回数据的到期时间。到期时间之前都是从缓存处直接获取相应的资源，之后才会向服务器发送请求获取。

　　提高前端性能的方法：

　　1、减少页面加载的时间，

　　2、减少网络时间：CDN技术，DNS缓存技术，减少文件的尺寸

　　3、减少发送的请求量：利用浏览器缓存

　　4、让页面尽早的开始显示

　　对于前段性能测试的理解：

　　由于本人之前有两三个月的时间接触了前端，对于前端的知识点比较熟悉，在这方面理解起来不是很困难，对于http协议，用户响应请求的过程都熟悉，但是那个时候并没有详细的考虑到页面的加载时间问题，只是想着将页面呈现出来，而忽略了对于响应时间的要求。由于自己都是在本机上实现的，所以每次想看结果的时候都要等很久，这就是没有使用性能的思想，去减少页面的加载时间，没有考虑周全。现在对于这方面有了更深的理解。

　　Web前端框架与类库的思考

　　1.前端框架的理解误区

　　网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的，所以在网站还很小的时候就去追求网站的架构框架是舍本逐末，得不偿失的。前端框架同理，如果是一个简单的页面型产品，应用只是依赖服务器来生成Web页面和视图，并且只需要使用一些简单的Javascript或者JQuery来使应用更加具有互动性，那么一个JQuery前端类库就可以了，真的没必要用上一些高大上的框架。

　　当然，框架的确是很有用的，重点是我们要知道什么时候该用什么框架。大公司大项目的经验和成功模式固然重要，值得学习借鉴，但我们不能因此变得盲从。只有深刻去理解前端框架，知道什么时候该用什么什么框架解决什么问题，才能有的放矢，直击要害。

　　2.前端框架与前端类库的区别

　　使用框架前，我觉得很重要的一点是弄清类库(诸如JQuery)和框架(诸如angularJS)的区别在何处。

　　简单而言，类库，解决的是代码或者是模块级别的复用或者对复杂度的封装问题，例如将一个解决复杂问题的功能模块封装成一个函数，提供一个简单的接口。库它是一种工具，它提供了很多封装好的方法，用与不用取决于我们自身，即使用了也不会影响我们呢的代码结构。

　　而框架，更多的是对模式级别的复用和对程序组织的规范。这里的模式是指比如MVC，为了实现M和V的解耦，把复杂的耦合关系由经常变化的业务代码转移到不经常变化的框架内部消化。是面向一个领域来提供一套解决方案，提高开发效率，如果我们选择了使用某框架，就应该遵循该框架所规定的规则。

　　二者最主要的区别是：JQuery以DOM操作为中心，框架，准确来说是MVC框架，是以模型(model)为中心，而DOM操作是附加的。所以，以模型为中心最终达到的目的是带来一整套工作流程的变更，使得后台工程师可以编写前端的模型代码，把后台与前端打通，交互设计师处理UI跟模型的互动关系，UI设计师可以专注、无障碍的处理HTML源码，把它们以界面模板的形式提交给交互工程师。这一整套协作机制能大大提高开发效率。使用MVC框架使得前端任务更好的被解耦。

　　3.前端MVC框架思想

　　我们知道，传统的MVC模式将一个应用划分为——模型层(model)、视图层(view)、控制层(controller)。他们在应用系统中担当不同的角色，完成不同的任务。

　　Model：即数据模型，用来包装和应用程序的业务逻辑相关的数据或者对数据进行处理，模型可以直接访问数据。

　　View：视图用来有目的显示数据，在视图中一般没有程序上的逻辑，为了实现视图上的最新功能，视图需要访问它监视的数据模型。

　　Controller：控制器调控模型和视图的联系，它控制应用程序的流程，处理事件并作出响应，事件不仅仅包括用户的行为还有数据模型上的改变。通过捕获用户事件，通知模型层作出相应的更新处理，同时将模型层的更新和改变通知给视图，使得视图作出相应改变。因此控制器保证了视图和模型的一致性。