再发请求获取这些资源文件(一)_光明网(组图)

　　再发请求获取这些资源文件(一)_光明网(组图)

　　包括css、js、图片等，然后发送请求获取这些资源文件。在 HTTP 1.1 请求中，

　　多个请求可以重叠，但是页面文件必须先到达才能知道要请求哪些资源文件。

　　所以整个过程有几个阶段，第一个阶段是第一个字节的获取时间，

　　即从URL请求到服务器收到HTTP请求并返回响应内容的时间，

　　这不仅仅是 DNS 和建立连接的时间。对于动态页面，

　　只有当服务器执行动态代码并返回页面代码时，

　　所以包括操作和数据库操作会直接增加首字节获取时间。

　　对于静态文件，第一个字节的获取时间通常更快。

　　但是如果与服务器的网络不畅，比如服务器在国外，就会造成长时间的延迟。

　　在阿里云的云监控中，可以任意设置HTTP监控点来监控服务器的响应时间。

　　比如我在同一台服务器上设置了两个网站：

　　

　　这里可以清楚的看到，对于需要调用数据库的Wordpress，

　　响应时间显然比下面简单的 HTML 内容要长很多。

　　至于响应时间，基本上响应时间是即时的。在这里可以看到服务器物理距离的影响。

　　因为服务器在杭州，从杭州访问只需3ms，从青岛访问需要4ms。

　　至于数据到服务器再返回的响应时间，可以得到ping命令。

　　说到ping命令很多人都用过，但是好像很多人只是用它来看看服务器是不是打不通。 . .

　　先说一下ping的原理：向目的地发送ICMP回显请求消息，并报告是否收到了想要的ICMP回显响应。

　　理论上，ping发送的数据大小应该和对方一样大小，这样就可以很容易的看到与服务器的通信状态了。

　　所以如果ping的响应时间一直稳定，突然有波动，可能是突然满带宽造成的，

　　这时候有了对服务器资源的监控，就可以很容易的看出问题出在哪里了。 （貌似我的带宽没有问题...囧~）

　　

　　在ping的同时不断刷新页面，可以看到某一时刻的时间明显变长了，也就是此时的带宽已经被占用了。

　　第二阶段是获取页面文件的时间。在获取页面文件之前，不会请求任何资源文件。

　　因为不知道页面上有什么资源文件，这个时间也很关键。

　　第三阶段是获取head中各个资源文件的时间。资源文件按照它们在 HTML 页面中出现的顺序加载。

　　所以head里的资源会先加载，head主要是css和js文件，然后页面渲染，

　　所以要特别注意头部所需资源的加载时间。毕竟在页面渲染之前，用户看到的都是空白。

　　第四阶段是获取剩余资源文件的时间。这部分主要是图片、*敏*感*词*、视频等文件。

　　重要性没有那么高。毕竟页面已经出来了。大多数用户认为在几秒钟内看到它们加载是可以接受的。

　　其实页面渲染时间还是有的，但是因为它和加载同步，通常不会比加载慢，所以可以忽略。

　　测试工具

　　如果想直观的获取这些数据，可以直接看页面的时间线，也就是瀑布图，

　　现在各大浏览器的内置调试工具都可以实现这个功能。以这个网站和safari为例，

　　可以看到如下图：第一次访问（在safari中可以使用shift刷新按钮忽略缓存）：

　　

　　再次访问：

　　

　　从图中可以清楚的看出，一共引用了37个资源文件，共979.9KB的数据。第一次访问总时间3.25s，第二次访问总时间2.02s。

　　说说第一次访问：第一行蓝色的是页面文件，总大小为80.91KB，实际传输大小为81.27KB，

　　响应时间1.06s，加载时间250.9ms。然后文件解析完成后，开始请求各个资源文件。

　　这里可以看到两条虚线，蓝色的是DOMContent事件触发的时间，这里是3.38s，

　　表示浏览器解析完文档（但其他资源如图片可能还没有下载），

　　红色的是Load事件的触发时间，这里是2.75s，表示所有资源都已经加载完毕。

　　第一次访问时必须请求所有资源，第二次访问时可以使用本地缓存的数据来加快资源加载。

　　所以为不经常变化的静态资源设置一个过期时间，并告诉浏览器在一定时间内不需要重新加载这个资源。

　　可以加快用户的重访速度，显着减少第四阶段的时间。

　　此时间线不仅可以在本地浏览器中查看，也可以在相关测试网站中查看，

　　比如阿里的阿里测试，Google Page Speed和Yahoo YSlow。

　　有一个结合了Google Page Speed和YahooYSlow的工具，叫做GTMetrix，也是一个不错的工具。

　　同时，这些网站也会为网站提供优化建议。

　　还有一个工具叫17CE，可以同时测试不同地区测试服务器的响应时间和PING时间，

　　可用于了解不同地区用户的访问速度。

　　优化方法

　　好了，有了相关的基础知识和工具，就​​可以进行针对性的优化了。下面分别说说如何优化每个部分：

　　第一阶段，服务器响应时间，这部分基本没有什么好办法，如果是动态网站，

　　主要是基于算法和数据库优化，以及使用AJAX异步读取数据，其实是后端的事情。

　　我不会在这里讨论它。但是一个网站如果服务器合规时间超过2秒，

　　基本上可以认为是服务器宕机了，一般应该控制在500ms以内，

　　可能对人不明显，如果能控制在250ms以内就更好了。

　　第二阶段是获取页面文件。第一，页面文件一般不大，都是纯文本。

　　所以优化的方法是开启Gzip压缩，开启，

　　对于Apache，先把httpd.conf中LoadModule deflate_modulemodules/mod_deflate.so前的#去掉，

　　然后重启Apache，并添加.htaccess：

　　AddOutputFilter DEFLATE html xml php js css text/htmltext/plain

　　Gzip 压缩对这种比较松散的纯文本效果还是比较明显的。比如我的主页从50K压缩到了10K。

　　也使用外部链接 CSS 文件。不要把样式表直接放到HTML页面中，这样可以缓存CSS文件。

　　第三阶段，头部的资源文件主要是css和js文件。有几种方法：

　　第四阶段，这个段是真正的大数据。现在用户的带宽通常不是问题。

　　瓶颈主要在服务器上。想想看。如果一个页面需要 2MB 的数据才能完全加载，

　　那么如果服务器的出口带宽只有1Mbps，所有的延迟都会被忽略。在只有一个用户访问的情况下，

　　传输 2MB 的数据最快需要 16 秒。这是用户无法忍受的。

　　所以对于阿里云的ECS，如果你是包月的，带宽不高，那么你必须尽量减少直接从ECS访问的所有资源。

　　方法主要是使用OSS存储、CDN加速和GZip压缩。这个具体的优化很详细，力求尽量减少直接在ECS上访问的数据量。

　　但是Wordpress很麻烦。系统自带的、插件中引用的一些js和CSS文件，不方便合并和更改位置。 . .

　　只做尽可能多的优化。以我的网站为例，之前把所有的图片都放到CDN之后，

　　加载首页还有大约220KB的数据要从ECS中取出，所以如果只有1Mbps的带宽，至少需要2秒。

　　后来我把主题里的所有图片和bootstrap，jquery转CDN，加上GZip压缩，

　　经过优化，现在只有80KB的数据，可以保证1秒内加载完毕。

　　其他需要注意的事项包括：

　　至于访问量巨大的网站，保存每一个字节很重要。还有更多优化方法。可以参考Google PageSpeed和

　　Yahoo YSlow的页面评价结果，不过这两个服务器在国外，所以响应时间会长很多，这个数据可以忽略。

　　最后说一下如何设置缓存时间。对于 Apache，

　　首先将httpd.conf中LoadModule expires_modulemodules/mod_expires.so前的#去掉，然后重启Apache，

　　然后在.htaccess中添加相应的代码来设置不同文件类型的缓存时间，

　　以下设置为1个月的图片文件和JS文件，以及1年的图标文件：

　　ExpiresActive OnExpiresByType image/jpg "access plus 1month"

　　ExpiresByType image/jpeg“访问加1个月”

　　ExpiresByType 图像/gif“访问加 1 个月”

　　ExpiresByType image/png “访问加 1 个月”

　　ExpiresByType text/x-javascript“访问加 1 个月”

　　ExpiresByType 申请/x-shockwave-flash“访问加1个月”

　　ExpiresByTypeimage/x-icon“访问加1年”