浏览器（1）
在国内有一个比较特别的现象，很多网站对浏览器的兼容性比较差，特别是一些网上银行、公共服务网站等，虽然现在IE浏览器已经推出了版本，但是这些网站目前只支持及以下版本。所以目前在国内使用IE6\IE7\IE8等旧版浏览器的用户占比还比较多。另一外方便，有些比较现代的网站，采用了很多HTML5、CSS3等最新的网络标准，IE8这些老旧的浏览器是无法支持的，而其他非IE浏览器对这些标准支持程度都比较高。为了应对这样的情况，所以国内很多互联网公司推出了“双核”浏览器。
“双核”浏览器内部的两个内核分别是IE内核和WebKit内核。
“双核”浏览器的两个内核并不能同时为一个网页进行渲染排版工作，而是根据我们的需要，选择两者之中更适合当前网页的内核来进行渲染排版。IE内核主要用于兼容“老一辈”的网页，使其能够正常显示；WebKit内核则用于渲染“新一代”的网页，从而发挥出更快的显示速度、更好的显示效果、更优异的脚本执行性能。
在head标签中添加一行代码：
&meta name=&renderer& content=&webkit|ie-comp|ie-stand&&
content的取值为webkit,ie-comp,ie-stand之一，区分大小写，分别代表用webkit内核，IE兼容内核，IE标准内核。
若页面需默认用极速核，增加标签：&meta name=&renderer& content=&webkit&&
若页面需默认用ie兼容内核，增加标签：&meta name=&renderer& content=&ie-comp&&
若页面需默认用ie标准内核，增加标签：&meta name=&renderer& content=&ie-stand&&
同时也可以同时指定多个内核名称，之间以符号”|”进行分隔：&meta name=&renderer& content=&webkit|ie-comp|ie-stand&&
此时浏览器将会按照从左到右的先后顺序选择其具备的渲染内核来处理当前网页。
IE8引入新的概念“文档模式”：要强制浏览器以某种模式渲染页面，可以使用
&meta http-equiv=&X-UA-Compatible& content=&IE=IEVersion&&
IE的版本（IEVersion）有以下一些不同的值：
Edge：始终以最新的文档模式来渲染页面。忽略文档类型声明。
EmulateIE9：如果有文档类型声明，则以IE9标准模式渲染页面，否则将文档模式设置为IE5。
EmulateIE8：如果有文档类型声明，则以IE9标准模式渲染页面，否则将文档模式设置为IE5。
EmulateIE7：如果有文档类型声明，则以IE9标准模式渲染页面，否则将文档模式设置为IE5。
9：强制以IE9标准模式渲染页面，忽略文档类型声明。
8：强制以IE8标准模式渲染页面，忽略文档类型声明。
7：强制以IE7标准模式渲染页面，忽略文档类型声明。
5：强制将标准模式设置为IE5，忽略文档类型声明。
这样写可以达到的效果是如果安装了GCF，则使用chrome内核来渲染页面，如果为安装GCF，则使用最高版本的IE内核进行渲染。
通过document.documentMode属性可以知道页面使用的是什么文档模式。
&&meta&http-equiv&=&&X-UA-Compatible&&content&=&&IE=edge,chrome=1&&/&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：44377次
排名：千里之外
原创：41篇
转载：31篇
(3)(2)(2)(2)(5)(2)(2)(3)(8)(8)(2)(3)(5)(4)(2)(5)(3)(6)(3)(3)javascript 外联文件引用放在 html 文档底部
css 外联文件引用在 html 文档头部
http 静态资源尽量用多个子域名：充分利用现代浏览器的多线程并发下载能力。浏览器的多线程下载能力
服务器端提供 html 文档和 http 静态资源时，尽量开启 gzip 压缩
尽量减少 HTTP Requests 的数量
js/css 的 minify
大量使用 CSS Sprites：这样做可以大大地减少CSS背景图片的HTTP请求次数；
首屏不需要展示的较大尺寸图片，请使用 LazyLoad
避免404错误：请求一个外联 js 失败时获得的404错误，不但会堵塞并行的下载，而且浏览器会尝试分析404响应的内容，来辨识它是否是有用的Javascript代码；
减少 cookies 的大小：尽量减少 cookies 的体积对减少用户获得响应的时间十分重要；
去除不必要的 cookie ；
尽量减少 cookie 的大小；
留心将 cookie 设置在适当的域名下，避免影响到其他网站；
设置适当的过期时间。一个较早的过期时间或者不设置过期时间会更快地删除 cookie，从而减少响应时间。
避免使用 javascript 来定位布局
图片压缩优化
不要使用frameset，少使用iframe: 搜索引擎不友好、 即使内容为空，加载也需要时间、会阻止页面加载。禁止使用iframe引入外部资源，不包括allyes广告，不包括about:blank的空页面。
中高级优化
combo handler 的引入：
通过combo handler模块，来合并相同URL下的Javascript和CSS文件，从而减少文件请求数
我们移动端首页就做了优化
??module/iscroll-lite/5.1.3/iscroll-lite.js,module/alertBox/2.0.0/alertBox.js,module/swipe/1.1.0/swipe.js
引入script元素做延迟解析异步渲染，如在移动端应用广泛的artemplate
添加Expire或Cache-Control:应用于不经常变化的组件，包括脚本、样式表、Flash组件、图片
避免重定向：在重定向完毕并且HTML下载完毕之前，是没有任何东西显示给用户的
js代码优化
代码逻辑分层
避免全局变量
便于多人协作开发
各部分代码模块化，可以按需加载
保持全局变量的清洁
可进行单元测试
减少 DOM Elements 的数量：针对一个展现元素，尽量减少其包含的DOM结点
移动端页面优化
移动页面的速度跟三个因素有关，分别是：移动网络带宽速度，设备性能（CPU，GPU，浏览器），页面本身。
因此移动页面优化尤其特殊性。除了以上的处理方式，还有一些优化手段
参考天猫首页，在页面加载完毕之前，有一个缓冲的动画过程。它一方面能增加页面的趣味性，另一方面能让后续页面体验更流畅
隐性加载 ：主要是图片的懒加载
能用css3实现的效果就不要用图片
使用icon-font代替图片
尽量避免DataURI
DataURI要比简单的外链资源慢6倍，生成的代码文件相对图片文件体积没有减少反而增大，而且浏览器在对这种base64解码过程中需要消耗内存和cpu，这个在移动端坏处特别明显。
点击事件优化
在移动端请适当使用touchstart，touchend，touch等事件代替延迟比较大的click事件。
使用成熟的前端手势库
尽量使用css3动画
适当使用canvas动画
合理使用requestAnimationFrame (android版本4.3以上)
高频事件优化
类似touchmove，scroll这类的事件可导致多次渲染，对于这种事件可以通过以下手段进行优化：
使用requestAnimationFrame监听帧变化，使得在正确的时间进行渲染
增加响应变化的时间间隔，减少重绘次数：移动端的搜索结果页的lazyload插件就是这么干的
ps:内部转正，要求开放性简答三个问题
题目一： css权重是什么？
题目二：js的基本数据类型有哪些？
题目三：页面优化的方式有哪些？
阅读(...) 评论()6058人阅读
学习（12）
模版存放于后端
php输出页面html结构进行页面渲染
ajax请求，需要重渲结构时，php输出html结构
builder制作静态页面结构
jser完成页面交互逻辑开发
模版数据无法存储本地，导致每次打开页面请求数据量巨大
数据每次要从接入层web服务器读取，没有合理利用CDN加速静态模版内容
联调成本较大，不利于前端控制页面展示和交互开发
3 解决方案
后端直接输出json数据
试图把渲染页面的模版存放在前端
4 技术路线
5 理论意义
利用CDN保存html模版，看起来第一次请求会使用多一点的资源，实际上消耗并不是很大，且多次请求可以减小下载量
充分利用缓存，提高性能
联调成本大大降低，后端只需要按规则输出Json数据，前端能更大程度的控制页面展示，减小bug量
二 基于模版与数据分离渲染方式的方案设计
1 ejs模版简介
& & & & 官方API地址：
& & & & 官方API介绍的很清楚，也是大多数模版的常用办法。下面列举几个特殊用法：
可自定义函数
& & & & &支持常用html标签的快捷方式，就像ruby on rails framework的做法一样，让代码更简洁。
支持模版错误提示
另外，ejs支持nodejs
2&pageletView渲染组件简介
pageletView按照页面的模块分别输出模块id，css，js，html
3 ejs与pageletView的融合方案设计
& & & & pageView在渲染页面的时候，是分模块进行渲染的。这种方式是实现bigpipe的重要渲染方式，那么需要我们在不改变原有pageview的基础上进行改造。
即在原有的技术上，多传给STK.pageletM.view方法参数的两个属性，一个属性命名为data，用来存放json数据传递给前端使用，另一个属性命名为template，用来存放模块的模版文件。
然而，由于页面上有多少个模块，就会有多少个template文件，在实现完成这种渲染之后，发现如果一个页面上的模块比较多的话，就会给页面渲染带来一定的负担，所以决定把一个页面的模版合并成一个模版文件，这样只需要请求一次模版文件就可以了。设计如下：
三 基于模版与数据分离渲染方式的实现
1模版的传递办法
& & & & ejs拿到模版和数据后，执行渲染。数据可以在pageLet拿到数据的时候，通过参数传递，而每个模块的渲染，需要动态的传递模块template，不可能直接$Import写死到ejs文件，也不可能$Import写死到pageletView文件里。这个问题有两种办法解决。
把模版设置成全局变量
使用listener广播事件监听
显然，第一种把模版设置成全局变量的办法有很大风险，容易造成混淆和错乱，切不利于维护。于是我们选择第二种办法，listener事件广播的形式。因为第二种办法，在需要使用到模版的地方，我们通过架设管道的方式，一对一的监听模版发出的广播，从ejs模版里进行接收，这样就避免了抛到全局造成的问题。
2 实现无等待的模版渲染
& & & & 然而，在使用listener事件的时候又遇到了问题。
& & & & 因为熟悉listener事件的同学都知道，事件fire与事件register是有先后顺序的，register在前，fire在后，也就是说在ejs需要使用模版的时候，我们会使用listener的register方法绑定事件，然后才可以把模版fire出来，那么我们很容易想到把合并完的模版文件a.js放在pageletView渲染模块之后，但是放在后面我们是无法监听到对应模块的pageletView已经register完成的，这时候如果使用setTimeout的方式虽然能够解决问题但是存在着很大的弊端，因为第一，setTimeout需要耗费性能，渲染出页面的体验非常差，第二，我们做了个测试，如果setTimeout的时间参数小于1000ms的话，成功渲染所有模块只能成为偶发的事情。
& & & & 怎么解决这个问题呢，我们最后想到了一个办法，使用两个广播进行解决。
& & & & 首先，我们把模版合并好的a.js文件放在pageletM（pageletM会调用pageletView方法）渲染之前，register一个广播，广播的名字叫做id+’_temp’,在这个广播里我们去把模版fire出去，fire的参数为id。
& & & & 其次，我们在ejs文件里register一个事件，这个参数为模块的id（即pid），然后fire一个事件，fire的参数为id+’_temp’
& & & & 整个传递的步骤为：
& & & & 首先ejs文件监听模版文件，然后模版文件fire出模版，整个目的就达到了。
& & & & 这个过程描述如图：
& & & & 说明：首先页面加载模版文件，模版文件监听pageletView文件reday的listener事件，回调函数fire出“模版”，然后页面运行pageletView文件，pageletView文件注册了模版文件ready的事件，然后再pageView文件里发出模版pagelet已经ready的信号。这样在pageletView执行的时候，模版告诉pageletView模版已经ready，监听过模板ready的回调函数就可以收到模版从而完成模板与数据拼接了。这样就实现了无等待的数据加模版渲染。
3 pageletView中的向下兼容
& & & & &由于微博现如今使用的方式是模版放在后端进行，前端取到后端传出的html，然后进行渲染，若使用template+data的方式进行页面渲染，我们可以做一下向下兼容。如下图，判断若data != undefined则通过template+data进行渲染，否则使用原有的方式进行渲染。
4 实现trans请求的模版渲染
& & & & 大家知道，前端对后端ajax请求成功的时候，若前端需要改变某个节点的innerHTML，后端会返回一段html代码，而当我们点击feed分页的时候，可能会浪费大量的模版流量，如果把模版存在前端，后端只需要提供每个feed需要的数据就可以了，这个可以节省很多资源。
& & & & 实现这种方式很简单，只需要按照pageletView中的使用方式就可以了，但是这样的话会存在一个问题。前端拿到模版和数据拼接好html结构后，需要知道怎么去处理这段html，所以我们把insertHTML集成在ejs中，通过传递参数的形式，去让ejs执行innerHTML或者是insertHTML（如下图）。
&5 实现ejs文件的简单使用
& & & & 每次使用可能我们都需要注册一个事件，并在这个事件内抛出另一个事件，使用起来非常不方便。经过分析与设计，我们决定把模版中的注册事件和fire事件封装起来，调用的过程中只需要传递几个参数就可以实现效果。如下图：
& & & & 模版文件引用sedEjsTemplate.js，业务文件引用$.kit.dom.ejs文件（pageletView对$.kit.ejs的引用是一种特例）。
& & & & & & & &
6 template+data使用步骤（非常简单好用）
& & & & 第一步：写模版文件。
& & & & & & & & & &&
& & & & 第二步：使用$.kit.dom.ejs();
& & & & &&
& & & & 参数说明：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：313175次
积分：3306
积分：3306
排名：第8188名
原创：90篇
转载：32篇
评论：25条
(1)(1)(1)(6)(7)(20)(4)(2)(9)(8)(6)(9)(2)(5)(4)(1)(21)(12)(3)页面渲染优化
页面渲染优化目前大概有以下几种方式，它们各有优缺点：
服务端缓存
采用服务端缓存重复渲染的页面是最简单，也最容易想到的方式来提高页面渲染性能，例如淘宝现在的pageCache就是将一些经常用到的模板页面，进过一次渲染后缓存在tair中，然后其他页面有引用到这个页面，或者重复的请求，可以直接从tair中去取，减少这个重复页面的重复渲染。
优点。实现简单，修改和失效容易控制
缺点。只是单纯的减少服务端的响应时间，增加了服务端的内存消耗，就是以空间换时间。没有减少用户的请求量，没有减少用户到主站的数据传输量
将一个大页面拆分成多以模块，将小模块改成异步请求，这种方式是将用户的需求拆分，只加载用户最需要的部分，其他次要的当用户需要的时候再加载，这样做虽然增加了用户请求服务端的次数但是可以同时减少服务端的响应时间，和减少从服务端的数据传输量。例如淘宝的TBSkip系统就是将detail系统部分异步化。
优点。减少服务端的响应时间、减少服务端到用户的数据传输量
缺点。系统的依赖将变得复杂，增加开发维护的难度，页面调试也变得困难，增加了系统的总的请求数，用户体验也会降低。
随着淘宝的CDN的完善，可以考虑将渲染后的页面推送到CDN上，然后用户直接从CDN上去拉静态页面，这里有两种实现方式：一种是根据用户的访问请求来划分页面，例如对同一个店铺，所有用户访问的页面应该都是一样的，那么可以按照店铺属性在CDN上缓存页面，这样只要用户访问的是同一个页面，它们可以直接在CDN上请求静态页面。另外一种是根据页面的修改热点进行划分，尽量将不经常修改的页面渲染后放到CDN上，将变化的部分通过异步请求，到服务端动态获取。这种方式目前淘宝还没有实现的成功案例。
优点。这两种方式的优点非常明显：减少用户的请求数，减少服务端的响应时间，减少服务端到用户的总的数据传输量，也就是将大部分的访问压力从主站转移到了CDN上。
缺点。缺点也很明显：增加了页面失效的难度，当页面被修改了更新会变得困难，这种方式可能会要修改当前的系统架构和后端数据结构的重新划分，重构系统成本较大。
页面JS渲染
JS渲染的想法是避免前面几种方法的缺点，但是又能实现他们的优点，由于现在有了自己的模板渲染引擎，使得我们有更多的选择，可以基于目前的模板，而不需要修改当前的系统结构。目前有这样几种实现。
1. 页面内容动静分离。
实现思路是通过模板引擎将模板中的静态html抽离出来，形成一个单独的JS文件，然后将这个JS文件发送到CDN上，页面的渲染逻辑仍然保持不变，而只是将HTML用一些符号代替，这样在用户浏览器里再将JS中的htm和服务端的动态内容合并形成一个完整的html。
1)优点。能够减少用户请求的总数据量的大小，减少服务端响应时间
2)缺点。增加一次或多次CDN的请求
2. 部分页面CDN化。
这种方式与第一种方式类似，不同点是不是在服务端缓存重复的页面，而是将这些页面渲染成JS发送到CDN上，有前段到CDN上去拉，再组装，这个过程同样是有模板引擎来完成，当页面修改时再重新渲染推送到CDN上。
1）优点。减少请求数据量的大小，减少服务端响应时间
2）缺点。增加一次CDN的请求
3.模板渲染完全用JS实现
这种方式是将后端模板转成vm模板或java代码转成js代码，业务逻辑保持不变，将velocity语法或java语法转成JS语法，将模板渲染需要的vo参数转成JSON传给前段浏览量器来渲染整个页面。目前这种方式也可以实现，通过模板引擎可以将vm转成JS，但是VO参数恐怕要重新设计。
1)优点。减少传输的数据量，减少响应时间。
2)缺点。增加浏览器的压力，可能会影响用户体验（待验证），服务端的VO要重新设计。
4.综合方式
就是综合以上几种方式灵活运用，可以取长补短，目前facebook也是综合利用了这些方式，至于浏览器端会不会影响用户体验，将有待验证。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}