加载ckpt比加载pb快_您的网站应加载多快？

加载ckpt比加载pb快

Web性能是一种分布 (Web performance is a distribution)

Go ask Google. You’ll find a bunch of articles telling you that 2–5 seconds does the trick. But what makes 2–5 seconds the prescribed range? Your gut tells you that the answer has to be more complicated than that.

去问问谷歌。 您会发现很多文章告诉您2到5秒钟就能解决问题。 但是什么使2-5秒成为规定范围呢？ 您的直觉告诉您答案必须比这更复杂。

Congratulations. You’re right. The answer is much more nuanced than any time range can answer. The problem lies in the question itself.

恭喜你 你是对的。 答案比任何时间范围内的答案都细微得多。 问题出在问题本身上。

并非所有网站和访问者都一样 (Not all sites and visitors are the same)

This question has a flaw. It assumes there’s a standard for different circumstances. Websites are different. Users visit sites under different conditions.

这个问题有一个缺陷。 假设有针对不同情况的标准。 网站是不同的。 用户在不同条件下访问站点。

A static blog is different than a graphics editor and 4G is a heck of a lot faster than 2G. A static blog may need no JavaScript whatsoever whereas a graphics editor uses quite a lot of it. A 4G visitor may deal with only 50ms of latency and a 2G user could suffer through an entire second per round trip.

静态博客不同于图形编辑器，而4G比2G快得多。 静态博客可能根本不需要JavaScript，而图形编辑器会使用很多JavaScript。 4G访问者可能只需要处理50毫秒的延迟，而2G用户每次往返可能会经历整整一秒钟的时间。

The table above describes data rates that are achieved in ideal conditions. Sitting in an underground parking garage is not ideal but it happens to all of us. This means the network conditions that users come to your site on are variable.

上表描述了理想条件下达到的数据速率。 坐在地下车库中并不是理想选择，但对我们所有人来说都是这样。 这意味着用户访问您的站点的网络条件是可变的。

网络条件的可变性 (Variability of network conditions)

Network conditions when tweaked result in dramatically different page load times. Let’s say we have two users who are going to visit my personal website (davidea.st) on a mobile network. It’s just a static site with no render blocking JavaScript. The index.html document is only 2.3kb and the CSS is 1.8kb. The first user visits with 400kib of bandwidth (2G speeds) but 100ms of latency (4G speeds). The second visitor also has 400kib of bandwidth, but 1000ms of latency (both 2G speeds).

调整时的网络状况导致页面加载时间截然不同。 假设我们有两个用户要通过移动网络访问我的个人网站( davidea.st )。 它只是一个静态站点，没有渲染阻止JavaScript。 index.html文件只有2.3kb，CSS是1.8kb。 第一个用户以400kib的带宽(2G速度)但100ms的延迟(4G速度)访问。 第二位访问者还具有400kib的带宽，但有1000ms的延迟(均为2G速度)。

It’s the same exact site, but tweaking the latency only (which is easy when you’re in a parking garage) increases the load of the index.html by ten times. So if latency alone can drastically change the page load of the same site, does it make sense to ask “How fast should my site load?”

这是完全相同的网站，但是仅调整延迟(当您在停车场时很容易)将index.html的负载增加了十倍。 因此，如果仅延迟就可以彻底改变同一站点的页面负载，问“我的站点应该加载多快？”是否有意义？

You the developer can’t control what network a user comes on. Which means that web performance isn’t about knowing a solid number that your site loads in. It’s knowing that your page load is a spectrum of different times under different conditions. The only way to know this is to measure.

您，开发人员无法控制用户进入哪个网络。 这意味着Web性能并不是要知道您的网站要加载的固定数字。而是要知道您的页面加载是在不同条件下的不同时间段。 知道这一点的唯一方法是测量。

RUM：衡量现实世界的表现 (RUM: Measuring real world performance)

That’s exactly what you get with RUM monitoring. RUM or Real User Metrics, collects important performance metrics from page loads and beacons them to a server where you the user gets to see the data in a dashboard.

这正是通过RUM监视得到的。 RUM或“真实用户指标”，从页面加载中收集重要的性能指标并将其信标到服务器，您可以从中查看用户在仪表板上的数据。

RUM providers come in different shapes and sizes, but for the sake of this article I’m going to use Firebase Performance Monitoring. Firebase is like a third child to me and they also pay my salary.

RUM提供程序的形状和大小不同，但是出于本文的目的，我将使用Firebase Performance Monitoring。 Firebase对我来说就像第三个孩子，他们也支付我的薪水。

Web性能是一种分布 (Web performance is a distribution)

Imagine if you recorded the first paint times from users who visited your site. Then you took their times and tallied them in a bar chart. It would look something like this.

想象一下，如果您记录了访问您网站的用户的首次绘画时间。 然后，您将他们的时间记录在条形图中。 它看起来像这样。

However, this isn’t a totally accurate visual. Not all users will load the site in the same exact time buckets. The site will load in 1.5 seconds for one person and 1.65 seconds for the next. So instead of a bar chart, we can use an area chart.

但是，这并不是完全准确的视觉效果。 并非所有用户都将在相同的确切时间段内加载网站。 一个人的网站加载时间为1.5秒，下一个人的网站加载时间为1.65秒。 因此，我们可以使用面积图代替条形图。

This area chart visualizes the distribution of load times. It helps use see the spectrum of load times and what is most common. It represents all the percentiles of load times.

该区域图显示了加载时间的分布。 它可以帮助您了解负载时间的范围以及最常见的情况。 它代表所有加载时间的百分位。

In Firebase Performance Monitoring we provide an entire dashboard of area charts for different metrics.

在Firebase Performance Monitoring中，我们为不同指标提供了一个完整的区域图仪表板。

The x-axis represents a larger array of load times. The y-axis represents the percentiles. What is most interesting about these percentiles is how they are shaped.

x轴代表更大的加载时间数组。 y轴表示百分位。 这些百分位数最有趣的是它们的形状。

尾巴 (The tail)

The chart begins to curve sharply up and then slowly curves down forming a tail. This tells us that most users have load times between 1.5 and 3.5 seconds, which can be good. However, don’t let that bump fool you. That tail contains all the problems.

图表开始急剧上升，然后缓慢下降，形成一条尾巴。 这告诉我们，大多数用户的加载时间在1.5到3.5秒之间，这可能很好。 但是，不要让颠簸骗了你。 那尾巴包含所有问题。

The tail represents your users who encounter the longest load times. The longer the tail, the larger the volatility. This means your site’s performance becomes hard to understand. Some users load quickly, some crawl their way in. So while we need to fight to shorten the tail, we also need to understand what it represents.

尾部表示遇到最长加载时间的用户。 尾巴越长，波动性越大。 这意味着您的网站性能变得难以理解。 有些用户会很快加载，有些会爬行。因此，尽管我们需要努力缩短尾巴，但也需要了解尾巴代表什么。

您的网站何时可用？ (When is your site usable?)

When most people say “page load” they are referring to when the site is actually usable. This is a bit misleading, because the site doesn’t have to be fully loaded.

当大多数人说“页面加载”时，他们指的是该站点实际可用的时间。 这有点误导，因为该站点不必完全加载。

Think about a live streaming blog covering a big event. You visit and see over time updates magically appear on the screen. At what point is this page “loaded”? Was it when the first set of updates appeared? Was it when the header loaded?

考虑一个涵盖重大事件的实时流媒体博客。 您访问时发现，随着时间的推移，更新神奇地出现在屏幕上。 该页面什么时候“加载”？ 是第一套更新出现时？ 标头加载时是吗？

This isn’t a debate anyone wants to have. Instead we break page load down into more specific metrics.

这不是任何人都想进行的辩论。 相反，我们将页面加载细分为更具体的指标。

“页面加载”的指标 (The metrics of “page load”)

Navigation is when the user initiates the loading of the site. This could be from typing the URL and hitting enter or clicking a link. No pixels have been painted. The browser is fetching assets over the network.

导航是当用户启动网站加载时。 这可能是通过键入URL并单击Enter或单击链接。 没有画像素。 浏览器正在通过网络获取资产。

First Paint (FP) is one of the most common metrics referenced. It simply asks: when did a non-trivial amount of pixels appear on the screen?

First Paint(FP)是引用的最常见指标之一。 它只是问：屏幕上何时出现平凡的像素？

Understanding when pixels start to appear is important because you learn how fast users begin to see something. In some cases this feedback helps a user know that the site is loading and they should hold on.

了解像素何时开始出现很重要，因为您可以了解用户开始看到事物的速度。 在某些情况下，此反馈可以帮助用户知道该网站正在加载，因此应该继续。

First Paint can accurately represent “page load” if you are building a traditional server rendered site (different than a server-side rendering JavaScript app). This is because all the HTML and CSS are ready to go without any render blocking JavaScript. The app looks and feels usable. But this can be different for JavaScript dependent sites.

如果您要构建传统的服务器呈现站点(与服务器端呈现JavaScript应用程序不同)，则First Paint可以准确地表示“页面负载”。 这是因为所有HTML和CSS都可以使用，而没有任何渲染阻止JavaScript。 该应用程序看起来和感觉可用。 但这对于依赖JavaScript的网站可能有所不同。

In the case of a lot of Single Page Applications (SPAs), First Paint happens for static elements like headers and footers. The rest of the app is still booting up, waiting for JavaScript to load and execute. The user may see something, but the app is not yet usable.

在很多单页应用程序(SPA)的情况下，First Paint会用于静态元素，例如页眉和页脚。 该应用程序的其余部分仍在启动，等待JavaScript加载和执行。 用户可能会看到一些东西，但该应用程序尚未可用。

First Contentful Paint (FCP) cares about when… well… content appears on the page. This is more than pixels rendered to the screen. If your site loads quickly, FCP and FP tend to fire at the same time. But in cases where you block text rendering for web fonts or when content requires JavaScript to load and execute, FCP can stagger behind FP.

First Contentful Paint(FCP)关心何时……好……内容出现在页面上。 这不仅仅是渲染到屏幕上的像素。 如果您的网站加载速度很快，则FCP和FP倾向于同时启动。 但是，如果您阻止了Web字体的文本呈现，或者当内容需要JavaScript来加载和执行时，FCP可能会落后于FP。

FCP and FP can also be the same even when your site loads slow. This is common is large JavaScript applications that don’t render much or any static HTML. In these circumstances, when the JavaScript finally loads, executes, and renders both FP and FCP tend to fire at the same time.

即使您的网站加载速度缓慢，FCP和FP也可以相同。 这是大型JavaScript应用程序的常见现象，这些应用程序无法渲染太多或任何静态HTML。 在这些情况下，当JavaScript最终加载，执行并渲染FP和FCP时，往往会同时触发它们。

What domInteractve indicates is that the browser has constructed the DOM tree from the static HTML. The browser then starts loading other resources like stylesheets, images, and JavaScript. This is useful to know when the DOM tree has been constructed and when the browser is going to start loading everything else. When do we know that important resources like JavaScript and stylesheets have loaded? That’s what domContentLoadedEventEnd is for. When domContentLoadedEventEnd fires you know that there are no longer any stylesheets blocking any JavaScript execution.

domInteractve表示浏览器已经从静态HTML构造了DOM树。 然后，浏览器开始加载其他资源，例如样式表，图像和JavaScript。 这对于了解何时构造DOM树以及何时浏览器将开始加载其他所有内容很有用。 我们何时知道重要的资源(如JavaScript和样式表)已加载？ 这就是domContentLoadedEventEnd目的。 当domContentLoadedEventEnd触发时，您会知道不再有任何样式表阻止任何JavaScript执行。

These metrics are useful together because domInteractive tells you when the stylesheet loading starts and domContentLoadedEventEnd tells you when it ends.

这些指标非常有用，因为domInteractive告诉您何时开始加载样式表，而domContentLoadedEventEnd告诉您何时结束。

Load Event End isn’t always the most useful metric, but sometimes it can tell you quite a bit. The loadEventEnd event will fire when the document’s load has completed. This means the event fires when all resources in the DOM tree have been loaded. All the linked stylesheets, scripts, and images. Resources like images can slow this metric down. If you accidentally upload a 100MB GIF to a site, you’ll see some pretty slow loadEventEnd times. I say this from experience as well.

加载事件结束并不总是最有用的指标，但是有时它可以告诉您很多信息。 文档的加载完成后，将触发loadEventEnd事件。 这意味着当DOM树中的所有资源都已加载时将触发该事件。 所有链接的样式表，脚本和图像。 图片等资源可能会降低此指标的速度。 如果您不小心将100MB GIF上传到站点，则会看到一些相当慢的loadEventEnd时间。 我也从经验上讲。

This metric helps you understand generally how long it takes for your document’s assets to load. Your site can be useable long before this metric fires. Use this as a guide to understanding if you have any heavy assets on the page.

该指标可帮助您大致了解文档资产的加载时间。 您的网站在此指标触发之前就可以使用了。 使用此指南来了解页面上是否有大量资产。

First Input Delay (FID) measures how long it takes for the first user interaction to trigger. You’ve probably been stuck on a page that looks that it’s ready to use, but it’s frozen. The site just doesn’t work no matter how many angry swipes or clicks you throw it. First Input Delay exists to measure this kind of problem.

首次输入延迟(FID)衡量首次用户交互触发所花费的时间。 您可能被困在看起来可以使用的页面上，但是页面已冻结。 无论您扔掉它多少次愤怒的轻击或点击，该网站都无法正常工作。 存在“第一输入延迟”来测量此类问题。

If you have a static blog, it may not be as useful because FID measures when users can interact with your site. This is usually triggered after event listeners fire. Now for heavy JavaScript apps, this metric could be critical. JavaScript heavy apps have to load, parse, and execute before they can run which can push back the first interactive moments of a site.

如果您有静态博客，则它可能没有用，因为FID可以衡量用户何时可以与您的网站进行交互。 这通常是在事件监听器触发后触发的。 现在，对于重型JavaScript应用程序，此指标可能很关键。 JavaScript繁重的应用程序必须先加载，解析和执行，然后才能运行，这可能会推迟网站的最初交互时刻。

网络生命 (Web Vitals)

If you are a savvy performance minded developer (or if you follow the great Addy Osmani) you’ve probably heard of the Web Vitals initiative.

如果您是一个精通性能的开发人员(或者如果您遵循出色的Addy Osmani )，那么您可能听说过Web Vitals计划 。

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

Web Vitals是Google的一项举措，旨在为质量信号提供统一的指导，这对于在网络上提供出色的用户体验至关重要。

The goal is to improve loading performance, interactivity, and stability. The core metrics that make up Web Vitals are:

目的是提高加载性能，交互性和稳定性。 构成Web Vitals的核心指标是：

• Largest Contentful Paint (LCP) (Measures loading performance)
  最大含量的涂料(LCP)(衡量装载性能)
• First Input Delay (Measures interactivity)
  首次输入延迟(测量交互性)
• Cumulative Layout Shift (CLS) (Measures stability)
  累积版式偏移(CLS)(衡量稳定性)

I’m not going to go over each one in detail (because we’ve already covered a lot of metrics) but you can check the descriptions at web.dev/vitals. Each metric is retrieved through a library provided by the Web team at Google.

我不会详细介绍每个指标(因为我们已经介绍了很多指标)，但是您可以在web.dev/vitals上查看说明。 每个指标都是通过Google网络小组提供的库检索的。

import { getCLS, getFID, getLCP } from 'web-vitals';getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Firebase Performance Monitoring only supports First Input Delay as a first class metric. Until the others are automatically collected you can use Custom Traces to log Largest Contentful Paint and Cumulative Layout Shift.

Firebase性能监控仅支持将“第一输入延迟”作为一流指标。 在自动收集其他内容之前，您可以使用“自定义跟踪”记录最大的内容丰富的绘画和累积布局偏移。

指标过载 (Metrics overload)

Web performance is full of metrics and not all of them may be useful for your site and situation. I recommend reading through each and seeing how it works for your type of site. Don’t worry about tracking each one. Learn which ones work best for your site.

Web性能充满了指标，但并非所有指标都对您的网站和情况有用。 我建议您通读每篇文章，并查看其如何适用于您的网站类型。 不必担心跟踪每个人。 了解哪种方法最适合您的网站。

那么，您的网站应该加载多快？ (So, how fast should your site load?)

What do we do with these metrics? Now that you know these metrics, we can use them to understand what’s happening on our sites and to ask better questions.

我们如何处理这些指标？ 现在您已经了解了这些指标，我们可以使用它们来了解我们网站上发生的情况并提出更好的问题 。

Here’s a specific question to ask: “When does our content first appear for 3G users?” Tracking these metrics in the wild allows you to see what kind of users are being affected and what the trend is over time.

这里有一个具体的问题要问： “我们的内容何时首次出现在3G用户身上？” 随意跟踪这些指标可以使您了解受影响的用户类型以及随着时间的推移趋势如何。

With Firebase Performance Monitoring you can drill into metrics, like First Contentful Paint, to see what dimensions affect the metric. In this case we can split it out by Effective Connection Type (network speed).

借助Firebase Performance Monitoring，您可以深入了解指标(例如First Contentful Paint)，以查看哪些维度会影响指标。 在这种情况下，我们可以按有效连接类型 (网络速度)将其拆分。

The dashboard shows that most users come on at least a 4G or above connection. But 5.88% of users come on 3G speeds and load in 2.24 seconds. And that is a lot better than asking, “How fast should my site load?”

仪表板显示大多数用户至少使用4G或更高的连接。 但是5.88％的用户使用3G速度并在2.24秒内加载。 这比问“我的网站应该加载多快？”要好得多。

开始测量 (Start measuring)

Hopefully you know a bit more about page load than you did before you started this article. If there’s one piece of advice you can take away, it’s start measuring.

希望您比开始本文之前对页面加载有所了解。 如果您可以采纳一条建议，那么它就会开始评估。

Check out the Firebase docs to get started with Firebase Performance Monitoring. It’s just a few lines of code. Measuring allows you to ask better questions and get better answers. And always remember, that page load isn’t a finite number. Web performance itself is a distribution.

查看Firebase文档，开始使用Firebase Performance Monitoring。 只是几行代码。 测量可以让您提出更好的问题并获得更好的答案。 永远记住，页面加载不是一个有限的数字。 Web性能本身就是一种分布。

资源资源 (Resources)

翻译自: https://medium.com/firebase-developers/how-fast-should-your-site-load-cfb14be48e8b

加载ckpt比加载pb快