Web ページのパフォーマンス測定指標と提案について_html/css_WEB-ITnose

まず写真をご覧ください:

注: 右側の写真は私たちの仕事でよく使用されています

私たちが重点を置いている Web パフォーマンス指標は何ですか?

1. ページの読み込み時間

从页面开始加载到页面onload事件触发的时间。一般来说onload触发代表着直接通过HTML引用的CSS，JS，图片资源已经完全加载完毕。

2. 合計ページ読み込み時間

全部页面载入时间指从最初启动浏览开始，直到所有元素都被加载完成后，在2秒后仍然没有网络活动的时间。

0 ～ 2 秒: 最高のユーザー エクスペリエンス、スコア 100

2 ～ 8 秒: ユーザーは 2 番目から許容できる2 秒目からは、

3 を超えるごとに 5 ポイントが減点されます。ユーザーはそれを許容できません。

標準時間 = DNS 解決時間 + 接続作成時間 + SSL 認証時間 + 100 ミリ秒。標準時間より 10 ミリ秒ごとに 1 ポイント減点します。

0 ～ 1 秒: ユーザー エクスペリエンスが最高です。

1 ～ 2 秒: ユーザーは次のことを行うことができます。許容します

2 ～ 3 秒: ユーザーは許容できません

4. 長時間接続を使用します

从开始加载到收到服务器返回数据的第一字节的时间

0 ～ 50 ミリ秒 100 分

50 ～ 500 ミリ秒は正常であり、ユーザー エクスペリエンスは 50 ミリ秒から始まり、10 ミリ秒ごとに減少します

500 ミリ秒を超えると、ユーザーの Web エクスペリエンスに重大な影響を及ぼします 50 ミリ秒から始まり、10 ミリ秒が追加されるごとに 2 分が減算されます

6 . TCP 時間

连接视图展现了页面加载过程中创建的（keepalive）连接，以及通过每个连接所加载的资源。

0 ～ 100 ミリ秒 100 分

100 ～ 500 ミリ秒、通常は 100 ミリ秒から始まり、10 ミリ秒が増加しない場合は 1 分を減算します。ユーザーの Web エクスペリエンスに重大な影響を及ぼします。100 ミリ秒ごとに 1 ポイント減算されます。

7. 総合スコア

进行域名解析所需要的时间

9.

客户端建立连接的时间

他にどのような指標がありますか?

簡単に言えば、Web リクエストの処理には次のステップが含まれます:

(1) クライアントがリクエストを送信します

(2) Web サーバーがリクエストを受信して​​処理します

(3) Webサーバーは DB からデータを取得します。

(4) Web サーバーはユーザーのオブジェクト (ページ) を生成し、ユーザーに返します。リクエストの開始からクライアントに送信される最後のバイトまでの時間を応答時間と呼びます (各リクエスト処理には 3 番目のステップは含まれません)。

1. トランザクション

2. リクエスト応答時間

页面渲染、下载速度、页面流畅度

4. スループット

以上评分的加权计算值=全部页面载入时间评分*0.2+首字节时间评分*0.2+使用了长连接*0.1+DNS时间评分*0.2+TCP时间评分*0.2+HTTP网页评分*0.1

6.tps

7 。クリック数 PV

请求时间定义：所谓的请求时间是指用户从三次握手到最后一次请求发出的这一段时间，这个时间可以用于定位网络问题。网络丢包率定义：当前的网络的丢包情况统计。网络时延定义：当前网络的时延。包括RTTc和RTTs。RTTc用户到探针的传输时延RTTs探针到服务器的传输时延可以关联的其他指标受影响的用户数所谓受影响，即当该业务的某个指标比较差时，有多少个用户受到影响。通过这个指标，可以进而得到具体受到影响的用户是哪些。受影响的站点数即当网络出现问题，或者是服务器出现问题时，有多少个站点受到影响。通过这个指标，可以进而得到具体受到影响的站点是哪些。

8. リソース使用率

事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.

并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。   可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。