7 天打造前端性能监控系统

引言

前阵子在w3ctech走进名企 – 百度前端 FEX 专场上曾“夸下海口”说听完讲座后七天就可以打造自己的前端性能监控系统,既然说出去了也不能食言。从前一篇文章前端数据之美相信大家对前端数据有了一定的了解,下面就针对其中的性能数据及其监控进行详细阐述。

开始行动

本文中的性能主要指 web 页面加载性能,对性能还不了解?不用担心,接下来的“每一天”跟我一起进入前端性能的世界。

Day 1 为什么要监控性能?

“If you cannot measure it, you cannot improve it” ———— William Thomson

这是一个最基本的问题,为什么要关注和监控前端性能?对于公司来说,性能在一定程度上与利益直接相关。国外有很多这方面的调研数据:

性能 收益
Google 延迟 400ms 搜索量下降 0.59%
Bing 延迟 2s 收入下降 4.3%
Yahoo 延迟 400ms 流量下降 5-9%
Mozilla 页面打开减少 2.2s 下载量提升 15.4%
Netflix 开启 Gzip 性能提升 13.25% 带宽减少50%

数据来源:http://www.slideshare.net/bitcurrent/impact-of-web-latency-on-conversion-rates http://stevesouders.com/docs/jsdayit-20110511.pptx

为什么性能会影响公司的收益呢?根本原因还是在于性能影响了用户体验。加载的延迟、操作的卡顿等都会影响用户的使用体验。尤其是移动端,用户对页面响应延迟和连接中断的容忍度很低。想象一下你拿着手机打开一个网页想看到某个信息却加载半天的心情,你很可能选择直接离开换一个网页。谷歌也将页面加载速度作为 SEO 的一个权重,页面加载速度对用户体验和 SEO 的影响的调研有很多

尽管性能很重要,开发迭代过程中难免会有所忽视,性能会伴随产品的迭代而有所衰减。特别在移动端,网络一直是一个很大的瓶颈,而页面却越来越大,功能越来越复杂。并没有简单的几条黄金规则就可以搞定性能优化工作,我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈,指导优化工作的进行。

Day 2 有什么可用的工具?

工欲善其事必先利其器

页面性能的评估与监控有很多成熟优秀的工具,合理利用已有工具能达到事半功倍的效果。下面简单介绍几个常用的工具:

Page Speed

Page Speed 是谷歌开发的分析和优化网页的工具,可以作为浏览器插件使用。工具基于一系列优化规则对网站进行检测,对于未通过的规则会给出详细的建议。与此类似的工具还有 Yslow 等,推荐使用gtmetrix网站同时查看多个分析工具的结果,如下图所示:

gtmetrix

WebPagetest

WebPageTest 是一款非常优秀的网页前端性能测试工具,已开源。可以使用在线版,也可以自己搭建。国内也有利用 WebPagetest 搭建的性能测试平台,推荐使用阿里测 (以下示例使用阿里测进行测试)。

使用 WebPagetest,你可以详细掌握网站加载过程中的瀑布流、性能得分、元素分布、视图分析等数据。其中比较直观的视图分析功能可以直接看到页面加载各个阶段的截屏:

webpagetest

: 整个测试结果请点击此处

上图直观地展现了浏览类网站两个重要的时间点:白屏时间和首屏时间,即用户多久能在页面中看到内容,以及多久首屏渲染完成(包含图片等元素加载完成)。这两个时间点直接决定了用户需要等待多久才能看到自己想看到的信息。谷歌优化建议中也提到减少非首屏使用的 css 及 JS,尽快让首屏呈现。

PhantomJS

PhantomJS轻松地将监控带入了自动化的行列。Phantom JS 是一个服务器端的 JavaScript API 的 WebKit,基于它可以轻松实现 web 自动化测试。PhantomJS 需要一定编程工作,但也更灵活。官方文档中已经有一个完整的获取网页加载 har 文件的示例,具体说明可以查看此文档,国内也有不少关于此工具的介绍。另外新浪@貘吃馍香开发的类似工具berserkJS也挺不错,还贴心的提供了首屏统计的功能,具体文章可以查看此处

Day 3 开始线上真实用户性能监控

取其所长,避其所短

到此肯定有同学问,既然有这么多优秀的工具,为什么要监控线上用户真实访问性能呢?

我们发现,工具模拟测试会在一定程度上与真实情况偏离,有时无法反映性能的波动情况。另外除了白屏首屏之类的基础指标,产品线同样关注产品相关的指标,例如广告可见、搜索可用、签到可用等,这些功能直接与页面 JS 加载相关,通过工具较难模拟。

为了持续监控不同网络环境下用户访问情况与页面各功能可用状况,我们选择在页面中植入 JS 来监控线上真实用户访问性能,同时利用已有的分析工具作为辅助,形成一套完整多元的数据监控体系,为产品线的评估与优化提供可靠的数据。

关于不同监控方式的简单对比可以查看下表:

类型 优点 缺点 示例
非侵入式 指标齐全、客户端主动监测、竞品监控 无法知道性能影响用户数、采样少容易失真、无法监控复杂应用与细分功能 Pagespeed、PhantomJS、UAQ
侵入式 真实海量用户数据、能监控复杂应用与业务功能、用户点击与区域渲染 需插入脚本统计、网络指标不全、无法监控竞品 DP 、Google 统计

Day 4 如何采集性能数据?

监控用户的痛点

线上监控哪些指标呢?如何更好地反映用户感知?

对于用户来说他感觉到的为什么页面打不开、为什么按钮点击不了、为什么图片显示这么慢。而对于工程师来说,可能关注的是 DNS 查询、TCP 连接、服务响应等浏览器加载过程指标。我们根据用户的痛点,将浏览器加载过程抽取出四个关键指标,即白屏时间、首屏时间、用户可操作、总下载时间(定义可见上篇文章)。这些指标是如何统计的呢?

确定统计起点

我们需要在用户输入 URL 或者点击链接的时候就开始统计,因为这样才能衡量用户的等待时间。如果你的用户高端浏览器占比很高,那么可以直接使用Navigation Timing接口来获取统计起点以及加载过程中的各个阶段耗时。另外也可以通过 cookie 记录时间戳的方式来统计,需要注意的是 Cookie 方式只能统计到站内跳转的数据。

统计白屏时间

白屏时间是用户首次看到内容的时间,也叫做首次渲染时间,chrome 高版本有 firstPaintTime 接口来获取这个耗时,但大部分浏览器并不支持,必须想其他办法来监测。仔细观察 WebPagetest 视图分析发现,白屏时间出现在头部外链资源加载完附近,因为浏览器只有加载并解析完头部资源才会真正渲染页面。基于此我们可以通过获取头部资源加载完的时刻来近似统计白屏时间。尽管并不精确,但却考虑了影响白屏的主要因素:首字节时间和头部资源加载时间。

如何统计头部资源加载呢?我们发现头部内嵌的 JS 通常需等待前面的 JS\CSS 加载完才会执行,是不是可以在浏览器 head 内底部加一句 JS 统计头部资源加载结束点呢?可以通过一个简单的示例进行测试:

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="UTF-8"/>
    <script>
      var start_time = +new Date; //测试时间起点,实际统计起点为 DNS 查询
    </script>
    <!-- 3s 后这个 js 才会返回 -->
    <script src="script.php"></script>  
    <script>
      var end_time = +new Date; //时间终点
      var headtime = end_time - start_time; //头部资源加载时间    
      console.log(headtime);
    </script>
    </head> 
    <body>     
    <p>在头部资源加载完之前页面将是白屏</p>
    <p>script.php 被模拟设置 3s 后返回,head 底部内嵌 JS 等待前面 js 返回后才执行</p>
    <p>script.php 替换成一个执行长时间循环的 js 效果也一样</p>  
    </body>
</html>

经测试发现,统计的头部加载时间正好跟头部资源下载时间相近,而且换成一个执行时间很长的 JS 也会等到 JS 执行完才统计。说明此方法是可行的(具体原因可查看浏览器渲染原理及 JS 单线程相关介绍)。

统计首屏时间

首屏时间的统计比较复杂,因为涉及图片等多种元素及异步渲染等方式。观察加载视图可发现,影响首屏的主要因素的图片的加载。通过统计首屏内图片的加载时间便可以获取首屏渲染完成的时间。统计流程如下:

首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内,找出加载最慢的一张 -> 首屏时间

这是同步加载情况下的简单统计逻辑,另外需要注意的几点:

  • 页面存在 iframe 的情况下也需要判断加载时间
  • gif 图片在 IE 上可能重复触发 load 事件需排除
  • 异步渲染的情况下应在异步获取数据插入之后再计算首屏
  • css 重要背景图片可以通过 JS 请求图片 url 来统计(浏览器不会重复加载)
  • 没有图片则以统计 JS 执行时间为首屏,即认为文字出现时间

统计用户可操作和总下载

用户可操作默认可以统计domready时间,因为通常会在这时候绑定事件操作。对于使用了模块化异步加载的 JS 可以在代码中去主动标记重要 JS 的加载时间,这也是产品指标的统计方式。

总下载时间默认可以统计onload时间,这样可以统计同步加载的资源全部加载完的耗时。如果页面中存在很多异步渲染,可以将异步渲染全部完成的时间作为总下载时间。

网络指标

网络类型判断

对于移动端来说,网络是页面加载速度最大的影响因素,需要根据不同的网络来采取相应的优化措施,例如对于 2G 用户采用简版等。但 web 上没有接口获取用户的网络类型。为了获取用户网络类型,可以通过测速的方式来判断不同 IP 段对应的网络。测速例如比较经典的有 facebook 的方案。经过测速后的分析,用户的加载速率有明显的分布区间,如下图所示:

gtmetrix

各个分布区间正好对应不同的网络类型,经过与客户端的辅助测试,成功率可以在 95%以上。有了这个 IP 库对应的速率数据,就可以在分析用户数据时根据 IP 来判断用户网络类型。

网络耗时统计

网络耗时数据可以借助前面提到 Navigation Timing 接口获取,与之类似的还有Resource Timing,可以获取页面所有静态资源的加载耗时。通过此接口可以轻松获取 DNS、TCP、首字节、html 传输等耗时,Navigation Timing 的接口示意图如下所示:

gtmetrix

以上重点介绍了数据采集部分,这也是系统中最关键的一部分,只有保证数据能真实反映用户感知,才能对症下药提升用户体验。数据采集完之后我们可以在页面加载完之后统一上报,如示例:

http://xxx.baidu.com/tj.gif?dns=100&ct=210&st=300&tt=703&c_dnslookup=0&c_connecting=0&c_waiting=296&c_receiving=403&c_fetch_dns=0&c_nav_dns=75&c_nav_fetch=75&drt=1423&drt_end=1436&lt=3410&c_nfpt=619&nav_type=0&redirect_count=0&_screen=1366*768|1366*728&product_id=10&page_id=200&_t=1399822334414

### Day 5 如何分析性能数据?

让数据会说话

而数据分析过程,如前一篇文章所述,可以从多个维度去分析数据。大数据处理需要借助 hadoop、Hive 等方式,而对于普通站点则任意一种后端语言处理即可。

均值与分布

均值与分布是数据处理中最常见的两种方式。因为它能直观的表示指标的趋势与分布状况,方便进行评估、瓶颈发现与告警。处理过程中应去除异常值,例如明显超过阈值的脏数据等。

耗时的评估中,有很多这方面的研究数据。例如有人提出三个基本的时间范围:

  • 0.1秒 : 0.1 秒是用户感知的最小粒度,在这个时间范围内完成的操作被认为是流畅没有延迟的
  • 1.0秒 : 1.0 秒内完成的响应认为不会干扰用户的思维流。尽管用户能感觉到延迟,但 0.1 秒 -1.0 秒内完成的操作并不需要给出明显 loading 提示
  • 10秒 : 达到 10 秒用户将无法保持注意力,很可能选择离开做其他事情

我们根据业界的一些调研,结合不同指标的特点,制定了指标的分布评估区间。如下图所示:

gtmetrix

评估区间的制定方便我们了解当前性能状况,同时对性能趋势波动做出反应。

多维分析

为了方便挖掘性能可能的瓶颈,需要从多维的角度对数据进行分析。例如移动端最重要的维度就是网络,数据处理上除了总体数据,还需要根据网络类型对数据进行分析。常见的维度还有系统、浏览器、地域运营商等。我们还可以根据自身产品的特点来确定一些维度,例如页面长度分布、简版炫版等。

需要注意的是维度并不是越多越好,需要根据产品的特点及终端来确定。维度是为了方便查找性能瓶颈

小插曲 :之前从微博中看到有人评价说想做监控但是公司没有日志服务器。并不需要单独的日志服务器,只要能把统计的这个请求访问日志保存下来即可。如果网站自己的独立服务器都没有还有解决办法,在百度开发者中心新建一个应用,写一个简单的 Web 服务将接收到的统计数据解析存到百度云免费的数据库中,然后每天再用 Mysql 处理下当天的数据即可,对于普通站点的抽样性能数据应该没问题。请叫我雷锋。

Day 6 如何利用监控数据解决问题?

发现瓶颈,对症下药

对于图表制作,比较出名的有Highcharts,百度开发的Echarts也很不错。不管使用什么工具,最关键的一点就是让报表能突出重点,直观明了

制作报表前多问几个如何让人直观看到目前状况和可能存在的问题,哪些地方可以加强,哪些可以去掉,使用是否习惯等。

gtmetrix

有了能反映用户感知的真实世界、并且细分到各个业务功能,有详细的网络等辅助数据,我们在解决前端性能上便更加得心应手。监控系统已经对线上访问状况有了连续的反馈,根据现有评估与瓶颈选择对应方案进行优化,最后根据反馈进行调整,相信性能优化不再是个难题。

如何选择优化方案呢?这又是一个比较大的话题了,好在已经有很多经验可以借鉴。附录中就整理了部分性能的学习资料,可以根据需要阅读学习。

gtmetrix

Day 7 总结

通过以上“几天”的努力,我们可以搭建一个小而美的前端性能监控系统。但这仅仅是开始,前端数据有很多挖掘的价值。性能优化也是一门需要认真学习的课程,为了打造流畅的使用体验,为了让用户更加满意,赶紧搭建起自己的前端数据平台吧!

该文写在w3ctech走进名企 – 百度前端 FEX 专场之后,分享时的 PPT 在这里,视频在这里

华丽非分割线 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

福利——前端性能学习资料整理

性能准则 ★★★★★

分析工具 ★★★

入门

  • pageSpeed 基于谷歌性能准则的检测,可浏览器安装插件运行
  • Yslow 基于雅虎性能准则的检测工具,可浏览器安装插件运行
  • pageCheck 百度内部开发,指标齐全,支持自动运行

进阶

  • webPageTest 查看页面加载瀑布流等数据,进阶必备工具
  • Chrome 开发者工具 功能强大,值得学习
  • PhantomJS 功能强大的分析工具,高手必备瑞士军刀
  • JsPerf JS 执行性能分析网站,谁用谁知道

浏览器与 Html 标准 ★★

入门

进阶

开发实战 ★★★★

通用

动画与渲染

移动端开发

性能监控 ★★★★

相关会议 ★★★

推荐博客 ` ★★★`

一言不合就动手系列篇一-仿电商平台前端搜索插件(filterMore)

话说某年某月某日,后台系统需要重构,当时公司还没有专业前端,由我负责前台页面框架搭建,做过后台系统的都知道,传统的管理系统大部分都是列表界面和编辑界面。列表界面又由表格和搜索框组成,

对于全部都是输入框的搜索条件开发起来很简单,用户体验上却差很多。开始了漫漫寻找寻插件之路,最终无果。一言不合决定参考互联网风格的筛选条件自己动手仿造一款插件。

最终filterMore诞生了,源代码已开源至GitHub:https://github.com/CrazyJson/filterMore

演示图片

阅读目录

插件介绍

  目地

       fiterMore是本人开源的第一框前端插件,基于bootstrap部分样式,旨在帮助开发者轻松实现现代化风格的筛选条件。参考某东,某宝的筛选条件。

  特性

  1. 首款开源筛选插件
  2. 参数配置项多,功能强大
  3. 轻量级(8k)
  4. 支持所有流行的浏览器

     插件来源

在开发该插件前,本着拿来主义的精神,寻找了很多前端插件库,没有找到类似插件。只能自己动手,经过差不多一年的项目检验,足步完善,自认为已经比较成熟。 她尽可能地在以更少的代码展现更强健的功能,且格外注重性能的提升、易用和实用性。当然,这种“王婆卖瓜”的陈述听起来总是有点难以难受,因此你需要进一步了解她是否真的如你所愿。

参数说明

初始化参数大全
参数名 字符类型 释义说明 默认值 使用频率
searchBoxs Array 筛选条件项,详情参见searchBoxs参数大全 null 必须
search function 查询事件,回调函数参数paramList为筛选条件 null 常用
expandRow integer 展开筛选条件行数 2 常用
expandEvent function 展开更多条件触发事件 参数:state true表示展开 false 收缩 一般可用来改变表格高度 null 常用
paramkey string 参数收集时返回值的Key ValueList 不常用
paramCustomkey string 参数收集时自定义条件返回值的Key CustomList 不常用
searchOnSelect boolean 点击选项时是否触发查询事件 true 不常用
searchBoxs参数大全
参数名 字符类型 释义说明 默认值 使用频率
id string 筛选条件项id,在查询回调事件的参数时会用上 没传会使用1,2,3… 必须
title string 筛选条件显示标题 null 必须
data Array 选项数据,数据格式[{value:’1′,text:’语文’},{value:’2′,text:’数学’}] null 必须
isMultiple boolean 是否允许条件多选 false 常用
type string 存在自定义日期区间时需设定 值可为 datetime(年月日时分秒) | date(年月日) null 常用
defaults Array 默认选中值,为空则选中全部 null 常用
custom object 自定义筛选,详情参见custom参数大全 null 常用
valueField string 选项数据 键字段名称 value 不常用
textField string 选项数据 值字段名称 text 不常用
isShowAll boolean 是否显示选项中的全部 true 不常用
custom参数大全
参数名 字符类型 释义说明 默认值 使用频率
isRange boolean 是否区间,用于控制自定义输入框个数 为false一个输入框 true两个输入框 false 非必须
event function 点击确定按钮回调事件,函数体申明如下 function(start,end){} isRange为false时 start有值 end:undefined isRange为true时都有值 ,函数返回值为boolean类型 为false时不触发查询事件 null 常用
方法大全
方法名 方法功能 参数 返回值 返回值说明
getParamList 获取搜索条件参数 array[] :[ {{“CustomList”:[“2016-09-01 00:00:00″,”2016-09-15 00:00:00″] //自定义区间值 ,”isMultiple”:false,”id”:”CreatedTimeOne”}, {“ValueList”:[“1″] //选中值,”isMultiple”:false,”id”:”CreatedTime”}, {“ValueList”:[“0″,”1″],”isMultiple”:true,”id”:”Status”}, {“ValueList”:[],”isMultiple”:false,”id”:”Createor”} ]
searchFunctionCall searchBox对外提供的调用函数 {“setValue”:[]} key为要调用的函数名称 value:为函数调用参数 依据具体函数定 setValue函数为赋值函数 调用如下 $(“.searchbox”).searchFunctionCall({setValue:[{“ValueList”:[“1″],”id”:”CreatedTime”}]}) getParamList函数为取值函数 调用如下 $(“.searchbox”).searchFunctionCall({getParamList:null})

使用案例

 基本例子

复制代码
//引用css
<link rel="stylesheet" href="https://crazyjson.github.io/filterMore/dist/css/fiterMore.min.css">
//页面使用一个占位Div
<div class="searchbox" id="basic_searchbox"></div>
//引用js
<script src="jquery-1.11.1.min.js"></script>
<script src="https://crazyjson.github.io/filterMore/dist/filterMore.min.js"></script>
复制代码

初始化

复制代码
 var options = {
            //查询事件
            "search": function (paramList) {
                $("#basic_searchbox_param").html('查询参数:'+JSON.stringify(paramList));
            },
            //默认展开条件数
            "expandRow": 2,
            //查询条件
            "searchBoxs": [
                {
                    "id": "Status_Basic",
                    "title": "任务状态",
                    "isMultiple":true,
                    "data": [
                        { "value": "0", "text": "运行" },
                        { "value": "1", "text": "停止" }
                    ]
                },
                {
                    "id": "Createor_Basic",
                    "title": "创建人",
                    "data": [
                        { "value": "admin", "text": "系统管理员" },
                        { "value": "zhangsan", "text": "张三" }
                    ]
                }
            ]
        };
        $("#basic_searchbox").fiterMore(options);
复制代码

演示地址:https://crazyjson.github.io/filterMore/demo/index.html#basic

  日期自定义

View Code
  展开条件回调事件
View Code
  默认值
  数据源格式自定义
  方法调用

总结

开源插件filterMore介绍完成,插件BUG或者建议的可以联系我。

GitHub地址 : https://github.com/CrazyJson/filterMore

在线演示地址:  https://crazyjson.github.io/filterMore/demo/index.html

跨域请求的几种实现方式

什么是跨域?

同源策略是由Netscape提出的著名安全策略,是浏览器最核心、基本的安全功能,它限制了一个源(origin)中加载文本或者脚本与来自其他源(origin)中资源的交互方式
,所谓的同源就是指协议、域名、端口相同。
当浏览器执行一个脚本时会检查是否同源,只有同源的脚本才会执行,如果不同源即为跨域

跨域的几种方式

在项目中可能会需要在一个域名下请求另外一个域名的资源,下面我们来探讨下跨域的几种实现方式

1、jsonp

最常见的一种跨域方式,其背后原理就是利用了script标签不受同源策略的限制,在页面中动态插入了script,script标签的src属性就是后端api接口的地址,并且以get的方式将前端回调处理函数名称告诉后端,后端在响应请求时会将回调返还,并且将数据以参数的形式传递回去。

前端:

//http://127.0.0.1:8888/jsonp.html
var script = document.createElement('script');
      script.src = 'http://127.0.0.1:2333/jsonpHandler?callback=_callback'
      document.body.appendChild(script);      //插入script标签
      //回调处理函数 _callback
      var _callback = function(obj){
          for(key in obj){
            console.log('key: ' + key +' value: ' + obj[key]);
          }
      }

后端:

//http://127.0.0.1:2333/jsonpHandler
app.get('/jsonpHandler', (req,res) => {
  let callback = req.query.callback;
  let obj = {
    type : 'jsonp',
    name : 'weapon-x'
  };
  res.writeHead(200, {"Content-Type": "text/javascript"});
  res.end(callback + '(' + JSON.stringify(obj) + ')');
})

在jsonp.html中打开控制台可以看到返回数据的输出:

jsonp.png

2、CORS

Cross-Origin Resource Sharing(跨域资源共享)是一种允许当前域(origin)的资源(比如html/js/web service)被其他域(origin)的脚本请求访问的机制。
当使用XMLHttpRequest发送请求时,浏览器如果发现违反了同源策略就会自动加上一个请求头:origin,后端在接受到请求后确定响应后会在Response Headers中加入一个属性:Access-Control-Allow-Origin,值就是发起请求的源地址(http://127.0.0.1:8888),浏览器得到响应会进行判断Access-Control-Allow-Origin的值是否和当前的地址相同,只有匹配成功后才进行响应处理。

现代浏览器中和移动端都支持CORS(除了opera mini),IE下需要8+

前端:

//http://127.0.0.1:8888/cors.html
var xhr = new XMLHttpRequest();
xhr.onload = function(data){
  var _data = JSON.parse(data.target.responseText)
  for(key in _data){
    console.log('key: ' + key +' value: ' + _data[key]);
  }
};
xhr.open('POST','http://127.0.0.1:2333/cors',true);
xhr.setRequestHeader('Content-Type','application/x-www-form-urlencoded');
xhr.send();

后端:

//http://127.0.0.1:2333/cors
app.post('/cors',(req,res) => {
  if(req.headers.origin){
    res.writeHead(200,{
      "Content-Type": "text/html; charset=UTF-8",
      "Access-Control-Allow-Origin":'http://127.0.0.1:8888'
    });
    let people = {
      type : 'cors',
      name : 'weapon-x'
    }
    res.end(JSON.stringify(people));
  }
})

可以在开发者工具里面看到请求的详细信息,并且在控制台也可以看到返回的数据输出:

response header.png

cors console.png

3、服务器跨域

在前后端分离的项目中可以借助服务器实现跨域,具体做法是:前端向本地服务器发送请求,本地服务器代替前端再向api服务器接口发送请求进行服务器间通信,本地服务器其实就是个中转站的角色,再将响应的数据返回给前端,下面用node.js做一个示例

前端:

//http://127.0.0.1:8888/server
var xhr = new XMLHttpRequest();
    xhr.onload = function(data){
      var _data = JSON.parse(data.target.responseText)
      for(key in _data){
        console.log('key: ' + key +' value: ' + _data[key]);
      }
    };
    xhr.open('POST','http://127.0.0.1:8888/feXhr',true);  //向本地服务器发送请求   
    xhr.setRequestHeader('Content-Type','application/x-www-form-urlencoded');
    xhr.send("url=http://127.0.0.1:2333/beXhr");    //以参数形式告知需要请求的后端接口

后端:

//http://127.0.0.1:8888/feXhr
app.post('/feXhr',(req,res) => {
  let url  = req.body.url;
  superagent.get(url)           //使用superagent想api接口发送请求
      .end(function (err,docs) {
          if(err){
              console.log(err);
              return
          }
          res.end(docs.res.text); //返回到前端
      })
})

//http://127.0.0.1:2333/beXhr
app.get('/beXhr',(req,res) => {
  let obj = {
    type : 'superagent',
    name : 'weapon-x'
  };
  res.writeHead(200, {"Content-Type": "text/javascript"});
  res.end(JSON.stringify(obj));     //响应
})

回到 http://127.0.0.1:8888/server 页面打开控制台可以看到数据输出:

console.png

4、postmessage跨域

在HTML5中新增了postMessage方法,postMessage可以实现跨文档消息传输(Cross Document Messaging),Internet Explorer 8, Firefox 3, Opera 9, Chrome 3和 Safari 4都支持postMessage。
该方法可以通过绑定window的message事件来监听发送跨文档消息传输内容。
使用postMessage实现跨域的话原理就类似于jsonp,动态插入iframe标签,再从iframe里面拿回数据
,私认为用作跨页面通信更加适合

总结

当然还有其他实现跨域的方式比如在ie8、9下XDR跨域方案,flash方案,以上是一些常用的跨域方案,都各有利弊,比如:jsonp只能发送get请求、cors会忽略cookie、服务器跨域需要另起服务器等等,大家可以根据自己项目需求选择适合的解决方案,如果对于跨域还有其他看法或者文中出现错误,欢迎大家留言:)

参考文献:

 

文/weapon_x(简书作者)
原文链接:http://www.jianshu.com/p/a63c29e0c863
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

九个Console命令,让js调试更简单

一、显示信息的命令

   1: <!DOCTYPE html>
   2: <html>
   3: <head>
   4:     <title>常用console命令</title>
   5:     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6: </head>
   7: <body>
   8:     <script type="text/javascript">
   9:         console.log('hello');
  10:         console.info('信息');
  11:         console.error('错误');
  12:         console.warn('警告');
  13:     </script>
  14: </body>
  15: </html>

最常用的就是console.log了。

二:占位符

console上述的集中度支持printf的占位符格式,支持的占位符有:字符(%s)、整数(%d或%i)、浮点数(%f)和对象(%o)

   1: <script type="text/javascript">
   2:         console.log("%d年%d月%d日",2011,3,26);
   3: </script>

效果:
image

三、信息分组

   1: <!DOCTYPE html>
   2: <html>
   3: <head>
   4:     <title>常用console命令</title>
   5:     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6: </head>
   7: <body>
   8:     <script type="text/javascript">
   9:         console.group("第一组信息");
  10:
  11:         console.log("第一组第一条:我的博客(http://www.ido321.com)");
  12:
  13:         console.log("第一组第二条:CSDN(http://blog.csdn.net/u011043843)");
  14:
  15:       console.groupEnd();
  16:
  17:       console.group("第二组信息");
  18:
  19:         console.log("第二组第一条:程序爱好者QQ群: 259280570");
  20:
  21:         console.log("第二组第二条:欢迎你加入");
  22:
  23:       console.groupEnd();
  24:     </script>
  25: </body>
  26: </html>

效果:
image

四、查看对象的信息

console.dir()可以显示一个对象所有的属性和方法。

   1: <script type="text/javascript">
   2:         var info = {
   3:             blog:"http://www.ido321.com",
   4:             QQGroup:259280570,
   5:             message:"程序爱好者欢迎你的加入"
   6:         };
   7:         console.dir(info);
   8: </script>

效果:
image

五、显示某个节点的内容

console.dirxml()用来显示网页的某个节点(node)所包含的html/xml代码。

   1: <!DOCTYPE html>
   2: <html>
   3: <head>
   4:     <title>常用console命令</title>
   5:     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6: </head>
   7: <body>
   8:     <div id="info">
   9:         <h3>我的博客:www.ido321.com</h3>
  10:         <p>程序爱好者:259280570,欢迎你的加入</p>
  11:     </div>
  12:     <script type="text/javascript">
  13:         var info = document.getElementById('info');
  14:         console.dirxml(info);
  15:     </script>
  16: </body>
  17: </html>

效果:
image

六、判断变量是否是真

console.assert()用来判断一个表达式或变量是否为真。如果结果为否,则在控制台输出一条相应信息,并且抛出一个异常。

   1: <script type="text/javascript">
   2:       var result = 1;
   3:       console.assert( result );
   4:       var year = 2014;
   5:       console.assert(year == 2018 );
   6: </script>

1是非0值,是真;而第二个判断是假,在控制台显示错误信息
image

七、追踪函数的调用轨迹。

console.trace()用来追踪函数的调用轨迹。

   1: <script type="text/javascript">
   2: /*函数是如何被调用的,在其中加入console.trace()方法就可以了*/
   3:   function add(a,b){
   4:         console.trace();
   5:     return a+b;
   6:   }
   7:   var x = add3(1,1);
   8:   function add3(a,b){return add2(a,b);}
   9:   function add2(a,b){return add1(a,b);}
  10:   function add1(a,b){return add(a,b);}
  11: </script>

控制台输出信息:
image

八、计时功能

console.time()和console.timeEnd(),用来显示代码的运行时间。

   1: <script type="text/javascript">
   2:   console.time("控制台计时器一");
   3:   for(var i=0;i<1000;i++){
   4:     for(var j=0;j<1000;j++){}
   5:   }
   6:   console.timeEnd("控制台计时器一");
   7: </script>

运行时间是38.84ms
image

九、console.profile()的性能分析

性能分析(Profiler)就是分析程序各个部分的运行时间,找出瓶颈所在,使用的方法是console.profile()。

   1: <script type="text/javascript">
   2:       function All(){
   3:             alert(11);
   4:          for(var i=0;i<10;i++){
   5:                 funcA(1000);
   6:              }
   7:         funcB(10000);
   8:       }
   9:
  10:       function funcA(count){
  11:         for(var i=0;i<count;i++){}
  12:       }
  13:
  14:       function funcB(count){
  15:         for(var i=0;i<count;i++){}
  16:       }
  17:
  18:       console.profile('性能分析器');
  19:       All();
  20:       console.profileEnd();
  21:     </script>

输出如图:
image

前端学习路径

作者:余博伦
链接:https://zhuanlan.zhihu.com/p/21935921
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

什么是前端工程师?

总而言之前端工程师就是运用HTML/CSS/JavaScript等Web技术,在工作中配合设计师实现用户界面,和后端工程师进行数据对接,完成Web应用开发的职位。

开发工具

设计软件

前端工程师最首要的任务就是把设计师的设计图切好并翻译成代码,所以我们要学习一些设计软件的基础操作和切图方法。

编辑器

工欲善其事,必先利其器。可以用的编辑器和IDE有很多,在这里我只推荐最棒的两个。

代码管理

不光要学会写代码,也要学会管理你的代码。在工作中你可能会遇到需要自己部署代码的情况;不停地修改迭代重构,当然也需要你掌握版本控制软件。

测试工具

预览和调试必不可少,编写前端代码的大部分时间都是在编辑器和浏览器之间切来切去。

  • Chrome Dev Tools 谷歌浏览器开发工具,想要预览调试你的前端页面必须在这里啦

基础知识

中级知识

高级知识

服务器端

技能图谱

在线资源

在线教程

在线书籍

推荐书目

H5、React Native、Native应用对比分析

H5、React Native、Native应用对比分析

离上次在北京开源中国盛典已经快一个月了,有点想念@oschina的小伙伴了。我必须承认oschina是国内最大的同性社交网站,这也是无可争议的事实,但是,我真想的是妹子!!![偷笑]。从上次演讲后,有一些同学陆陆续续问我演讲的PPT在哪,还有不少同学希望看到[手稿],这学习精神,在下实在是佩服啊。有着这么热情的小伙伴,我激动不已啊,所以在此公布[手稿],方便大家可以将[PPT]和[手稿]双手齐下,:)。2015年,我们要一起努力完成以前吹过的牛逼…..  下面是[多图预警],请考虑切wifi,土豪请无视我,也可拿红包砸我,:)

---------------华丽丽的分割线,主题开始---------------------

“存在即合理”。凡是存在的,都是合乎规律的。任何新事物的产生总要的它的道理;任何新事物的发展总是有着取代旧事物的能力。React Native来的正是时候,一则是因为H5发展到一定程度的受限;二则是移动市场的迅速崛起强调团队快速响应和迭代;三则是用户的体验被放大,用户要求极致的快感,除非你牛x(例如:12306最近修改手机号需要用户自己发短信接收验证码)。

以下简单的介绍下H5、React Native、Native的含义:

最近三四年间,国内外的前端与全栈开发者社区都在坚持不懈地追寻使用JavaScript与HTML、CSS技术体系开发App内场景的核心工程技术。这种技术,在国内很多公司与团队中,被通称为H5。——童遥

这段是取自@童老师给小二我新书作的序,没有断章取义的意思。很清楚,H5并不是狭义的HTML5新标签和API,而是工程化的“In App” technology。

iOS/Android ——原生应用(都懂得,不解释)。

React Native —— React & Native ,应运而生!

一、React Native的出现

React Native的出现,似乎是扛起的反H5的旗子。就像当年Facebook放弃H5,全部转向Native一样。这一点,我们需要认同和保持高度的清醒。那么,React Native是否又是在吞食Native的领地呢?技术的发展,是用户风向标的导向起的作用。任何一门技术的出现,都是当时用户需求的体现。

我们应该从以下几点看待React Native的出现。

“鉴往知来”——从过去的教训中总结经验,从用户的角度开拓未来,用户更希望产品迭代和稳定寻求一种平衡
“HTML5差强人意,但是与原生应用相比还是有些差距”——为了更高的追求! 用户体验!
“人才宝贵,快速迭代”——Web开发者相对较多,寻找平衡点
“跨平台!跨平台!跨平台!”——单一技术栈,开发者的福音
“xx是世界上最好的语言” ——工程学的范畴,没有最好,只有最适合,我还是补充一句,JS还是很好很好的。

HTML5 vs React Native ? HTML5 : React Native
结论(React Native):
1、原生应用的用户体验
2、跨平台特性
3、开发人员单一技术栈
4、上手快,入门容易
5、社区繁荣

二、3款应用效果

注:以下所有对比均在iOS平台下



上面3张图片,如果去掉第一张图的“HybirdApp”的字样,是否分得清哪个是React Native开发?哪个是Native应用。
你的第一感觉是什么?

三、工程方案

为了评估3种方案的技术优势和弱势。我们需要开发功能大致相似的App。这里,我们使用了“豆瓣”的API来开发“豆搜”应用。该应用能够搜索“图书”、“音乐”、“电影”。想当年,豆瓣以“图书评论”走红,尤其是12年当红!豆瓣是一个清新文艺的社区,一个“慢公司”。最近有一则网传消息,注意是网传——“传京东投1.5亿美元控股豆瓣”。今天,不聊豆瓣,我们要聊一个工程化的问题。

我们需要将3款App的功能做到一致,同时需要保持技术要点一致。比如React Native这里使用了TabBar,那么Native我们也必须使用TabBar。简单而言就是:功能一致,组件 & API一致。我们功能如下图所示:

1、H5方案
在H5/Hybird应用中,我们使用AngularJS开发单页webApp,然后将该WebApp内嵌入到iOS WebView中,在iOS代码中,我们使用Navigation稍微控制下跳转。
WebApp地址:http://vczero.github.io/search/html/index.html
WebApp项目地址:https://github.com/vczero/search (很简单的一个项目)
H5/Hybird项目地址:https://github.com/vczero/search_Hybird

2、React Native
在React Native中,封装必要的功能组件。
项目地址:https://github.com/vczero/React-Dou。
项目结构如下图:

3、Native(iOS)
使用React Native大致相同的组件开发App,不使用任何第三方库,代码布局。
项目地址:https://github.com/vczero/iOS-Dou

四、对比分析

很多时候,新技术的采用最希望看到的是数据,而不是简单说“用户体验棒,开发效率高,维护成本低”。不过,生活中也有这样的同学,知一二而能窥全貌。当然,本人生性胆小,也没有那么多的表哥和隔壁的老王,所以不敢早下定论,不敢太放肆。赵本山在《大笑江湖》中有句名言“May the force be with you”(别太放肆,没什么用)。因此,从以下几个方面做一个简单的对比。

---------------分析提纲----------------

1、开发方式

(1)代码结构
(2)UI布局
(3)UI截面图
(4)路由/Navigation
(5)第三方生态链

2、性能 & 体验

(1)内存
(2)CPU
(3)动画
(4)安装包体积
(5)Big ListView
(6)真机体验

3、更新 & 维护

(1)更新能力
(2)维护成本
-----------------提纲---------------

1、开发方式

很多人说React Native的代码不好看,不好理解。那是因为前端工程师都熟悉了Web的开发方式。怎么解决这个问题呢,可以先看看iOS代码,断定不熟悉iOS的同学心里会默念“一万匹**马奔腾”。那时候,你再看React Native,你会觉得使用React Native开发App是件多么美好的事!OK,我们先来看下三者在开始“一款简单App”的代码结构。
(1)代码结构
H5/Hybird的开发模式,我们需要维护3套代码,两套是Native(iOS/Android)代码,一套是WebApp版本。这里,我们使用AngularJS作为WebApp单页开发框架。如下图所示。

在React Native中,同样需要关注部分的Native代码,但是大部分还是前端熟悉的JavaScript。在“豆搜”应用中,代码结构如下:

在Native开发中,更加强调Native开发者的能力。平台是:iOS/Android。

结论:从前端角度而言,React Native跨平台特性,不要开发者深入的了解各平台就能开发一款高效App。同时,语言层面而言,JavaScript运用很广泛,入门门槛相对较低。React Native虽然抛弃了MVC分离实践,但是从业务角度而言,更为合理。一切而言:对前端,对移动领域是利好的消息。

(2)UI布局
“面容姣好”,合理的UI却总是跟着时间在变。那么UI布局就不是小事。
Web开发布局目前大多是 DIV + CSS。
React Native的布局方式是Flexbox。

   //JSX
  <ScrollView style={styles.flex_1}>
    <View style={[styles.search, styles.row]}>
      <View style={styles.flex_1}>
        <Search placeholder="请输入图书的名称" onChangeText={this._changeText}/>
      </View>
      <TouchableOpacity style={styles.btn} onPress={this._search}>
        <Text style={styles.fontFFF}>搜索</Text>
      </TouchableOpacity>
    </View>
    {
      this.state.show ?
      <ListView
        dataSource={this.state.dataSource}
        renderRow={this._renderRow}
        />
      : Util.loading
    }
  </ScrollView>
  //样式
  var styles = StyleSheet.create({
      flex_1:{
        flex:1,
        marginTop:5
      },
      search:{
        paddingLeft:5,
        paddingRight:5,
        height:45
      },
      btn:{
        width:50,
        backgroundColor:'#0091FF',
        justifyContent:'center',
        alignItems:'center'
      },
      fontFFF:{
        color:'#fff'
      },
      row:{
        flexDirection:'row'
      }
    });

而Native布局就有种让你想吐的感觉,尤其是iOS的布局。这里不是指采用xib或者Storyboard,而是单纯的代码,例如添加一个文本:

UILabel *publisher = [[UILabel alloc]init];
publisher.frame = CGRectMake(bookImgWidth + 10, 50, 200, 30);
publisher.textColor = [UIColor colorWithRed:0.400 green:0.400 blue:0.435 alpha:1];
publisher.font = [UIFont fontWithName:@"Heiti TC" size:13];
publisher.text = obj[@"publisher"];
[item addSubview:publisher];

总结:React Native既综合了Web布局的优势,采用了FlexBox和JSX,又使用了Native原生组件。比如我们使用一个文本组件。
<Text style={{width:100;height:30;backgroundColor:'red'}}>测试</Text>

(3)UI截面图
Hybrid方式截面图

可以看到第一层列表页是完整的布局,实际上这就是Web页面;而第二层灰色的是Native的WebView组件。
iOS UI截面图


可以看到Native页面的组件特别多,即使是列表页,其中某一项都是一个组件(控件)。

当然,我们就会想,能够完全调用原生组件呢?那样性能是否更好?
React Native UI截面图


可以清楚的看到React Native调用的全部是Native组件。并且层次更深,因为React Native做了组件的封装。如上图,蓝色边框的就是RCTScrollView组件。这就是React Native相比H5更高效的原因。

(4)路由/Navigation
在Web单页面应用中,路由由History API实现。
而React Native采用的路由是原生的UINavigationController导航控制器实现。
React Native NavigatorIOS组件封装程度高;Navigator可定制化程度高。
Navigator方法如下:

getCurrentRoutes() - returns the current list of routes
jumpBack() - Jump backward without unmounting the current scene
jumpForward() - Jump forward to the next scene in the route stack
jumpTo(route) - Transition to an existing scene without unmounting
push(route) - Navigate forward to a new scene, squashing any scenes that you could jumpForward to
pop() - Transition back and unmount the current scene
replace(route) - Replace the current scene with a new route
replaceAtIndex(route, index) - Replace a scene as specified by an index
replacePrevious(route) - Replace the previous scene
immediatelyResetRouteStack(routeStack) - Reset every scene with an array of routes
popToRoute(route) - Pop to a particular scene, as specified by its route. All scenes after it will be unmounted
popToTop() - Pop to the first scene in the stack, unmounting every other scene

相对Native而言,这些接口更Native还是很相似的。

//iOS UINavigationController  
//相对Web而言,不用自己去实现路由,并且路由更加清晰         
[self.navigationController pushViewController:detail animated:YES];

“豆搜” WebApp路由(基于AngularJS)如下:

“豆搜” React Native版本导航如下:

“豆搜” iOS版本导航代码如下:

总结:React Native封装的导航控制更容易理解。

(5)第三方生态链
“我的是我的,你的也是我的。 ”——我不是“疯狂女友”,我是React Native!
我们缺少“城市列表”组件,OK,使用JSX封装一个;觉得性能太低,OK,基于React Native方案封装一个原生组件。
这个iOS图表库不错,拿来用呗! => 完美!
这一切都是基于React Native提供的模块扩展方案。
所以说:iOS第三方库 + 部分JavaScript库 = React Native 生态库(可以知道,基于React Native的扩展方案是多么方便)

2、性能 & 体验

我们都很关注一款App性能。因此测试和体验App的性能很重要。以下测试,都是基于相同的case。
测试平台:模拟器,iphone6,iOS8.4
(1)内存
首先,我们来看下Native应用占用的内存情况。一开始,原生应用启动后,占用内存是20~25M;针对相同的case,跑了2min,结果如下图:

可以看出,峰值是87.9M,均值是72M;内存释放比较及时。

我们再来看下Hybird App的情况。App已启动,占用内存35~55M;同样,跑了2min以上,结果如下图:

可以看出,峰值在137.9M,因为整个应用在WebView中,内存释放不明显,存在缓存。

最后,看下React Native的情况。App启动占用内存35~60M,同样跑2min以上,结果如下图:

可以看出,峰值在142M,内存相对释放明显。

总结:React Native和Web View在简单App上相差不大。二者主要:内存消耗主要是在网页数据上。

(2)CPU
我们可以看一下Native应用程序CPU的情况,最高值在41%。

Hybird App的最高值在30%。

React Native的最高值在34%。

总结:CPU使用率大体相近,React Native的占用率低于Native。

(3)动画
React Native提供了Animated API实现动画。简单效果,基本OK。个人觉得React Native不适合做游戏,尤其布局能力。
Native Animation提供UIView动画
H5/Hybird:采用js动画能力
总结:React Native Animated API / 封装Native动画库 可以满足基本需求

(4)安装包体积
Hybird App:
34(App壳) + 5(HTML) + 125(Angular) + 29(An-route) + 6(min.js) + 4(min.css) = 203 KB。

React Native:
不含bundle: 843KB
含bundle: 995KB

Native
83KB

React Native框架包大小
843(不含bundle) – 32(Hybird_app空壳,初识项目) = 811KB

相比快速迭代和热更新,比Native多了811KB一点都不重要,我们将图片素材、静态资源线上更新缓存起来即可减少很多体积。
总结:牺牲一点体积,换更大的灵活性!(世界上哪有那么美的事,除非丑,就会想得美,:) )。

(5)Big ListView & Scroll 性能
循环列表项500次: H5页面惨不忍睹
React Native还可以接受
Native 采用UITabView更高效,因为不渲染视图外部分。

(6)真机体验
机型:iphone4s,iOS7
Native > React Native > Hybird
如果非要给个数字的话,那我个人主观感受是:
Native: 95%+ 流畅度
React Native: 85~90% 流畅度
H5/Hybird: 70% 流畅度

总结:Native/React Native的体验相对而言更流畅。

3、更新 & 维护

(1)更新能力
H5/Hybird: 随时更新,适合做营销页面,目前携程一些BU全部都是H5页面;但是重要的部分还是Native。
React Native:React Native部分可以热更新,bug及时修复。
Native:随版本更新,尤其iOS审核严格,需要测试过关,否则影响用户。

(2)维护成本
H5/Hybird: Web代码 + iOS/Android平台支持
React Native:可以一个开发团队 + iOS/Android工程师;业务组件颗粒度小,不用把握全局即可修改业务代码。
Native:iOS/Android开发周期长,两个开发团队。

总结:React Native 统一了开发人员技术栈,代码维护相对容易。

五、综合

1、开发方式

(1)代码结构: React Native更为合理,组件化程度高
(2)UI布局:Web布局灵活度 > React Native > Native
(3)UI截面图:React Native使用的是原生组件,
(4)路由/Navigation:React Native & Native更胜一筹
(5)第三方生态链:Native modules + js modules = React Native modules

2、性能 & 体验

(1)内存:Native最少;因为React Native含有框架,所以相对较高,但是后期平稳后会优于Native。
(2)CPU:React Native居中。
(3)动画:React Native动画需求基本满足。
(4)安装包体积:React Native框架打包后,811KB。相比热更新,可以忽略和考虑资源规划。
(5)Big ListView
(6)真机体验:Native >= React Native > H5/Hybrid

3、更新 & 维护

(1)更新能力: H5/Hybird > React Native > Native
(2)维护成本: H5/Hybird <= React Native < Native

React Native定制难度相比Native有些大;但是具备跨平台能力和热更新能力。

说了这么多,最后个人建议:

一个新的App完全可以采用React Native开发,这样成本会低很多。

关于演讲:

PPT: http://www.oschina.net/doc/24007

视频:http://www.oschina.net/question/865233_2145334 (这个演讲在移动专场下半场开场)

六、图书 & 工作机会

最后说一下图书《React Native入门与实战》吧。这是一本[难产]的家伙,15年写的比较顺利,最后因为北京雾霾,印刷厂偶尔停工,一直在难产。前段时间,图书发往各地书店,到店比较迟,我猜测是因为雾霾,找不到高速出口~~目前该书由人民邮电出版社图灵原创出版,已经开卖了。本书主要是希望带领大家一起进入React Native开发领域,针对每个API和组件都有详细的案例,同时为了更好的实战,最后3章以实际案例(通讯录App,LBS App,基于豆瓣OpenAPI的搜索 App)给出,供大家参考。觉得入门是完全没问题的,后期大家可以一起交流,争取丰富国内React Native社区。

《React Native入门与实战》各网站购买地址:

京东:http://item.jd.com/10089810271.html (目前应该都有货了,微信有同学传照片给我看了,铁粉哈)

http://item.jd.com/11844102.html (京东自营,货源需要跟客服确认哦)

互动:http://product.china-pub.com/4904552 (已经有货)

天猫:https://detail.tmall.com/item.htm?spm=a220m.1000858.1000725.21.rc0yeu&id=525484671101&cat_id=2&rn=4690ef5b4e06412ffae4d1cc4f4dcc9a&user_id=1020536390&is_b=1 (天猫这家卖的还可以,不知道为啥京东看不到数据,京东应该才是技术买书的最爱啊,听说也预售了不少呢)

前端性能优化方案索引

陆续整理和不断更新网络上给出的前端性能的优化方案。

这里只是做一个总概括式的索引,每一个方案都十分值得推敲和细说。

1 请求和响应

缓存控制

请求头里,可以发送 If-Modified-Since 以及 If-None-Match 等信息,来询问服务端请求内容是否有更新,如果没有更新,可返回304,告诉浏览器使用缓存,避免重新下载资源。Pragma 和 Cache-Control 等也能控制缓存。如告诉服务端不要缓存等。

响应头里,Expires 可以告诉浏览器过期时间,Last-Modified 最近更新时间,ETag 则可允许浏览器进行缓存验证(在 If-None-Match 请求信息中使用)。

复用TCP

请求头里,Connection 可控制 TCP 通道的使用,使用 keep-alive 可以复用上次打开的 TCP。

GZIP压缩

如果可以启用 gzip 压缩,将减少响应数据大小,加快响应。请求头里面可用 Accept-Encoding 告知浏览器支持的压缩方式,而服务端则用 Content-Encoding 作为回应。

Cookies

发送请求时,cookies 也在请求之中。因此,cookies 也可以作为减少请求的优化对象。如,根据同源限制策略,可以使用多个域名加载资源,如加载静态资源,就不会发送多余的 cookies;同时,合理设置 cookies 的路径和域名,如在子站避免不必要的来自父站的 cookies。

减少HTTP请求

有很多细节可以实现,比如CSS Sprites、Data URL等等,由于此部分内容和下述内容有所重复,故部分细节在下面会讲到。

多域名分发

同域下浏览器能并发的请求有限,而为了增加并发,尤其是一些静态资源上,可以使用多个域名。但由于域名DNS解析本身也是耗时的,所以实践原则是2-4个为宜。

需要额外提醒的是,加载图像资源的时候,并发没有问题;但在加载 JavaScript 脚本的时候,还是会暂停加载其他资源。

使用CDN

根据用户能访问的最快位置加速访问。

避免重定向和404

重定向和404将浪费加载请求。

favicon.ico

浏览器默认加载的资源,最好能够缓存之。

2 HTML

减少DOM

过多的DOM元素会影响渲染、加载、执行。除了精简页面结构外,还可以适时删除不必要的DOM元素(页面内已经不会再访问的元素),又或者可以懒加载(不一定会使用到的元素,如登录框)。

CSS 和 JavaScript 文件位置

CSS 放 head,JavaScript 放 body 闭标签前。乃是因为:

  • 样式表不参与 DOM 修改,所以不会为了解析样式停止文档解析
  • 浏览器要避免重绘,在没有拿到全部样式前不会开始渲染
  • 解析样式时,有的浏览器(FF)会停止脚本运行,而有的(Webkit)则会在脚本访问样式属性但可能受未加载样式影响时停止脚本运行
  • 脚本解析中可能请求样式,如果样式还未解析完毕就会出错
  • 脚本执行将暂停文档的解析和资源的下载

因此,将二者放在适当的位置,能够极大提高渲染效率。

脚本延迟加载

可将脚本添加 defer 和 async 属性。两个属性的共通点在于,脚本的加载和文档的解析是同步进行的,而区别在于:async 一旦加载完毕,立即停止文档解析并执行脚本;defer 等待文档解析完毕后再执行。

合理使用内联

脚本和样式,应按需选择内联或者外链。对于访问少、样式和脚本复用少的页面,可以考虑使用内联样式从而减少 HTTP 请求。但如果页面访问频繁,样式脚本在多个页面经常复用,使用外链则是最优选择。

无论如何,需要避免使用 @import 来导入样式。

而图像也是一样,高级浏览器支持将图像数据直接 base64 编码在 src 属性里,必要时可直接在 HTML 里输出图片数据。

减少iframe

iframe 本身有许多优点,比如可以并行下载脚本,适合加载慢内容(如广告),同时浏览器可以对其进行安全控制。

减少使用 iframe 的主要考虑是:iframe 会阻碍页面加载,同时也没有语义。

3 CSS

选择器

选择器效率排行如下:

  1. ID选择器
  2. 类选择器
  3. 标签选择器
  4. 相邻选择器
  5. 子选择器
  6. 后代选择器
  7. 通配符选择器
  8. 属性选择器
  9. 伪类选择器

效率与优先级并不是对等关系,优先级高的不一定效率高。如 #id.class 合用比 单个 #id 的优先级高,但效率却比值慢。

选择器书写建议是:

  1. 避免使用通配符
  2. 不使用标签名或类名修饰ID规则:如果规则使用ID选择器作为关键选择器,不要给规则添加标签名。因为ID本身就是唯一的,添加标签名会不必要地降低匹配效率
  3. 不使用标签名修饰类:相较于标签,类更具独特性
  4. 尽量选择最具体的方式:造成低效的最简单粗暴的原因就是在标签上使用太多规则。给元素添加类可以更快细分到类方式,可以减少规则去匹配标签的时间
  5. 关于后代选择器和子选择器:避免使用后代选择器,非要用的话建议用子选择器代替,但子选择器也要慎用,标签规则永远不要包含子选择器
  6. 利用可继承性:没必要在一般内容上声明样式

避免滤镜、表达式、Hack

效率低。

Sprites

合并图片可减少 HTTP 请求。其他建议有:

  1. Sprite 中水平排列图片,垂直排列会增加文件大小
  2. Sprite 中把颜色较近的组合在一起可以降低颜色数,理想状况是低于256色以便适用PNG8格式
  3. 不要在Spirite的图像中间留有较大空隙。这虽然不大会增加文件大小,但对于用户代理来说它需要更少的内存来把图片解压为像素地图。100×100的图片为1万像素,1000×1000就是100万像素

使用3D动画

使用 transform: translate3d 等可加速 GPU 渲染。

4 JavaScript

避免重排

渲染中可能存在的高成本操作:

  1. 修改、增加、删除DOM节点
  2. 移动DOM位置或者动画效果
  3. CSS样式修改(重绘比重排好些)
  4. 调整窗口大小,或者滚动时有绝对定位、fixed 背景以及动画
  5. 修改页面默认字体

浏览器一般会缓存Render Tree的更新渲染,但以下情况除外:

  1. 调整窗口大小和修改页面默认字体
  2. client/offset/scroll
  3. getComputedStyle() currentStyle

优化建议:

  1. 修改 className 而非 style
  2. 离线 DOM 后修改,如 documentFragment 或者 display:none 后再调整样式
  3. 缓存属性值
  4. 动画使用 absolute/fixed
  5. 不使用 table 布局(牵一发动全身)
  6. 修改层级比较低的 DOM

事件委托

将多个节点上的事件放到其父节点(经典案例:将 li 上的事件绑定到 ul 上)。

内存管理

合理释放和缓存内存。如缓存复用的属性,接触对象引用等。

5 资源

压缩大小

压缩样式、脚本、图像等资源的大小。

针对图像资源,可从预览小图、格式选择等多角度优化。

懒加载

如图像的懒加载(滚动到显示区域后才加载)等。

预加载

针对之后会用到的资源提前加载。

5 客户端

localStorage 缓存

相比 cookies,localStorage 存储容量更大。可以将一些静态资源(如 jQuery库)等缓存。