Web 前台优化

大型网站--前端性能优化和规范


2013-10-28 09:00 by 贤达, 2 阅读, 10 评论, 收藏编辑

Web性能涉及的范围太广,但一般web开发者在程序上线以后很多都曾遇到过性能的问题。普遍表现为页面速度开始急剧变慢,正常访问时间变的很长,或则干脆给你抛出异常错误页面。这里会涉及到很多可能发生的情况,举例几个最主要发生的情况:

* 数据库连接超过最大限制,一般表现为程序的连接池满,拒绝了与数据库的连接。

* 数据库死锁

* Web Server 超过最大连接数(一般在虚拟主机上才会限制)

* 内存泄漏

* Http连接数太多,即访问量超过了机器和软件设计正常所能提供的服务

而今天分享的主要是比较偏向前端

浏览器请求和响应的过程

第一步、浏览器预处理

查询Cache:读取Cache 或者发送304请求

第二步、查询DNS


优化规则--减少DNS查找

DNS缓存

浏览器DNS缓存 计算机DNS缓存 服务器DNS缓存(TTL)

使用Keep-Alive特性 
减少DNS查找

当客户端的DNS缓存为空时,DNS查找的数量与Web页面中唯一主机名的数量相等。减少唯一主机名的数量就可以减少DNS查找的数量。

较少的域名来减少DNS查找(2-4个主机)

第三步、建立连接


优化规则-- 使用内容分发网络

美国十大Internet网站和CDN服务提供商

页面静态化,取决于发布系统

Ctrip使用的China-Cache和网宿

优化规则--用域名划分页面内容

按页面内容划分域名,在合适的资源服务器上存放文件

第四步、发送请求


优化规则-- 减少HTTP请求

HTTP请求30-40,合并文件,图片地图,内联图像

a)js文件(不超过7个)

1.tuna_090501_base.js和tuna_090501_module.js(拆分tuna_090501.js)

2.数据文件js(1-2个)

3.频道公用js(1个)和页面私有js(1-2个)

不含ga.js、uiscript.asp和外链其他网站的js

b) css文件不超过4个,各频道首页和全站首页不超过3个。

c) 目前无法解决的是allyes广告的请求数。

?

? 大量的广告和产品图片可能会造成,图片请求数很大,可能造成总请求数指标吃紧,

这个只能从设计上搞定,需要权衡

? 目前老页面可能css和js文件请求数可能会超标

优化规则- – 优化CSS Spirite


图片地图   Ctrip首页例子

优化规则– 避免404错误

避免内部无效的链接

规则优化 –不要使用frameset,少使用iframe

搜索引擎不友好、

即时内容为空,加载也需要时间、会阻止页面加载

禁止使用iframe引入外部资源,不包括allyes广告,不包括about:blank的空页面。

第五步、等待响应


优化规则 --避免重定向

在重定向完毕并且HTML下载完毕之前,是没有任何东西显示给用户的

涉及服务器负载、数据查询、服务器端缓存等

第七步、接收数据

优化规则 -- 压缩组件

HTML文档、脚本和样式表、XML和JSON的文本响应 压缩如何工作
压缩通常能将响应的数据量减少将近70%

优化规则 -- 精简Javascript和Css

从代码中移除不必要的字符以减少其大小,减少加载时间。

规则规则– 尽量缩减页面大小

页面必须小于150K(不含图片)
a) 静态文件是否gzip
b) 图片是否压缩优化过

第八步、读取Cache

优化规则-- 添加Expire或Cache-Control

应用于不经常变化的组件,包括脚本、样式表、Flash组件、图片
Expires和Cache-Control

规则规则 -- 使用外部的Js和Css文件

尽可能使用外部Js和Css,因为我们目前大部分Js和Css都做了Gzip和缓存技术,可以充分利用。

第九步、处理元素

不要对image和pdf等二进制文件进行gzip压缩

第十步、渲染元素


优化规则 -- 将样式表放在顶部

界面原型页面必须将样式表置于页面顶部,开发人员如无特殊原因也必须将样式表置于顶部。

以往多数是因为masterpage原因无法将所有样式表置顶,在改版修改masterpage时,尽可能按照此原则进行设计。

优化规则 – 建议将脚本放在底部

一般浏览器可以允许并行下载,取决于主机个数、带宽等

(默认情况下,IE是2个而FF是8个)

下载脚本时并行下载实际上是被禁用的。

优化规则-- 移除重复脚本

必须为0

优化规则 -- 避免CSS表达式

影响浏览器渲染时间

优化规则 – 优化图像

尽量使用GIF和PNG

尽量使用png/gif格式的图片,png的图片优先,但是必须注意如要兼容IE6,则png使用一定要注意透明问题。

图片在上次前一定要先用工具压缩优化(png、jpg)

Javascript开发规范

大型的项目在前端 JS 方面有几个需要达成的目标:

  1. 代码逻辑分层

  2. 避免全局变量

  3. 便于多人协作开发

  4. 各部分代码模块化,可以按需加载

  5. 保持全局变量的清洁

  6. 可进行单元测试

推荐书籍

Steve Souders (Yahoo!  
Chief Performance)

Greyhound 灵缇犬 (世界上跑的最快的狗)

转帖注明:http://www.cnblogs.com/and/p/3390676.html

Web 前台优化,布布扣,bubuko.com

时间: 2024-11-06 12:32:39

Web 前台优化的相关文章

web性能优化1

WEB前台的优化规则 一.尽量减少 HTTP 请求 有几种常见的方法能切实减少 HTTP 请求: 1. 合并脚本跟样式文件,如可以把多个 CSS 文件合成一个,把多个 JS 文件合成一个. 2. CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位,把多个图片合成一个图片. 二.使用浏览器缓存 在用户浏览网站的不同页面时,很多内容是重复的,比如相同的JS.CSS.图片等.如果我们能够建议甚至强制浏览器在本地缓存这些文件,将大大降低页面产生的流量,从而降低页面载入

java web项目优化记录:优化考试系统

考试系统在进行压力测试时发现,并发量高之后出现了按钮无反应,试题答案不能写到数据库的问题,于是针对这些核心问题,进行了优化. 数据库方面: Select语句:Select * from TEB_VB_XZTRecord改为select 必须的列 form TEB_VB_XZTRecord,之前看的教学视频里就讲过最好别用*,由于查询了不必要的列,所以导致了低效率. insert优化:考试业务的原因,需要把查询出来的试题,一条条的插入到数据库中.优化前:循环+每次插入一条的insert语句.优化后

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

web单机优化

又得开始写博客了,目测又要一周一篇了,当然了这不算python跟前端的,个人喜欢notepad++可惜不能放图片,word什么的太讨厌了 为什么要单机优化呢,很简单,因为不论以后是各类集群也好,物理机虚拟机也好,只有将个人优势发挥到最大才能提升整体的最低限度,因为木桶原理嘛:再一个,穷啊,玩linux那就是得优化,极尽的压榨操作系统的性能.集群什么的都是从单机演化出来的,so,优化好单机是你继续下一步的初始条件 我们从一个请求连接的总流程来看一下我们可优化的点(运维角度) 其实这中间的每一个步骤

Web前台直接加载GIS格式数据分析

本文以Flex直接加载Shp.DWG和MDB为例. 首先看一份现估测数据: 1)  加载Shp文件,目前直接由前台Flex代码完成: 图1 在ArcCatalog里面的Shp文件 图2 直接在前台加载后的Shp文件 结果显示: Shp文件 大小 加载时间 Shp1 50kb 约3s Shp2 750kb 约10s 分析:未用后台开发,直接使用前台Flex对SHP开放数据加载,省去通讯时间,速度快捷,速度与客户端配置成正比. 说明:直接加载使用了LibertyGIS.swc组件. 2)  加载Dw

【转】关于大型网站技术演进的思考(二十一)--网站静态化处理—web前端优化—下【终篇】(13)

本篇继续web前端优化的讨论,开始我先讲个我所知道的一个故事,有家大型的企业顺应时代发展的潮流开始投身于互联网行业了,它们为此专门设立了一个事业部,不过该企业把这个事业部里的人事成本,系统运维成本特别是硬件采购的成本都由总公司来承担,当然互联网业务上的市场营销成本这块还是由该事业部自己承担,可是网站一年运维下来,该公司发现该事业部里最大的成本居然不是市场营销的开销,而是短信业务和宽带使用上的开销,是不是有点让人感到意外呢?下面我来分析下这个场景吧. 短信这块是和通讯运营商有关,很难从根本上解决,

关于大型网站技术演进的思考(二十一)--网站静态化处理—web前端优化—下【终篇】(13)

本篇继续web前端优化的讨论,开始我先讲个我所知道的一个故事,有家大型的企业顺应时代发展的潮流开始投身于互联网行业了,它们为此专门设立了一个事业部,不过该企业把这个事业部里的人事成本,系统运维成本特别是硬件采购的成本都由总公司来承担,当然互联网业务上的市场营销成本这块还是由该事业部自己承担,可是网站一年运维下来,该公司发现该事业部里最大的成本居然不是市场营销的开销,而是短信业务和宽带使用上的开销,是不是有点让人感到意外呢?下面我来分析下这个场景吧. 短信这块是和通讯运营商有关,很难从根本上解决,

关于大型网站技术演进的思考(二十)--网站静态化处理—web前端优化—中(12)

Web前端很多优化原则都是从如何提升网络通讯效率的角度提出的,但是这些原则使用的时候还是有很多陷阱在里面,如果我们不能深入理解这些优化原则背后所隐藏的技术原理,很有可能掉进这些陷阱里,最终没有达到最佳的预期效果,今天我在这里分析下浏览器和服务端通讯的一些细节问题,希望通过分析这些细节问题,能给大家一个启迪,能更好的理解这些优化原则背后的隐秘,最终能更好的运用这些原则. 网站的通讯技术是构建在http协议上,http协议底层通讯手段使用的是tcp/ip协议,但是tcp通讯协议在建立连接和断开连接这

Web性能优化:图片优化

程序员都是懒孩子,想直接看自动优化的点:传送门 我自己的Blog:http://blog.cabbit.me/web-image-optimization/ HTTP Archieve有个统计,图片内容已经占到了互联网内容总量的62%,也就是说超过一半的流量和时间都用来下载图片.从性能优化的角度看,图片也绝对是优化的热点和重点之一,Google PageSpeed或者Yahoo的14条性能优化规则无不把图片优化作为重要的优化手段,本文覆盖了Web图片优化的方方面面,从基本的图片格式选择.到尚未被