想知道wpt是什么? (想知道你熬过了多少没星星的夜晚)

本文目录导航：

• 想知道wpt是什么?
• 怎样检查网页每一局部的加载速度,比如图片,js,css文件的加载速度
• 记一次性微信小程序页面加载慢的排查环节

想知道wpt是什么?

wpt是Web Page Test的缩写，它是一个在线的网站性能测试工具。

Web Page Test能够对网站的加载性能启动片面的测试和剖析。

经过模拟不同天文位置、不同网络条件下的用户访问，Web Page Test能够提供关于页面加载期间、各个资源加载时长、主机照应期间等详细数据。

这些数据关于优化网站性能，优化用户体验至关关键。

经常使用Web Page Test，用户可以选用测试地点，这包括了世界各地的多个数据核心，以模拟不同天文位置用户的访问体验。

同时，用户还可以设置网络条件，如带宽、提前等，以模拟不同网络环境下的访问状况。

测试实现后，Web Page Test会生成一份详细的测试报告，报告中蕴含了页面加载的每一个细节，如各个资源的加载时长、主机的照应期间、页面渲染的期间等。

这些数据可以协助用户找出性能瓶颈，优化网站性能。

举个例子，假设一个网站在某些地域的加载速度较慢，经过Web Page Test的测试报告，咱们可以检查是哪个资源加载缓慢，是图片、脚本还是其余资源。

而后，咱们可以针对这些资源启动优化，如紧缩图片、优化脚本加载等，以优化网站的加载速度。

总的来说，Web Page Test是一特性能弱小的网站性能测试工具，它能够协助用户片面了解网站的加载性能，找出性能瓶颈，并提供优化倡导。

无论是网站开发者、运维人员还是网站一切者，都可以经过Web Page Test来优化网站性能，优化用户体验。

怎样检查网页每一局部的加载速度,比如图片,js,css文件的加载速度

须要预备的资料区分是：电脑、chrome阅读器。

1、首先，关上chrome阅读器，进入要检查的网页，例如。

2、键盘按F12，会调出开发者工具，点击“Network”标签页。

3、键盘按“F5”键以刷新页面，此时从开发者工具可以看到各个资源（例如图片、css文件、js文件）的加载破费期间。

记一次性微信小程序页面加载慢的排查环节

公司新上线了一个微信小程序，在测试环境以及小程序体验版上测试一切反常，但上线之后，页面加载尤其慢。

经过运维排查，一切的恳求抵达主机后均在1s内解决实现并照应，偶然有2-3s的恳求，极少。

既然服务端解决恳求没有疑问，那么，加载或者出如今小程序自身或网络提前，但后者或者性较低。

于是，经常使用fiddler抓包，其中一个加载较慢的恳求结果如下： 关键期间节点如下： · 客户端与主机实现tcp链接期间是11:31:35（时分秒） · 客户端开局向服务端发送恳求的期间是11:31:36（时分秒） · 服务端接纳到恳求的期间是11:31：36（时分秒） · 服务端开局照应的期间是11:31:46（时分秒） 也就是说，从主机接纳到恳求到开局照应耗时10s，可这跟运维检查的日志结果不符！ 鉴于下面的抓包结果和消费日志结果相悖，选择经常使用curl对耗时较长的http恳求启动剖析。

运转结果如下 对应的结果含意如下： · time_namelookup ：DNS 域名解析的时刻，就是把转换成 ip 地址的环节 · time_connect ：TCP 衔接建设的期间，就是三次握手的期间 · time_appconnect ：SSL/SSH 等下层协定建设衔接的期间，比如 connect/handshake 的期间 · time_redirect ：从开局到最后一个恳求事务的期间 · time_pretransfer ：从恳求开局到照应开局传输的期间 · time_starttransfer ：从恳求开局到第一个字节将要传输的期间 · time_total ：这次恳求破费的所有期间 那么对应的期间点应该是： · DNS解析耗时：0.005s · TCP建设衔接的耗时：0.035-0.005=0.03s · SSL握手实现耗时：3.8-0.034=3.7s · server解决数据的期间：3.8402-3.8401=0.0001s · 总体的耗时：14.5s emmm，依照这个结果来看，从主机开局照应到传输实现一共耗时14.5-3.8=10.7s。

那么这里疑问又来了，这结果跟fiddler的结果齐全同样，究竟是在哪个环节出了疑问？ fiddler的结果显示从主机接纳到恳求到开局照应耗时10s，是主机解决恳求消耗了10s；而curl显示主机解决恳求只用了0.0001s，照应开局到完结耗时10.7s。

究竟哪个是对的，难道是依据自身有疑问？ 于是在跟运维共事一波交换之后，获取恳求流转环节如下： 客户端<---------->CDN主机<---------->Nginx代理<---------->运行主机<---------->DB 弄清恳求流转环节之后，手动发送恳求，实时检查Nginx和运行主机日志，发现恳求收回后，距离一段期间（10s左右）Nginx日志才有输入，接着很快App Server日志也有输入（包括恳求和照应）。

理想就摆在眼前，是CDN主机<---------->Nginx代理之间产生了疑问，详细是为什么目前还不分明。

那么fiddler和curl抓包的结果如何解释？ fiddler：从主机接纳到恳求到开局照应耗时10s，是正确的。

curl：主机解决恳求只用了0.0001s，照应开局到完结耗时10.7s。

这里就有疑问了，要想解释得通，只能说time_pretransfer和time_starttransfer是CDN主机的照应期间，因为性能了CND，在向小程序运行主机发送恳求时，会先恳求到CDN主机此时CDN主机很快就照应了客户端的恳求，但CDN主机在转发恳求到Nginx代理时产生了提前，因此在curl的恳求结果中才会看起来像是照应开局到照应完结耗时较长。

至于为什么恳求从CND主机到运行主机会产生提前，目前还没有论断。

待降级http:///art//?foxhandler=RssReadRenderProcessHandler