关闭

大型电子商务网站架构之-前端优化

404人阅读 评论(0) 收藏 举报
 

1           前端优化必要性

随着互联网的发展,前端优化越来越被人们重视,在一个大型的大型电子商务网站技术架构中,前端架构一定是一项必不可少的工作,国内几个大型的互联网公司也有非常强大的前端技术人员。在业界享有名气淘宝 UED团队就有好几十人。在浏览器访问一个网站时,有 10%-20% 的时间是花在下载 HTML 上面,有 80%-90% 时间是花在下载页面中所有组件上面。如果我们可以把后端时间缩短一半,整体响应时间只能减少 5%-10% 。然而我们关注前端,同样是其响应时间缩短一半,那整体性能能减少 40%-45% 。

看些研究数据:

l  Amazon 慢 0.1 s -> 1% 用户放弃交易

l  Google 慢 0.4s ->  0.6% 放弃搜索

l  Yahoo! 慢 0.4s ->  减少 5%-9% 的流量

l  Bing 慢 2s ->  收入下降 4.3 %

2           前端优化最佳实践

在前端发展了那么长时间,其优化经验也有很多值得借鉴,下面作简单介绍。

2.1       14 条优化军规

1.         尽可能的减少 HTTP 请求数

2.         使用 CDN

3.         添加 Expires 头 ( 或者 Cache-control)

4.         Gzip 组件

5.         把 CSS 样式放在页面的上方。

6.         将脚本放在底部 ( 包括内联的 )

7.         避免在 CSS 中使用 Expressions

8.         将 javascript 和 css 独立成外部文件

9.         减少 DNS 查询

10.     压缩 JavaScript 和 CSS 文件 ( 包括内联的 )

11.     避免跳转

12.     移除重复的脚本

13.     配置 ETags

14.     缓存 Ajax 请求

以上内容在网上都有介绍,在此不作多说,有兴趣的同学可以 google 一把。

2.2       拆分初始化负载

Ajax 和动态 HTML 的日益普及网页上面的 js 和 css 也变得非常庞大, web 程序也变得像桌面程序一样,很大一部分代码不会在启动时候使用,而是采取插件式架构,允许动态加载模块。

         在一个大型结构复杂的网页上面,为了不影响用户体验,可以把 js 分为两部分,一部分是渲染页面必须的,剩下是一部分。这样也在一定程度上面提高用户体验,给用户第一时间看到完整的页面。再寻找哪些 js 可以被拆分,可以通过一些辅助工具来判断, firebug 就是一个非常好的工具,可以通过查看哪些函数 onload 之前未被使用。通过判断可以把其中一部分拆分出来,但是有些不开始拆分,例如页面的错误处理和业务判断等 js 是不能拆分的,如果要拆分合理必将是一项严谨的工作。

2.3       无阻塞加载脚本

Js 有两种方式被包含在页面中,一种是行内脚本,一种是外部脚本。对外面脚本浏览器在下载 js 或者执行脚本的同时不会下载其他内容,有时候这种情况是必要,但是却会影响页面其他展示,理想情况是不堵塞其他内容下载的方式来加载 js 。目前也有对应的技术,用得比较多的是 XHR Eval , xhr 注入, script ifram , script dom element , script defer document.write script Tag 。具体使用情况要根据环境来定。

由于使用外部脚本,有人可能会想到把全部使用内部脚本,这种做法不可取,这样会增加页面大小,而且浏览器不会缓存 js ,少数内部脚本是可取的。但是大多情况下使用外部脚本,这样无论在团队开发,还是版本控制还会带来很大好处。

2.4       使用现成组件

现成开源的 js 组件很多,可以根据熟悉程度和业务应用性使用, jquery , yui , ext , dojo 。如果自行开发,除非有强大团队,要不维护成本太高,而且功能不完善。

Prototype

惊艳,野性, 代码风格类 Ruby ,新手不易上手,文档缺乏

Jquery

乖巧 灵活 易用

Dojo

强大,复杂,笨重

它的设计初衷就是:不光只运行在浏览器的脚本环境中,甚至像 pdf/rhino 这些也拥有

脚本环境的地方也能使用

Yui

温顺,矫健,文档齐全,编码语法相对传统,封装的形式比较接近于 Java

Ext

Ext:  野生,炫,侵入太强,适用于精英团队

 

2.5       针对 Content 优化

1.         组件延迟加载

不可见的组件 : 非当前的 Tab ,隐藏的图片

附加组件:动画 , 拖动

2.         预加载组件

无条件的预加载 (Google 首页的例子)

有条件的预加载(淘宝首页搜索提示功能的例子)

3.         减少 DOM 元素个数

元素越多,下载的数据越多, JS 操作 DOM 速度越慢

4.         尽量少使用 iframe

l  公共文件的重复加载

l  浏览器的消耗

2.6       图片优化

l  优化图片

尝试使用 PNG , png 拥有 gif 所有功能,还支持 alpha 透明,文件比较小,所以尽可能使用 png 格式图片。

删除图片的元数据,例如 photoshop 的元数据,这样在一定程度上能减少图片大小而不影响图片质量。

l  CSS sprites

可以把网站常用的小图片集合在一张图片中,通过 Css 定位到小图上面,从而减少 http 请求。

l  不要在 HTML 中缩放图片  

<img width="100" height="100" src= “ cat.jpg" />

3           怎么样才算足够快

0.1 秒

用户直接操作 ui 中对象的感觉极限。例如,用户直接选择表格的一列到该列高亮显示,或者反馈被选择的时间间隔。

1 秒

用户随意在计算机指令空间操作而无需过度等等时间的感觉极限。 0.2-1.0 的时间延迟会被用户注意到,会让用感觉到计算机正在对指令进行处理中。等待的时间过长,会让用户失去流畅的体验。

10 秒

用户专注于任务的极限,超过 10 秒的任何操作都要有一个进度指示器,以及有一个让用户中断操作,而且有清晰的标示方法。假设用户超过 10 秒后返回界面,他们将要重新适应。在实际工作中有些操作超过 10 秒是可以接受的,比如撤换操作任务。

换句话说 js 在执行如果超过 0.1 秒,会让人感觉到不平滑。如果超过 1 秒会让人感觉应用程序缓慢;超过10 秒那么用户会非常沮丧。这些就是用于足够快的标准。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:12452次
    • 积分:193
    • 等级:
    • 排名:千里之外
    • 原创:5篇
    • 转载:11篇
    • 译文:0篇
    • 评论:4条
    最新评论