基于大数据的用户行为预测在前端性能优化上的应用

首先,我得说,这篇文章有点标题党了,其实内容并没有标题看起来那么高大上。其次,本文只是做一个技术方案可能性的探讨,并没有提供完善的解决方案,至多给了一个Demo供参考。

目的

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

前端性能优化,我觉得最主要的目的就两个:1、提升页面加载速度;2、节约服务器资源。

这里特别提一下节约服务器资源,很多人在做前端性能优化的时候,往往只考虑前端性能的问题,而完全忽视前端的性能优化对后端服务器性能的影响。其实,对于一个网络流量比较大的站点来说,节约服务器资源就是省钱啊。比如,js文件、图片文件的大小越小,服务器所需的磁盘IO贷款和网络IO贷款也就越小,自然就可相应省下部分开支了。

现有的方法

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

前端性能优化,我们目前主流的技术方案主要也就两个:1、合并;2、压缩;3、缓存。

举个例子,一个网站有A,B,C,D四个页面,分别需要引用a\b, a\b\c, a\b\c\d, a\d这几个js文件。于是我们考虑到a这个js文件在四个页面中均有引用,所以不参与合并。然后把b\c两个js文件合并成x,把b\c\d三个js文件合并为y。现在A,B,C,D四个页面对js文件的引用规则变成了分别引用a\b, a\x, a\y, a\d这几个js文件。接下来,我们将a\b\x\y\d这五个js文件分别混淆压缩。

通过以上一系列的处理,现在用户通过浏览器访问我们的站点的时候,在A\B\C\D四个页面都只需要发起两个对js文件的请求。同时,四个页面还可以共享对a这个js文件的缓存。

现有的问题

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

上述的这个性能优化方案,我想很多人一眼就可以看出来,其实还存在很多问题。

1、首次加载页面时,缓存策略无法发挥作用,拖慢了页面加载速度。

虽然我们配置了缓存策略,使得用户访问过B页面一次之后再访问B页面是可以从浏览器缓存中直接加载其依赖的a\x两个js文件的。但是,如果用户只访问过A页面而没有访问过B页面,此时再访问B页面的话,只有a的缓存能够生效,而x是没有缓存的。

2、b\x\y\d这四个js文件的内容存在冗余,浪费了服务器资源。

x包含了b\c两个js文件的内容,但当用户使用浏览器请求了x之后再请求b,任然需要重新下载整个b文件,这里对x的缓存是无法使用在b上面的。

从这两个问题来看,似乎我们还有进步的空间!

新方法

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

针对上面的问题,我们一个个来解决。

首先是首次加载页面时缓存策略无法发挥作用的问题。其实这个问题也是本文的核心,我的解决方案是预加载。也就是说,当用户还没有访问B这个页面的时候,我们就预先让用户的浏览器加载B页面所依赖的x这个js文件。

我设计了一个前端资源预加载系统,包括前端js代码、后端预加载策略逻辑,还有用于计算加载策略的数据库。还是用上面的那个例子。假设A页面是网站的首页,当用户访问A页面后,前端js将用户的SessionID和当前页面的URL发送到后端,并由后端逻辑将这条访问行为记录到数据库的visit_sequence表,然后收集前端资源形成资源列表,包括页面中引用的link、script等,并计算此资源列表的MD5发往后端进行比对。后端逻辑根据页面URL在page_resource_signature表中查找相应的MD5值,如果没有找到,就要求前端js代码发送整个资源列表以及页面URL和资源列表的MD5值并记录到page_resource_signature和page_resource表中;如果根据页面URL找到记录但MD5值不匹配,则要求前端js代码发送整个资源列表以及页面URL和资源列表的MD5值并并更新page_resource_signature和page_resource两个表中的数据;如果根据页面URL找到记录且MD5值也匹配,则后端程序根据数据库中visit_sequence表和page_resource表的记录,计算出用户在当前页面下访问系统中其他页面资源的可能性,并返回给前端代码逻辑,接下来,前端代码预加载后端返回的预加载资源列表中的资源。

前端代码:

/*
desc: performancecollector依赖于jquery及md5.js,用于收集用户在系统中各个页面间跳转的路径,以及每个页面所引用的静态资源列表
*/

if(typeof performance !== ‘undefined‘ && typeof performance.timing !== ‘undefined‘){
    $(document).ready(function(){
        //统计页面ready时间,并将用户的SessionID和当前页面的URL发送到后端
        $.post(‘http://127.0.0.2/index.php/Home/VisitSequence/Insert/‘, {
            SessionID: document.cookie.substr(document.cookie.indexOf(‘PHPSESSID=‘) + 10, 26),
            PageUrl: window.location.href.indexOf(‘#‘) < 0 ? window.location.href : window.location.href.substring(0, window.location.href.indexOf(‘#‘)),
            Cost: performance.timing.domContentLoadedEventStart - performance.timing.responseStart
        });
        //收集页面资源信息
        var resources = [];
        $(‘link‘).each(function(){
            resources.push($(this).attr(‘href‘));
        });
        $(‘script[src]‘).each(function(){
            resources.push($(this).attr(‘src‘));
        });

        //计算resource的MD5并发往服务器比对
        setTimeout(function(){
            var resourceSignature = md5(JSON.stringify(resources));

            $.post(‘http://127.0.0.2/index.php/Home/VisitSequence/CompareSignature/‘, {
                Signature: resourceSignature,
                PageUrl: window.location.href.indexOf(‘#‘) < 0 ? window.location.href : window.location.href.substring(0, window.location.href.indexOf(‘#‘))
            }, function(data){
                //如果没找到此页面资源的签名,就安排延时上传页面资源签名及资源列表
                if(data.find === 0){
                    $.post(‘http://127.0.0.2/index.php/Home/VisitSequence/UpdateResource/‘, {
                        Signature: resourceSignature,
                        Resources: resources,
                        PageUrl: window.location.href.indexOf(‘#‘) < 0 ? window.location.href : window.location.href.substring(0, window.location.href.indexOf(‘#‘))
                    });
                }else{
                    //安排延时预加载资源
                    loadResource(data.resources);
                }
            });
        }, Math.random() * 1000 + 2000);

        //预加载资源
        function loadResource(resources){
            //在这个方法里面加载resources参数中列出的资源
            console.log(‘loadResource‘, resources);
        }
    });
}

数据库表结构:

序列图:

上述这个流程中,最关键的步骤就是“计算各个页面资源被访问的可能性”这一步了,也就是序列图中标红的部分。这个动作可以通过用程序分析用户以往的浏览记录来实现。比如我们常见的Piwik系统中,就直接提供了每个页面的上下游关系:

如上图,我们可以通过Piwik的接口清晰的看到,访问index.php这个页面之后,有37%的用户接下来会访问xxxx/xx=attendance&menuid=19这个页面,还有20%的用户接下来会访问xxxx/xx=ast&a=index&menuid=30这个页面。加入这两个页面都引用了sharelib.js这个文件,那么用户访问index.php这个页面后,需要访问sharelib.js这个资源的可能性就高达57%,那么我们是不是就可以让index.php的前端代码预先加载sharelib.js这个资源呢?这样当用户真的发生页面跳转去浏览别的页面的时候,很可能跳转后的页面所需的前端资源我们已经预先加载过了,浏览器可以直接从缓存中读取相应的数据,从而实现加快页面加载速度的效果!

由此,通过详细记录用户浏览站点的行为,并分析每个页面的资源引用情况,我们就可以实在在用户访问某个页面之前就预先判断出那先资源是值得预先加载的。从而实现资源预加载的效果。

我们再来看第二个问题,也就是资源合并导致的内容冗余问题。

其实,当我们解决第一个问题的时候,第二个问题也就不复存在了。因为我们可以在用户进入页面之前就预先加载页面的资源,所以前端资源的合并也就没有存在的必要了,也就不存在因资源整合导致的内容冗余问题了。

新问题

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

这个新的方案虽然解决了我们的一些问题,但也并非完美无缺。

1、团队协作更复杂

以往的前端性能优化方案中,我们往往只需要一组前端开发人员参与就行了,可是现在的这个方案,由于需要后端提供用户行为预测的数据,所以很可能需要后端开发的同学也参与进来。如果站点的用户数据收集是专门的团队进行的,那么很可能还需要这个专门的团队参与整个方案的设计和实施。这无疑大大增加了团队协作的复杂度,对项目管理水平的要求进一步提高。

2、对站点首页没有任何效果

基于用户行为预测的优化方案,只有在用户进入站点之后才能生效,如果用户根本就没有进入站点,我们就什么都做不了了,所以,网站的首页在这种优化方案中完全得不到任何好处。而网站的首页往往又是整个站点中受访量最大的几个页面之一,所以这个问题带来的影响还是比较大的。

3、需要权衡数据实时性和性能

服务端在返回给前端用户接下来可能需要访问的资源的时候,是实时地通过数据库中的数据计算出各个资源被访问的概率,还是我们通过某种机制事先计算好然后直接读取返回给前端?如果是实时计算,可能概率的准确性会更高,但是用户访问的历史数据太多的话,这个实时计算是否会消耗过多的系统资源又是个大问题,而如果我们事先计算好这些数据,当站点页面更新的时候,若这些计算的概率数据没有更新,则用户在访问我们的站点的时候,就无法享受到预加载带来的好处,而且会因为我们放弃了传统优化方式而获得更糟的用户体验,那么这些概率数据什么时候才能得到更新又是个问题。

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

此文完全源于本人的一个脑洞,就是忽然灵光一现,想到了这个性能优化的方案。我在网络上尝试搜索相关的关键字,但是并没有找到很好的资料,所以我想,难道这还是我首创的?如果真是,那肯定还有很多没有考虑到的细节和不足,写出来供大家参考。如果不是,那还请各位过来人不灵赐教分享你的实践经验!

如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html

时间: 2024-10-02 19:06:19

基于大数据的用户行为预测在前端性能优化上的应用的相关文章

基于大数据的用户行为预测

随着智能手机的普及和APP形态的愈发丰富,移动设备的应用安装量急剧上升.用户在每天使用这些APP的过程中,也会产生大量的线上和线下行为数据.这些数据反映了用户的兴趣与需求,如果能够被深入挖掘并且合理利用,可以指导用户的运营.若能提前预测用户下一步的行为,甚至提前得知用户卸载.流失的可能性,则能更好地指导产品的优化以及用户的精细化运营. 大数据服务商个推旗下的应用统计产品"个数",可以从用户属性.使用行为.行业对比等多指标多维度对APP进行全面统计分析.除了基础统计.渠道统计.埋点统计等

新产品为了效果,做的比较炫,用了很多的图片和JS,所以前端的性能是很大的问题,分篇记录前端性能优化的一些小经验。

第一篇:HTTP服务器 因tomcat处理静态资源的速度比较慢,所以首先想到的就是把所有静态资源(JS,CSS,image,swf) 提到单独的服务器,用更加快速的HTTP服务器,这里选择了nginx了,nginx相比apache,更加轻量级, 配置更加简单,而且nginx不仅仅是高性能的HTTP服务器,还是高性能的反向代理服务器. 目前很多大型网站都使用了nginx,新浪.网易.QQ等都使用了nginx,说明nginx的稳定性和性能还是非常不错的. 1. nginx 安装(linux) htt

蔡先生论道大数据之十三:预测企业未来

每次技术变革企业包括个人都需要做出适应,现在我们处于新一轮实际革命的时代节点上,从小数据时代到大数据时代的前叶. 那么企业面对大数据需要做出什么样的变革呢? 又存在什么样的挑战呢? 首先, 决策方式的改变,传统运作管理在变成大数据管理,越来越多的传统决策在变成基于数据分析的决策.其次,企业不仅要关心内部信息整合,比如CRM\ERP 还要关心外部数据比如用户评论\口碑\商誉\留言等,现在出现的新的趋势就是通过内部和外部的数据整合来决定企业的管理决策.最后,过去企业关心能够创造什么价值,是生产电视机

H2O是开源基于大数据的机器学习库包

H2O是开源基于大数据的机器学习库包 H2O能够让Hadoop做数学,H2O是基于大数据的 统计分析 机器学习和数学库包,让用户基于核心的数学积木搭建应用块代码,采取类似R语言 Excel或JSON等熟悉接口,使的BigData爱好者和专家可以利用一系列简单的先进算法对数据集进行探索,建模和评估.数据收集是很容易,但是决 策是很难的. H2O使得能用更快更好的预测模型源实现快速和方便地数据的挖掘. H2O愿意将在线评分和建模融合在一个单一平台上. H2O提供了机器学习的培训手册供学习:H2O训练

基于大数据技术之电视收视率企业项目实战(hadoop+Spark)张长志(项目实战)

38套大数据,云计算,架构,数据分析师,Hadoop,Spark,Storm,Kafka,人工智能,机器学习,深度学习,项目实战视频教程 视频课程包含: 38套大数据和人工智能精品高级课包含:大数据,云计算,架构,数据挖掘实战,实时推荐系统实战,电视收视率项目实战,实时流统计项目实战,离线电商分析项目实战,Spark大型项目实战用户分析,智能客户系统项目实战,Linux基础,Hadoop,Spark,Storm,Docker,Mapreduce,Kafka,Flume,OpenStack,Hiv

基于大数据技术推荐系统算法案例实战视频教程(项目实战)

38套大数据,云计算,架构,数据分析师,Hadoop,Spark,Storm,Kafka,人工智能,机器学习,深度学习,项目实战视频教程 视频课程包含: 38套大数据和人工智能精品高级课包含:大数据,云计算,架构,数据挖掘实战,实时推荐系统实战,电视收视率项目实战,实时流统计项目实战,离线电商分析项目实战,Spark大型项目实战用户分析,智能客户系统项目实战,Linux基础,Hadoop,Spark,Storm,Docker,Mapreduce,Kafka,Flume,OpenStack,Hiv

新的学习路径、学习想法和思路的头脑风暴:基于泰迪云课程,对数据分析和数据建模,机器学习算法进行统筹,接着是基于大数据的数据挖掘、进度、

新的学习路径.学习想法和思路的头脑风暴:基于泰迪云课程,对数据分析和数据建模,机器学习算法进行统筹,接着是基于大数据的数据挖掘.进度. 泰迪云代码已经下载,对相关内容进行应用和学习 想通视频之后对代码进行研究 专家经验.优秀经验工程师经验转化. 从论文中第三四大章,读取 设计和解决问题流程 找论文.使用benchmark 上有收录论文.找到论文.不建议自己先去想. 以后一定 偏分析,偏挖掘.偏决策的.不是执行者,执行者是最low的,最强的解决方案,都按论文来找. 高端会议.每年会出来十多篇研究成

[转载]前端数据之美 -- 七天打造前端性能监控系统

开始行动 本文中的性能主要指 web 页面加载性能,对性能还不了解?不用担心,接下来的“每一天”跟我一起进入前端性能的世界. Day 1 为什么要监控性能? “If you cannot measure it, you cannot improve it” ———— William Thomson 这是一个最基本的问题,为什么要关注和监控前端性能?对于公司来说,性能在一定程度上与利益直接相关.国外有很多这方面的调研数据: 性能 收益 Google 延迟 400ms 搜索量下降 0.59% Bin

基于GruntJS的前端性能优化

本文主要如何使用GruntJS来作简单的前端性能优化的自动化处理,我写了一个完整的例子放在Github上,可以参考一下.关于Yahoo的前端优化规则请参考:Best Practices for Speeding Up Your Web Site 前端性能主要有图片的压缩,JS和CSS的合并.压缩,对所有静态文件的文件根据其内容加上hash,然后把CSS.HTML等文件中对所有的静态文件名替换成加上hash的新文件名.对所有的静态内容的路径上加上CDN的URL,最后将所有的静态文件上传到七牛CDN