网页的资源加载优化

移动开发中很重要的一块是资源的加载优化。移动开发由于网速低带宽,高延迟,移动设备小内存,低处理器性能的原因,因此很多时候不得不通过优化前端页面的性能来满足用户对网页加载的预期。

前段时间做了相关方面的优化,发现网上的中文教程比较少,都是照着chrome开发者网站上一步一步看下来,找问题来解决,因此将部分有用的网页整理翻译了一下。

一、查看网页加载速度

网页加载时长受到网速影响,一般采用浏览器模拟一个特定网速进行测试,这样优化前与优化后的结果会有一个较准确的对比。

方法:打开调试面板—选择网速,一般我们移动测试用的是regular 3g.然后刷新页面,开始查看页面加载时间。

资源加载顺序与耗时就会依次显示出来,红线表示DOM加载的时间。

二、资源加载的顺序与说明

资源请求的生命周期如下:

重定向 - 应用程序缓存 - DNS - TCP - 请求 - 响应

对于某一个资源,点击资源加载进度条可以看到具体每一阶段的加载时间。或者可以在console面板中,通过timing api获取。

performance.getEntriesByType(‘resource‘).filter(item => item.name.includes("style.css"))

具体解释如下:

  • Queueing(排队):浏览器有连接限制,当网页资源很多时就会出现排队的现象,排队的资源要等到上一个资源加载完毕释放后才能开始请求。比关键资源(如javascript与css)低优先级的请求会被浏览器推迟,一般推迟的都是图片。在许多资源同时发起请求时浏览器默认先加载css,然后javascript,最后才是图片。
  • Stalled(阻塞):请求在发送前的时间被成为阻塞。阻塞的原因有很多种,导致排队的原因或是Proxy Negotiation都能造成阻塞。
  • DNS Lookup(DNS查询):DNS查找的时间,网页资源中请求每一个新域都需要做一次完整的DNS查询。
  • Initial Connection(初次连接):初次建立连接需要花费的时间。
  • Request Sent(请求发送时间):网络请求发送的时间。
  • Waiting(TFFB)(等待时间):等待服务器初始响应的时间。
  • Content Downloading(下载时间):资源下载的时间。

三、诊断原因与解决方案

通过chrome网络面板调试,经常会看到每次加载的时间都不太相同,造成加载慢会有许多原因。前端需要优化,但很多时候是后台或者网络的问题。

1. 排队问题

最长见的问题就是资源排队问题。在HTTP1.0/1.1连接中,chrome最多允许对同一host一次有6个连接,如果网页种有12个资源,那后面的6个就需要排队,直到前面的下载完毕,才能按次序发起请求。解决这个问题,首先要减少网页的请求,例如css sprite、js/css压缩、采用缓存、按需加载等等。

还有一种方法,将资源放在不同的子域名下,比如将图片资源与静态资源分开可以大大加速网页加载时间,但这个方法对HTTP2的连接不适用。

2. TFFB时间慢

TFFB时间通常建议在200ms以下,如果超过推荐值,会引起队列中其他资源下载都跟着变慢。TFFB高主要有两个原因:一是客户端和服务器之前网络情况比较差;二是服务器应用响应比较慢。首先排除网络因素,在本地环境看一下是否仍旧存在TFFB情况,如果有,需要优化应用程序的响应时间,例如优化数据库查询、实现资源缓、修改web服务器配置等等。
如果是由于网络引起的,那服务器与客户端的每一个节点都有可能引起这个问题,最简单的方法是把应用迁移至其他服务器看看是不是存在这个问题,然后一个节点一个节点查明原因。

3. 下载时间过久

如果大量的时间花在下载上,那提高服务器响应也没用,还是应该将文件进行压缩

原文地址:https://www.cnblogs.com/chiangyibo/p/9551656.html

时间: 2024-10-07 15:58:05

网页的资源加载优化的相关文章

让我们再聊聊浏览器资源加载优化

让我们再聊聊浏览器资源加载优化 让我们再聊聊浏览器资源加载优化

也许是被误解的浏览器资源加载优化

几乎每一个前端程序员都知道应该把script标签放在页面底部.关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中,他之所以建议这么做是因为: Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This ensures that the page c

【让我们再聊聊浏览器资源加载优化】

几乎每一个前端程序员都知道应该把script标签放在页面底部.关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中,他之所以建议这么做是因为: Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This ensures that the page c

[转]让我们再聊聊浏览器资源加载优化

作者 李光毅 发布于 2014年6月27日 几乎每一个前端程序员都知道应该把script标签放在页面底部.关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中,他之所以建议这么做是因为: Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This e

js资源加载优化

互联网应用或者访问量大的应用,对js的加载优化是不可少的.下面记录几种优化方法 CDN  + 浏览器缓存 CDN(content delivery network)内容分发网络, 最传统的优化方式.其实就是将自己页面所依赖的js(静态的)放置到CDN上,或者使用一些CDN库,以此降低对应用服务器的请求,而浏览器缓存也是不重复加载js文件的性质. 优点: 1.简单.容易维护 2.304 cache 简单来说就是转掉请求,缓存不重加载. 缺点: 1.缓存会失效,当用户强制刷新时会有请求 2.无法增量

cocos2d-x 图片纹理优化 资源加载方案

原文地址:http://blog.sina.com.cn/s/blog_64d591e80101me1y.html 文章主要解决了我一直以来疑惑的几个问题 1.到底用不用2的N次幂的图片 2.为什么加载资源的时候,内存会突然飙高 3.内存突然飙高的解决方案 4.如何解决程序在加载资源卡的问题 首先是cocos2d-x官网上的优化建议 一帧一帧载入游戏资源 减少绘制调用,使用"Use CCSpriteBatchNode" 载入纹理时按照从大到小的顺序 避免高峰内存使用 使用载入屏幕预载入

chromium网络资源加载分析(一) 主资源加载逻辑分析

最近花了点时间看了看chromium加载网页的逻辑.由于这段内容较为复杂,现在只看了一部分.现将主资源的加载记录下来. 注:下面提到的文件,如果没有指明目录,则在third_party/WebKit目录下 1. ContentViewCore执行loadUrl之后,经过一些逻辑(这些逻辑比较简单,这里不做介绍),最终会走到:render_frame_impl.cc的方法:RenderFrameImpl::OnNavigate 该方法中,有代码:frame->loadRequest(request

各浏览器对页面外部资源加载的策略

这个总结来源于一次优化的请求,最初某个页面的加载十分缓慢,load事件迟迟无法触发,因此希望可以通过对静态文件分域名等方式对页面的外部资源进行优化,拿得load事件尽可能早地触发. 于是我查看了页面的源码,并对外部资源进行了整理,基于下面2个理念画出了一个推测的瀑布图: 1.浏览器对同一个域只能并发2个HTTP请求 – 网上盛传已久.2.javascript文件的加载会阻塞浏览器其他资源的加载 – 同样网上盛传已久. 然而,当我看到各浏览器中实际的瀑布图时,我知道自己又犯了一个简单的错误:太过相

Webkit资源加载介绍

一.webkit资源分类 webkit中有多种资源,大致分为以下几种: HTML文本 CSS样式文本 - CachedCSSStyleSheet 字体 - CachedFont 图片 - CachedImage 只读资源 - CachedRawResource JavaScript文本 - CachedScript SVG - CachedSVGDocument 视频字幕 - CachedTextTrack XSL样式表 - CachedXSLStyleSheet 类图如下: HTML文本是网页