问题标签 [lighthouse]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
html - 如何避免 PWA 中的 CORS 问题
我们开始实施 PWA，作为实施的一部分，我从 amazon s3 存储桶中导入 manifest.json。出现以下错误。
无法加载https://abcdefghij.com/static/pwa/Manifest.json:No 'Access-Control-Allow-Origin' header is present on the requested
我在 index.html 文件中编写了以下代码
如果有人帮助，将不胜感激。
google-chrome - Error in Google Chrome Lighthouse's Best Practice audit regarding manifest 'short_name'?
I'm getting an error when using Google Chrome's new auditing features (Lighthouse). I get the following message as a failed audit:
Manfiest's
short_namewill be truncated when displayed on homescreen
They suggest I make short_name less than 12 characters, which it already is.
manifest.json
I'm just trying to figure out if it's something wrong on Lighthouse's end, or is there something incorrect / invalid from the manifest that's failing this audit?
google-chrome - 启动本地路径 chrome 时关闭第一个水龙头
我想关闭第一个水龙头，只留下空白水龙头 这是一张显示我的意思的图片。
这是我的代码
angular - 在 Lighthouse 测试 Angular 应用程序时，我发现性能指标不准确
我正在使用 Angular CLI (1.4.8) 创建的 Angular 应用程序（版本 4.4.6）上运行 Lighthouse 测试（版本 2.7.0）。它是使用 --prod 标志构建的。第一次有意义的绘画时间为 6 秒以上，第一次互动时间为 11 秒以上。与我从新的浏览器窗口秒表页面时看到的相比，这似乎非常高，大致是：第一次绘制的时间为 1-2 秒，第一次交互的时间为 4 秒。
为什么我自己测量的结果与 Lighthouse 报告的结果之间存在如此大的差异？
javascript - 未能提高网站首次加载性能
我正在使用 HTML5、JavaScript 和 React 创建一个网站。我正在使用 Google Chrome Lighthouse 来检查网站首次加载的性能。
这是 Lighthouse 运行时环境：
- 用户代理：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
- 设备仿真 Nexus 5X：已启用
- 网络节流 562.5ms RTT, 1.4Mbps down, 0.7Mbps up: 启用
- CPU Throttling 4x 减速：启用
经过多次迭代和修复，这些是我目前在 Lighthouse 上的得分：
- 性能 57
- 渐进式网络应用 100
- 无障碍 100
- 最佳实践 88
- 搜索引擎优化 100
最佳实践不是 100，因为：
- 我拥有的主机不提供 HTTP/2（如果这真的是一个问题，我可能会改变）
- 我有带有 document.write() 的 Google Ads 脚本（对此无法更改）
我的大问题是性能指标。我有一个超过 3.3 秒的白色空白屏幕，并且在 8.3 秒后完全显示！第一次有意义的绘制为 5,750 毫秒，第一次交互为 6,720 毫秒（与一致交互相同）感知速度指数为 4,228（得分 64），估计输入延迟为 16 毫秒（得分 100）
这是关键链请求：
这是网络概述：
这是我到目前为止所做/尝试过的：
- 使用 react-code-splitting 将起始页面中的所有组件移动到异步加载
- 优化图像以使用新的 J2P、JXR 和 WEBP 格式，并使它们的大小正确，因此浏览器不必调整它们的大小。
- 将 App.js 的内容移动到 index.js 中（在加载之前会并行获取 index.js 和 vendor.js，然后是一个包含所有 css 文件和 app.js 的 js 文件，之后它将并行加载app.js 中使用的组件
- 将一些 css 导入移动到与它们关联的组件中。
- 使用 webpack-bundle-analyzer 尝试查找常用库以及它们是如何拆分的。正如您在以下屏幕截图中看到的那样，我的包中有很多重复的模块，我找不到如何提取以提高效率。（lodash，react-overlays，...）
这是我的 webpack.config.js
我的.babelrc
还有我的 index.js
现在我不知道如何提高加载速度以获得更好的 Lighthouse 分数。任何人都可以发现我不知道的任何事情吗？
在我看来，chunk-manifest-webpack-plugin 似乎没有正常工作，因为它没有提取所有常见模块。其次，index.[hash].js 包包含它不应该包含的文件（例如：utils.js、“actions”文件夹下的文件……这些是我自己的文件，但在我的索引中没有引用它们.js 那么为什么要把它们放在那里呢？
html - Lighthouse 要求我推迟加载 /
我已将样式表推迟到页面底部，并在顶部内联了一些初始 css，但在灯塔上的得分仍然很低。当我检查指针时，它只建议延迟加载 / （见图）
任何人都可以为我理解这一点吗？
lighthouse - 让 Lighthouse 使用自定义模板生成报告
是否可以使用自定义 HTML 模板而不是 Lighthouse 中提供的模板来导出 Lighthouse？
我在想可能有一种类似Basic Custom Audit Recipe的方法。
我在想模板逻辑的代码在这里。
javascript - 将同步代码插入异步
我正在针对大约 50 个站点列表运行灯塔 cli 。我只是在一个.forEach循环中运行它，如果我理解的话，它是阻塞的，也就是同步的。但是，我最终一次性启动了 50 个 Chrome Canary 实例。在我对这些事情的有限理解中，我认为线程是同步启动的，但随后node可以将线程传递给内核并愉快地启动下一个。同样，这只是我对正在发生的事情的随意理解。
我正在使用我从某处抄袭的这个功能：
nextTick我在循环中尝试过：
但这仍然会产生一堆 Chrome 实例。如何在一个灯塔完成时暂停执行？
css - Angular Universal：服务关键 CSS 并延迟非关键 CSS
这基本上是我正在使用的代码，lighthouse 说我的（几乎是空的！）css 包正在延迟我的初始加载。
那么如何在
<head><style>DONT_WANT_TO_WRITE_STUFF_INLINED</style>...</head>
有没有比https://www.npmjs.com/package/critical更好的解决方案或内联编写所有内容？
以及如何延迟主要styles.scss 的加载，直到在浏览器中加载预渲染的通用内容？angular-cli.json 中的服务器应用程序配置不包含stylesor assets，所以我不明白为什么最初加载 styles.scss
jenkins-plugins - 前端性能测试自动化
目前，我们的企业 Web 应用程序（Java、Hibernate、Oracle、HTML/CSS/JavaScript 和内部模板语言）几乎没有进行前端性能测试。
我们最近设置了 Jenkins，并正在慢慢尝试自动化。
我直接知道我们前端性能的主要问题点（没有缩小、压缩、捆绑等......）
应用程序是通过 jenkins 任务每晚构建的。（使用 Maven）我想使用一个工具来识别当前的基线指标，然后让测试每晚运行一次，并在超出基线值时发出警报。
我快速浏览了Lighthouse并注意到它提供了一个 nodejs 模块，用于在命令行上运行，并且可以通过 jenkins 作为 grunt 任务运行。 这篇文章对设置很有用。
有没有人使用这些工具使用这种方法？任何建议的更好的方法？
最初，我们正在寻找应用程序中最受打击的部分的基础知识。（页面加载时间、文件大小、页面上的 http 请求）。
我还可以看到我们使用它来保持网站可访问性的礼貌，因为这对我们来说也很重要。