【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端)

简介: 原文:【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端)构建高性能ASP.NET站点之二 优化HTTP请求(前端)   前言: 这段时间比较的忙,文章写不是很勤,希望大家谅解.   上一篇文章主要讲述了请求一个页面的过程,同时也提出了在这个过程中的一些优化点,本篇就开始细化页面的请求过程并且提出优化的方案.
原文: 【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端)

构建高性能ASP.NET站点之二 优化HTTP请求(前端)

  前言: 这段时间比较的忙,文章写不是很勤,希望大家谅解.

  上一篇文章主要讲述了请求一个页面的过程,同时也提出了在这个过程中的一些优化点,本篇就开始细化页面的请求过程并且提出优化的方案.同时,在上篇文章中,不少朋友也提出了一些问题,在本篇中也对这些问题给出了回答!

 

 

  系列文章链接:

  构建高性能ASP.NET站点 开篇

  构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

  构建高性能ASP.NET站点之二 优化HTTP请求(前端)

  构建高性能ASP.NET站点之三 细节决定成败

  构建高性能ASP.NET站点 第五章—性能调优综述(前篇)

  大型高性能ASP.NET系统架构设计  

  构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

  构建高性能ASP.NET站点 第五章—性能调优综述(后篇)  

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(上篇)—识别性能瓶颈

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下后篇)—减少不必要的请求

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能  

 

 

 

  本篇的议题如下:

  HTTP请求的优化

 

  HTTP请求的优化

  在一个网页的请求过程中,其实整个页面的html结构(就是页面的那些html骨架)请求的时间是很短的,一般是占整个页面的请求时间的10%-20%.在页面加载的其余的时间实际上就是在加载页面中的那些flash,图片,脚本的资源. 一直到所有的资源载入之后,整个页面才能完整的展现在我们面前.

 

  下面,我们就从一个页面开始讲述:


 1  <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
 2  < html  xmlns ="http://www.w3.org/1999/xhtml" >
 3  < head >
 4       < title > 小洋,燕洋天 </ title >
 5 
 6       < script  type ="text/javascript"  src ="../demo.js" >
 7       </ script >
 8 
 9  </ head >
10  < body >
11       < div >
12           < img  src ="../images/1.gif"   />
13           < img  src ="../images/2.gif"   />
14           < img  src ="http://yanyangtian.cnblogs.com/image/3.gif"   />
15           < img  src ="http://yanyangtian.cnblogs.com/image/4.gif"   />
16           < img  src ="http://yanyangtian.cnblogs.com/image/5.gif"   />
17           < img  src ="http://yanyangtian.cnblogs.com/image/6.gif"   />
18           < img  src ="http://yanyangtian.cnblogs.com/image/7.gif"   />
19           < img  src ="http://yanyangtian.cnblogs.com/image/8.gif"   />
20           < img  src ="http://yanyangtian.cnblogs.com/image/7.gif"   />
21           < img  src ="http://yanyangtian.cnblogs.com/image/8.gif"   />
22       </ div >
23  </ body >
24  </ html >
25 


  如果我们向服务器请求这个页面,客户端的浏览器首先请求到的数据就是html骨架,:

 

 1  <! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
 2  < html  xmlns ="http://www.w3.org/1999/xhtml" >
 3  < head >
 4       < title > 小洋,燕洋天 </ title >
 5 
 6       < script  type ="text/javascript"  src ="../demo.js" >
 7       </ script >
 8 
 9  </ head >
10  < body >
11       < div >
12           < img  src ="../images/1.gif"   />
13           < img  src ="../images/2.gif"   />
14           < img  src ="http://yanyangtian.cnblogs.com/image/3.gif"   />
15           < img  src ="http://yanyangtian.cnblogs.com/image/4.gif"   />
16           < img  src ="http://yanyangtian.cnblogs.com/image/5.gif"   />
17           < img  src ="http://yanyangtian.cnblogs.com/image/6.gif"   />
18           < img  src ="http://yanyangtian.cnblogs.com/image/7.gif"   />
19           < img  src ="http://yanyangtian.cnblogs.com/image/8.gif"   />
20           < img  src ="http://yanyangtian.cnblogs.com/image/7.gif"   />
21           < img  src ="http://yanyangtian.cnblogs.com/image/8.gif"   />
22       </ div >
23  </ body >
24  </ html >
25 


 

  在此之前,首先来普及一下页面加载的小知识:

当页面的html骨架载入了之后,浏览器就开始解析页面中标签,从上到下开始解析.

 

首先是head标签的解析,如果发现在head中有要引用的js脚本,那么浏览器此时就开始请求脚本,此时整个页面的解析过程就停了下来,一直到js请求完毕.

 

之后页面接着向下解析,如解析body标签,如果在body中有img标签,那么浏览器就会请求imgsrc对应的资源,如果有多个img标签,那么浏览器就一个个的解析,解析不会像js那样等待的,如果发现imgurl地址是同一个地址,那么浏览器就会充分的利用这个已经打开的tcp连接顺序的去一个个的请求图片,如果发现有的imgurl地址不同,那么浏览器就另开tcp连接,发送http请求.

 

注意之前请求js的区别:请求需要js,浏览器会一直等待,不在解析下面的html标签

但是解析到img的时候,尽管此时需要加载图片,但是页面的解析过程还是会继续下去的,然后决定是否发送新的tcp连接加载资源.

 

  大家可能觉得这个之前的代码片段一样,确实代码是一样的,但是,在最开始的时候,发送到浏览器中的只是那些html的代码,任何的js脚本和图片还没有发送过来.

 

  html代码到了浏览器中,那么浏览器就开始一步步的解析这些代码了,只要遇到了需要加载的资源,浏览器就向服务器发出http请求,请求所需的资源.

  整个页面的加载时间图如下:

 

  大家从图中可以看出:

  第一条线中分为一半黄色和一半蓝色,其实黄色的部分就代表了打开一个tcp连接花的时间,而后面的蓝色的部分就是请求整个html骨架文档的时间.可以看出,请求html骨架的时间是很短的.其余蓝色的线就表示了图片,脚本资源加载所花的时间.

 

  很显然,这样页面的整个加载时间就很长了.因为页面的加载几乎是顺序的载入,时间就是所有资源加载时间的总和.

  下面我们把上面的页面代码代为如下:

<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
< html  xmlns ="http://www.w3.org/1999/xhtml" >
< head >
    
< title > 小洋,燕洋天 </ title >

    
< script  type ="text/javascript"  src ="../demo.js" >
    
</ script >

</ head >
< body >
    
< div >
        
< img  src ="http://demo1.com/images/1.gif"   />
        
< img  src ="http://demo1.com/images/2.gif"   />
        
< img  src ="http://demo2.com/image/3.gif"   />
        
< img  src ="http://demo2.com/image/4.gif"   />
        
< img  src ="http://demo3.com/image/5.gif"   />
        
< img  src ="http://demo3/image/6.gif"   />
        
< img  src ="http://demo4.com/image/7.gif"   />
        
< img  src ="http://demo4.com/image/8.gif"   />
        
< img  src ="http://yanyangtian.cnblogs.com/image/7.gif"   />
        
< img  src ="http://yanyangtian.cnblogs.com/image/8.gif"   />
    
</ div >
</ body >
</ html >

 

  我们再来看看页面的加载时间图

 

 


  这就是所谓的并行载入了.

  比较一下两段代码的不同:其实就在imgsrc属性上面:

    第一段页面的代码:imgsrc属性都是指向一个域名的.

    第二段页面的代码:imgsrc属性指向了不同的域名

  这样做的结果是什么?

 

  请大家注意比较imgsrc的不同.

 

  解释之前,首先来看一个小的常识(在上篇文章中也提过):

当页面请求向服务器请求资源的时候,如果浏览器已经在客户端和服务器之前打开了一个tcp连接,而且请求的资源也在开了连接的服务器上,那么以后资源的请求就会充分的利用这个连接去获取资源. 这样也就是第一个时间图的由来.

 

如果请求的图片分别位于不同的服务器网站,或者那个请求的服务器网站有多个域名,那么因为浏览器就会为每一个域名去开一个tcp连接,发送http请求,这样,结果就是同时开了多tcp连接,这也是第二个时间图的由来.

 

  虽然说并行加载,确实使得页面的载入快了不少,但是也不是每一个图片或者其他的资源都去搞一个不同的域名,像之前的第二个并行载入图片的例子,也是让两个图片利用一个tcp连接.如果每个图片都去开一个连接,这样浏览器就开了很多个连接,也是很费资源的,而且浏览器还可能会僵死”.而且有时还会严重的影响性能.

 

  所以,这是需要权衡的.

  除了上面的优化方式,还有其他的图片优化的加载方式.主要是通过减少http的请求达到优化

 

 

  大家都知道网站的一个menu菜单,有些菜单就是用图片作出来的.

 


 

  如果上面的图片一个个载入,势必影响速度,如果开多和请求,有点得不偿失.而且图片也不是很大,那么就一次把整个menu需要的图片作为整个图片,一次加载,然后通过map的方式,控制点击图片的位置来达到导航的效果.

 

  这样一个问题就是:算出图片的坐标,不能点击了主页图片,然后却跳到了帮助页面了.

 

  本篇就讲述到这里,下篇讲述其他的资源文件的优化,希望 多多提出建议,争取把这个系列写好!

 

 

版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。

   http://www.cnblogs.com/yanyangtian

 

 

  另外补上网友发的信息:

#21楼 2010-07-28 14:51 | leening       
我一般处理图片的方式是叫美工把所有的小图片合成一张大的图片,加载到页面,然后用CSS去定位,当然用map的方式是可以的,但是用CSS的方式来的快且方便,参考代码如下:
div{ background:#FFF url(image) no-repeat fixed x y;}
x,y表示背景图片的定位,而不需要是坐标,具体可参考如下链接:
http://www.dwww.cn/news/2009-3/20093111943478871.shtml
谢谢

 

 

 

相关实践学习
基于函数计算快速搭建Hexo博客系统
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
2天前
|
Web App开发 存储 缓存
第八篇 提升网页性能:深入解析HTTP请求优化策略(三)
第八篇 提升网页性能:深入解析HTTP请求优化策略(三)
|
2天前
|
消息中间件 前端开发 JavaScript
第七篇 提升网页性能:深入解析HTTP请求优化策略(二)
第七篇 提升网页性能:深入解析HTTP请求优化策略(二)
|
2天前
|
安全 Android开发
Android之OKHttp基本使用和OKHttp发送https请求安全认证
Android之OKHttp基本使用和OKHttp发送https请求安全认证
11 0
|
3天前
|
移动开发 前端开发 数据可视化
前端HTML:构建网页的基石
前端HTML:构建网页的基石
21 0
|
2天前
|
前端开发 Java Go
从前端到后端:构建现代化Web应用的技术实践
本文将介绍如何通过前端和后端技术相结合,构建现代化Web应用的技术实践。我们将探讨前端开发、后端架构以及多种编程语言(如Java、Python、C、PHP、Go)在构建高效、可扩展的Web应用中的应用。
|
2天前
|
编解码 前端开发 JavaScript
第六篇 提升网页性能:深入解析HTTP请求优化策略(一)
第六篇 提升网页性能:深入解析HTTP请求优化策略(一)
|
2天前
|
Web App开发 前端开发 JavaScript
构建跨浏览器兼容的前端应用:技术实践与挑战
【5月更文挑战第16天】构建跨浏览器兼容的前端应用是应对浏览器差异和多样性的挑战。使用现代框架(如React、Vue)能自动转换代码,编写可移植的Web标准代码,结合浏览器兼容性测试工具和Polyfill解决旧浏览器支持问题。关注浏览器更新,应对性能、API差异和样式问题,采用渐进增强、条件判断和CSS Reset策略确保应用在各种浏览器上运行良好。
|
2天前
|
前端开发 JavaScript NoSQL
从前端到后端:构建全栈开发者的必备技能
随着互联网技术的不断发展,全栈开发者的需求日益增长。本文将介绍如何从前端到后端,掌握全栈开发所需的关键技能,包括前端框架的选择、后端语言的学习以及数据库的应用,帮助读者构建成为全面的技术专家。
|
3天前
|
存储 JavaScript 前端开发
使用Vue.js构建交互式前端的技术探索
【5月更文挑战第12天】Vue.js是渐进式前端框架,以其简洁和强大的特性深受开发者喜爱。它聚焦视图层,采用MVVM模式实现数据与视图的双向绑定,简化开发。核心特性包括响应式数据绑定、组件化、模板系统和虚拟DOM。通过创建Vue实例、编写模板及定义方法,可以构建交互式前端,如计数器应用。Vue.js让复杂、交互式的前端开发变得更加高效和易维护。
|
3天前
|
开发框架 Dart 前端开发
【Flutter前端技术开发专栏】Flutter中的Web支持:构建跨平台Web应用
【4月更文挑战第30天】Flutter,Google的开源跨平台框架,已延伸至Web领域,让开发者能用同一代码库构建移动和Web应用。Flutter Web通过将Dart代码编译成JavaScript和WASM运行在Web上。尽管性能可能不及原生Web应用,但适合交互性强、UI复杂的应用。开发者应关注性能优化、兼容性测试,并利用Flutter的声明式UI、热重载等优势。随着其发展,Flutter Web为跨平台开发带来更多潜力。
【Flutter前端技术开发专栏】Flutter中的Web支持:构建跨平台Web应用