2024年9月如何优化网站的访问速度和时间(网站访问速度优化方案)
⑴如何优化网站的访问速度和时间(网站访问速度优化方案)
⑵本文为大家介绍如何优化网站的访问速度和时间(网站访问速度优化方案),下面和小编一起看看详细内容吧。
⑶很多站长都遇到过网站访问速度不够快的问题。今天让我们试着理解和解决这个问题。
⑷先说说当我们用浏览器访问一个网页,看到这个网页出现的时候是怎么回事?
⑸首先,您需要在HTTP请求之前执行此操作:
⑹获取IP。在浏览器地址栏输入URL并提交后,它会先到DNS本地缓存表中查找,如果有就直接告诉IP地址。如果没有,则需要网关DNS查找,以此类推,找到对应的IP后,返回给浏览器。
⑺建立TCP连接。获取IP后,开始与请求的服务器完成三次握手,建立TCP连接。
⑻建立连接后,向服务器发送http请求。
⑼HTTP请求会先获取页面文件,然后解析页面文件中的资源文件,
⑽包括css、js、图片等,然后发送请求获取这些资源文件。在HTTP.请求中,
⑾多个请求可以重叠,但是页面文件必须先到才能知道请求哪些资源文件。
⑿所以整个过程有几个阶段,第一个阶段是第一个字节获取时间,
⒀即从URL请求到服务器收到HTTP请求后返回响应内容的时间,
⒁这不仅仅是DNS和建立连接的时间。对于动态页面,
⒂只有在服务器执行动态代码并返回页面代码后,
⒃所以包括计算和数据库操作,这些都会直接增加第一个字节的获取时间。
⒄对于静态文件,获取第一个字节的时间通常更快。
⒅但是如果跟服务器的网络不畅,比如服务器在国外,就会造成很长的延迟。
⒆在阿里云的云监控中,可以任意设置HTTP监控点,监控服务器的响应时间,
⒇例如,我在同一台服务器上建立了两个网站:
⒈这里可以清楚的看到,对于需要调用数据库的Wordpress,
⒉响应时间明显长于下面仅使用简单XML读取的eitdesign。
⒊对于eitdesign来说,响应时间基本是即时的,这里可以看出服务器物理距离的影响。
⒋因为服务器在杭州,从杭州访问只需要ms,从青岛访问只需要ms。
⒌至于数据到服务器再返回的响应时间,可以通过ping命令获取。
⒍据说很多人都用过ping命令,但是好像很多人只是用来看看服务器是不是不可达。
⒎先说一下ping的原理:向目的地发送一个ICMPechorequest报文,报告是否收到了想要的ICMPechoresponse。
⒏理论上对方回复的数据应该和ping发送的数据大小一样,这样就可以很容易的看到与服务器的通信状态。
⒐所以,如果ping的响应时间一直很稳定,突然出现波动,可能是突然满带宽造成的。
⒑这时候有了服务器资源的监控,就很容易看出问题出在哪里了。
⒒边ping边不断刷新页面,可以看到某个时刻的时间明显变长了,也就是此时带宽已经被占满了。
⒓第二阶段是获取页面文件的时候。在获取页面文件之前,不会请求任何资源文件。
⒔因为目前还不知道页面上有哪些资源文件,所以这段时间也很关键。
⒕第三阶段是获取head中各种资源文件的时间。资源文件按照它们在HTML页面中出现的顺序加载。
⒖所以会先加载head中的资源。head中的主要文件是css和js文件,然后会渲染页面。
⒗所以要特别注意head中所需资源的加载时间。毕竟在页面渲染之前,用户看到的都是空白。
⒘第四阶段是获取剩余资源文件的时间,主要是图片、动画、视频等文件。
⒙重要性不是那么高,在所有页面都出来之后,大多数用户觉得看他们加载几秒钟是可以接受的。
⒚其实页面渲染是有时间的,但是由于是和loading同步完成的,一般不会比loading慢,所以可以忽略。
⒛如果想直观的获取这些数据,可以直接看页面的时间线,也就是瀑布图。
现在各大浏览器内置的调试工具都可以实现这个功能。以本网站和safari为例,
可以看到下图:第一次访问(在safari中按shift+refresh键可以忽略缓存:
从图中可以清楚的看到,一共引用了个资源文件,一共M的数据。第一次访问的总时间是.秒,第二次访问的时间是ms。
先说第一次访问:第一行蓝色的是页面文件,总大小.KB,压缩后实际传输大小.KB。
响应时间为ms,加载时间为.ms。然后文件解析完成后,开始请求各个资源文件。
这里可以看到两条虚线,蓝色的是DOMContent事件触发时间,这里是ms,
表示当浏览器解析完文档(但可能还没有下载图片等其他资源时,
而红色的这条是Load事件触发时间,这里是.秒,表示所有资源都已经加载完成了。
首次访问时所有资源都要请求,而再次访问时就可以利用本地缓存数据加快资源载入速度了。
所以对不常变化的静态资源设置一个过期时间,告诉浏览器在一定期间内都不需要重新载入这个资源。
可以加快用户再次访问的速度,显著减少第四阶段的时间。
这个时间线不仅可以在本地浏览器中查看,也可以在相关的测试网站上看到,
例如阿里的阿里测,还有GooglePageSpeed和YahooYSlow.
有一个工具把GooglePageSpeed和YahooYSlow结合了一下,叫GTMetrix,也是不错的工具。
同时这些网站也会针对站点提供优化的建议。
还有个工具叫CE,可以同时从不同地区的测试服务器测试响应时间和PING时间,
可以用于了解不同地区用户的访问速度。
好了,现在有了相关的基础知识和工具,就可以有针对性的进行优化了。下面来分别说一说各部分要如何来优化:
第一阶段,服务器响应时间,这部分基本上没啥太好的方法了,如果是动态网站的话,
主要以算法和数据库优化为主,还有使用AJAX异步读取数据之类的,其实是后端的事,
这里就不展开讨论了。不过一个网站如果服务器顺应时间超过秒,
基本上可以认为这服务器已经挂了,通常应该控制在ms以内,
或许让人感觉并不明显,如果能控制在ms以内就更好了。
第二阶段,获取页面文件,首先页面文件通常都不大,而且都是纯文本。
于是优化的方法就是开启Gzip压缩,开启方式,
对于Apache来说,首先要把httpd.conf里的LoadModuledeflate_modulemodules/mod_deflate.so前的#去掉,
然后重启Apache,然后在.htaess中加入:
IfModulemod_deflate.c
AddOutputFilterDEFLATEhtmlxmlphpjscsstext/htmltext/plain
Gzip压缩对于这种比较松散的纯文本效果还是比较明显的,比如说我的这个首页就从K压缩到了K。
还有要使用外部linkCSS文件,不要把样式表直接放入HTML页在,这样CSS文件可以设置缓存。
第三阶段,head中的资源文件,主要是css和js文件,方法有这几个:
使用minify之后的js和css,原版用于修改,输出min版用于使用,虽然不利于阅读,但是尺寸明显减小。
合并多个css和js文件,减少http请求数量。
把不必要的js文件移到页面后面去加载,对于那些不影响渲染的js文件,移到第四阶段再加载可以减少页面显示时间。
对于不常更新的文件设置缓存时间并使用OSS或CDN
第四阶段,这一段才是真正的大数据量,现在通常用户的带宽都不是问题了,
瓶颈主要出现在服务器上了,可以想想看,如果一个页面完全载入需要MB的数据,
那么如果服务器出口带宽只有Mbps的话,则忽略各种延时不计,在只有一个用户访问的情况下,
最快也需要秒的时间才能传输完成这MB的数据。这对于用户来说是不能忍的。
于是对于阿里云的ECS来说,如果你是包月的,没有很高带宽的话,就要尽量减少一切从ECS上直接访问的资源。
方法主要是使用OSS存储,CDN加速和GZip压缩。这具体的优化就很细致了,努力将ECS上直接访问的数据量减至最少,
但是Wordpress很麻烦,有些系统自带的和插件里引用的js和CSS文件,不方便合并和改变位置。。。
只能尽量优化。以我这个网站为例,之前在将所有图片都放入CDN之后,
载入首页还是大概要有KB的数据要从ECS上走,这样只有Mbps带宽的话,至少需要秒时间。
后来又移动了主题内的所有图片和bootstrap,jquery至CDN,再加上GZip压缩,
经过优化之后,现在只有KB的数据,可以保证在秒以内加载完成。
其它需要注意的地方包括:
至于访问量巨大的网站,那更是节约每一个字节都很重要,还有更多的优化方法,可以具体参考GooglePageSpeed和
YahooYSlow的页面评测结果,不过这两个服务器都在国外,所以响应时间会长很多,这一数据可以忽略。
最后来说说如何设置缓存时间,对于Apache来说,
首先要把httpd.conf里的LoadModuleexpires_modulemodules/mod_expires.so前的#去掉,然后重启Apache,
然后在.htaess中加入相应的代码就可以设置不同文件类型的缓存时间了,
如下设置的是图片文件和JS文件个月,图标文件年:
IfModulemod_expires.c
ExpiresActiveOnExpiresByTypeimage/jpgaessplusmonth
ExpiresByTypeimage/jpegaessplusmonth
ExpiresByTypeimage/gifaessplusmonth
ExpiresByTypeimage/pngaessplusmonth
ExpiresByTypetext/x-Javascriptaessplusmonth
ExpiresByTypeapplication/x-shockwave-flashaessplusmonth
ExpiresByTypeimage/x-iconaessplusyear
其实这篇文章的诞生源于阿里云服务器的小故障,某一天开始响应时间变的非常长,以至于云监控报警,当时上去看了一下一度响应时间达到秒以上。。。
于是在想是发生什么了。。。就想尽各种办法开始优化自己的网站,虽然这故障很快修复了,但是有机会让我重新研究了一下页面加速的各种知识。让我清醒的意识到Mbps带宽是多么多么的小。。。
希望大家在这篇文章中能找到自己想要的东西,小小的加速一下自己的网站~~~