lighthouse使用_如何使用Lighthouse，Webpack和React可加载组件提高应用程序的性能

lighthouse使用

by Adam Henson

亚当·汉森(Adam Henson)

如何使用Lighthouse，Webpack和React可加载组件提高应用程序的性能 (How to improve performance in your apps with Lighthouse, Webpack, and React Loadable Components)

改善网页性能的现代概念，工具和示例策略的概述 (An overview of modern concepts, tools and example strategies to improve web page performance)

In March of 2018 Google confirmed rumors by announcing the migration of sites for “mobile-first” indexing.

Google在2018年3月宣布将网站迁移为“移动优先”索引，从而证实了谣言。

这是什么意思 (What this Means)

Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used the desktop version of a page’s content when evaluating the relevance of a page to a user’s query. Since the majority of users now access Google via a mobile device, the index will primarily use the mobile version of a page’s content going forward. We aren’t creating a separate mobile-first index. We continue to use only one index.~Prepare for mobile-first indexing

移动优先编制索引意味着Google将主要使用内容的移动版本进行索引和排名。 从历史上看，索引在评估页面与用户查询的相关性时主要使用页面内容的桌面版本。 由于大多数用户现在都通过移动设备访问Google，因此该索引将主要使用该页面内容的移动版本。 我们不会创建单独的移动优先索引。 我们将继续仅使用一个索引。〜准备进行移动优先索引

“Yikes!” — you may be thinking. This is a reasonable reaction for anyone owning a website relying on organic search results for its success. Consider extreme examples of websites that drive millions of dollars a day who’ve come to depend on such rankings. Many of these websites weren’t necessarily built to support mobile devices as the highest priority.

“赞！” -您可能在想。 对于拥有依靠自然搜索结果获得成功的网站的所有人来说，这是一个合理的React。 考虑一些极端的例子，这些网站每天要吸引数百万美元的收入，而这些依赖于这些排名。 这些网站中的许多不一定是要优先支持移动设备的。

对抗表现 (Confronting Performance)

The first step in ensuring optimal performance of a web page on a mobile device is to understand key metrics in modern testing. We can go straight to the source by utilizing Lighthouse, Google’s open-source tool. You can run it in Chrome DevTools, from the command line, or as a Node module.

确保移动设备上的网页具有最佳性能的第一步是了解现代测试中的关键指标。 我们可以利用Google的开放源代码工具Lighthouse来直接寻找源代码。 您可以在Chrome DevTools中，从命令行或作为Node模块运行它。

Lighthouse has a variety of options to allow performance testing under a variety of conditions, specifically notable being device and connection type.

Lighthouse有多种选择，可以在各种条件下进行性能测试，尤其是设备和连接类型。

灯塔指标和计分 (Lighthouse Metrics and Scoring)

In a Lighthouse performance audit, results are provided as a set of metrics with values. The score is a number between 0 and 100 where the higher number is better. Score is calculated by a weighted group of select metrics as explained in the documentation.

在Lighthouse绩效审核中，结果将作为一组带有值的指标来提供。 分数是0到100之间的数字，数字越高越好。 得分由一组加权的选择指标计算得出，如文档中所述。

Load is not a single moment in time — it’s an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as “fast” or “slow”.

负载不是时间紧迫的时刻，而是一种度量标准无法完全捕获的经验。 负载体验中有多个时刻会影响用户将其视为“快速”还是“缓慢”。

~ Paint Timing Spec

〜 油漆时间规格

Not only does each metric capture a characteristic of page load, but each metric can encompass the results of others.

每个度量不仅捕获页面加载的特征，而且每个度量都可以包含其他结果。

改进的机会和解决方案 (Opportunities for Improvement and Solutions)

I’ve identified a few commonly low metrics with fairly straightforward solutions, depending on complexity. “Time to Interactive” is one of the most important.

我已经根据复杂性确定了一些通常比较低的指标，这些指标通常都非常简单。 “ 互动时间 ”是最重要的时间之一。

互动时间 (Time to Interactive)

At the time of this writing, the “Time to Interactive” metric is weighted highest in its influence on the overall performance score.

在撰写本文时，“互动时间”指标对整体绩效得分的影响权重最高。

The Time to Interactive (TTI) metric measures how long it takes a page to become interactive. “Interactive” is defined as the point where:

互动时间(TTI)度量标准衡量页面互动的时间。 “交互”定义为：

The page has displayed useful content, which is measured with First Contentful Paint.

该页面显示了有用的内容，该内容使用First Contentful Paint进行测量。

Event handlers are registered for most visible page elements.

已为大多数可见的页面元素注册了事件处理程序。

The page responds to user interactions within 50 milliseconds.

该页面在50毫秒内响应用户交互。

To improve your TTI score, defer or remove unnecessary JavaScript work that occurs during page load. See Optimize JavaScript Bootup and Reduce JavaScript Payloads with Tree Shaking, and Reduce JavaScript Payloads with Code Splitting.

为了提高您的TTI分数，请推迟或删除页面加载期间发生的不必要JavaScript工作。 请参阅优化JavaScript引导并通过摇树来 减少JavaScript有效负载 ，以及通过代码拆分来减少JavaScript有效负载 。

~Time to Interactive

〜 互动时间

缩短互动时间 (Improving Time to Interactive)

Webpack provides sophisticated customization nowadays to improve optimization. It provides out of the box configuration options to split code and prevent duplication as illustrated in the documentation. By using Webpack Bundle Analyzer, we can visualize the outcome of a “prevent duplication” code splitting approach.

Webpack现在提供了复杂的自定义功能，以改善优化。 它提供了开箱即用的配置选项，用于拆分代码并防止重复，如文档中所示 。 通过使用Webpack Bundle Analyzer ，我们可以可视化“防止重复”代码拆分方法的结果。

Okay, well… could be worse ?! The important part is we separated common code. By doing this alone we relieve work from the main execution thread, provide asset caching potential, and other interesting things as detailed by Addy Osmani and Jeremy Wagner. But wait… there’s more!

好吧，好吧……可能会更糟吗？ 重要的部分是我们分离了通用代码。 仅通过这样做，我们就可以从主执行线程中解放工作，提供潜在的资产缓存能力，以及Addy Osmani和Jeremy Wagner所详述的其他有趣的事物。 但是等等...还有更多！

动态代码分割 (Dynamic Code Splitting)

We talked about one approach above. Another code splitting technique supported by Webpack involves the use of dynamic imports. I accomplished this fairly easily with staggering results by using Loadable Components to handle rendering in my “universal” app. I chose this library in its support of “Server Side Rendering” and documentation of it. It provides a Babel Plugin (which delegates chunks under the hood during build) and a Chunk Extractor — to collect chunks server side and provide script tags on page render. This seems confusing, so enough with the words… let’s role up our sleeves!

我们在上面讨论了一种方法。 Webpack支持的另一种代码拆分技术涉及动态导入的使用。 通过使用可加载组件来处理我的“通用”应用程序中的渲染，我可以轻松获得令人惊讶的结果。 我选择该库是因为它支持“服务器端渲染”及其文档 。 它提供了Babel插件 (在构建过程中在后台委托块)和块提取器 -收集服务器端的块并在页面渲染上提供脚本标签。 这似乎令人困惑，用这样的话就足够了……让我们袖手旁观！

Imagine a page component, defined with a dynamic import.

想象一下用动态导入定义的页面组件。

And to process and delegate Loadable Components during build, we can configure Webpack with the Babel plugin (mentioned above).

为了在构建过程中处理和委派可加载组件，我们可以使用Babel插件(如上所述)配置Webpack。

In our client side render entry, we wrap in Loadable Ready. Loadable Components loads all your scripts asynchronously to ensure optimal performance. All scripts are loaded in parallel, so you have to wait for them to be ready using loadableReady .

在客户端渲染条目中，我们包装了Loadable Ready 。 可加载组件异步加载所有脚本以确保最佳性能。 所有脚本都是并行加载的，因此您必须使用loadableReady等待它们准备就绪。

On server side render, Loadable Components ChunkExtractor provides only the script tags used by initial page load and the rest asynchronously, client side! JS is loaded on-demand, behind the scenes.

在服务器端渲染上，可加载组件ChunkExtractor仅提供初始页面加载所使用的脚本标签，其余部分则异步地提供给客户端！ JS是在后台按需加载的。

Dynamically extracting script and style tags needed by a particular page is quite powerful. I used dynamic imports in all page components and components that uniquely import heavy libraries. What a difference! ?

动态提取特定页面所需的脚本和样式标签非常强大。 我在所有页面组件和唯一导入大量库的组件中使用了动态导入。 有什么不同！ ？

We reduced the main vendor bundle by more than 100kb. The blue squares in the image above represent bundles created with dynamically imported page components. The large violet square in the top middle is a vendor split bundle from one specific component I identified as uniquely importing large libraries.

我们将主要供应商捆绑包减少了100kb以上。 上图中的蓝色方块表示使用动态导入的页面组件创建的包。 顶部中间的大紫罗兰色正方形是来自供应商的拆分捆绑包，来自我确定为唯一导入的大型库的一个特定组件。

好吧，我们实际上做了什么？ (Okay, Did We Actually Do Anything?)

The short answer is — yes!! We can see how JS is loaded by examining the network panel in Chrome Dev Tools. Let’s assume a request to a home page.

简短的答案是-是的！ 我们可以通过检查Chrome开发工具中的网络面板来了解如何加载JS。 让我们假设有一个主页请求。

Okay, wait… it’s all coming back now…

好吧，等等...现在都回来了...

An alternative to large bundles is code-splitting, which is where JavaScript is split into smaller chunks. This enables sending the minimal code required to provide value upfront, improving page-load times. The rest can be loaded on demand.

大包的替代方法是代码拆分，这是将JavaScript拆分为较小的块的地方。 这样就可以发送最少的代码以预先提供价值，从而缩短页面加载时间。 其余可以按需加载。

~ Reduce JavaScript Payloads with Code Splitting

〜 通过代码拆分减少JavaScript有效负载

Aha, we can see this in action here as a user navigates to another route client side. Assume the user navigates to a “dashboard” page from the home page. Dashboard.fc4871b3.js is downloaded on demand!

啊哈，当用户导航到另一条路由客户端时，我们可以在此处看到此操作。 假设用户从主页导航到“仪表盘”页面。 按需下载Dashboard.fc4871b3.js ！

And… Google loves it! With the above changes, I saw a Lighthouse score improvement of more than 10 points. ?

而且…Google喜欢它！ 通过上述更改，我发现Lighthouse得分提高了10分以上。 ？

结论 (Conclusion)

By utilizing a recipe of modern tools and features, we can effectively identify, measure, visualize and address web page performance. This is important in accommodating Google’s mobile-first indexing. Key metrics documented by Google to measure performance, such as “Time to Interactive”, can help us pinpoint opportunities for improvement.

通过利用现代工具和功能的配方，我们可以有效地识别，测量，可视化和解决网页性能。 这对于容纳Google的移动优先索引非常重要。 Google记录的衡量绩效的关键指标(例如“ 互动时间 ”)可以帮助我们确定改进机会。

翻译自: https://www.freecodecamp.org/news/taming-performance-in-todays-web-app-with-lighthouse-webpack-and-react-loadable-components-b2d3fa04e0ab/

lighthouse使用