看起来Lighthouse 6引入了一些新的指标，并且从v5中删除了一些其他指标，因此分数肯定有可能发生变化。 本文介绍了已更改的内容：

https://web.dev/lighthouse-whats-new-6.0/

最后还有一个指向分数计算器的链接，该链接对于分解分数并了解哪些因素贡献最大是非常有用的。

https://googlechrome.github.io/lighthouse/scorecalc

我的印象是，v6中更加关注主线程交互性，因此，如果您的站点包含大型JS捆绑包，那就可能是一个重要因素。

是的， @ shanekenney ，我知道，但是除了删除网站的某些部分以了解导致该问题的原因之外，我真的不知道如何减少它

您还看到对gaysbyjs和theme-ui网站的影响吗？ 我很好奇/很想知道他们可能正在考虑他们网站上的哪些优化措施，或者是否发现了某些特定原因

这个问题很棒，因此我们可以讨论Lighthouse / PageSpeed洞察力的总体得分以及我们在v6中看到的可能的回归。

@kuworking值得一提的是，lighthouse-metrics.com似乎使用_“ Emulated Nexus 5X” _（用于5.6）和_“ Emulated Moto G4” __（用于6.0），这也可能给比较添加一些噪音。

这个超过922个网站的基准在v5中声称Gatsby网站的平均性能得分为75 。 我将尝试使用托管解决方案进行快速查看，以防止本地网络成为另一个可变性因素。

当前（使用Lighthouse v5.6 / PageSpeed Insights）

PSI在“快速3G”的Moto G4上运行。 资源

使用Gatsby构建的某些“标记”网站在PageSpeed Insights上的效果并不理想（我认为仍在使用Lighthouse v5.6 –每次运行均受标准可变性的影响，可能运行3倍或5倍，取平均值会得出

• gatsbyjs.org（移动72/100，TTI 9s）来源
• reactjs.org（Mobile 62/100，TTI 9.5s）来源
• gatsbyjs.com（移动77/100，TTI 6.6s）来源

但是，其他一些网站（和大多数入门网站）在PageSpeed Insights上的表现非常出色：

• store.gatsbyjs.org（移动99/100，TTI 2.5秒）来源
• thirdandgrove.com（移动91/100，TTI 4.0s）来源

平均TTI引人注目-尽管v6将TTI的整体权重从33％更改为15％并降低了First CPU Idle，但它确实添加了25％的权重的TBT，这可能可以解释分数的总体下降，原因仅在于整体JS解析和执行。

Lighthouse v6（使用WebPageTest.org ）

• 这在_Moto G（第4代），Moto G4-Chrome_上运行了WPT，连接速度为_3G快速（1.6mbps / 768kbps 150ms RTT）_。 在PSI更新其基础灯塔版本之前，这似乎与设备/网络非常接近。
• 确保检查_Chromium_下的_Capture Lighthouse Report_。 我已禁用重复视图，以将范围保持在首次访问者，页面的首次加载上。

这是结果，您可以通过单击编号查看灯塔报告。 我正在从该报告中提取值。

• gatsbyjs.org（72-> 67/100，TTI 7.5s，TBT 2150ms）来源
• reactjs.org（62-> 66/100，TTI 7.8s，TBT 3520ms）来源
• gatsbyjs.com（77-> 66/100，TTI 8.4s，TBT 2440ms）来源

但是，请注意以下两个站点上的回归：

• store.gatsbyjs.org（99- > 54/100 ，TTI 6.8s，TBT 1300ms）来源
• thirdandgrove.com（91- > 63/100 ，TTI 14s !, TBT 1330ms）来源

我有一些未解决的问题。

1. 是通过JS解析+执行来解释总体TTI（和TBT），还是存在其他损害交互性的因素？
2. 如果是这样，我们可以更积极的（无论是在盖茨比默认情况下，比如像最新的变化使颗粒块，或在一些实验性标志）构建块，以_only_送什么，首先需要的负荷（即防止APP- [散列]时.js多余）？ 这也可能只是简单地记录了在更多指导下扩展webpack配置的播放方式。
3. 诸如Module / nomodule之类的模式部分补液？
4. 这可能是迈向高分的第二步，但是由于FMP不再是一个因素，因此在LCP上gatsby-image LQIP是对LCP有所帮助还是有害？ 上面运行的store.gatsby.org的LCP为4.7秒！

（我仅以上面的链接为例，如果有人希望删除某个链接，我可以很高兴地编辑邮件）

我的网站（https://matthewmiller.dev/）似乎已经变好了（〜92到〜95），但是一些新测试揭示了一些可能需要改进的地方。

例如，不必要的JavaScript测试，
（第一列是大小，第二列是不必要的数量）

我认为这是由于此处包含其他页面所需的项目所致，因此使用诸如loadable-components之类的内容可能会有所帮助。

对我来说，在理解Largest Contentful Paint遇到了很大的困难，即我在不知道为什么的情况下获得了非常大的值，并且看到报告中的值之间存在差异（例如7.4 s和LCP Performance - ViewTrace LCP标签中显示的Performance ViewTrace标签（〜800毫秒）

我可以看到类似的东西似乎在启动器https://parmsang.github.io/gatsby-starter-ecommerce/中发生了

作为一项更新– PageSpeed Insights似乎已软启动了该更新以运行Lighthouse v6（可能不是在所有地区中）。

链接到测试https://gatsbyjs.org/ 。 当前获得的结果从低60s到80s中期不等，主要取决于TBT和TTI的值。

@ kuworking ，Lighthouse v6识别gatsby-image可能存在问题。

根据webdev

对于已根据其固有尺寸调整大小的图像元素，报告的尺寸为可见尺寸或固有尺寸，以较小者为准。

就我而言，我认为Lighthouse不尊重视图大小。

这是有问题的图像

这可能是因为固有尺寸为3000像素，因此对我来说是13s LCP。

@ daydream05我也有类似的理论和发现，因此我在没有图像的情况下测试了我的页面，但仍然有一个疯狂的较长LCP（10-12秒）。 我的项目正在进行很多工作，因此它也可能是其他变量，但是我很好奇您是否测试过带有文本内容且还没有图像的页面。

从100下降到79〜https : //dougsilkstone.com/。 删除Google跟踪代码管理器（和Google Analytics（分析））时，跳转到90。

我会在测试时报告更多发现。

编辑：从gatsby-plugin-web-font-loader删除Typekit加载的字体时，命中100（也使用preload-fonts缓存）。

GTM总体上影响了我的项目，但是当我将其删除时，变化并不那么剧烈（LH6之后，sub 50s得分最高5-10分）。 我仍然需要做更多的测试，但只想把它扔出去。

@Jimmydalecleveland有趣！ 我也有另一个站点，在屏幕上我只是发短信，并且将英雄文本归咎于LCP。 LCP仅考虑了所见即所得，这没有任何意义。 文本怎么可能成为一个大问题。

@dougwithseismic我也使用typekit，它是灯塔得分较低的罪魁祸首之一。 我希望有一种修复Typekit的方法，因为它们不支持字体显示

我认为Lighthouse v6在JS框架上确实很难，因为在它们如何改变分数权重方面。 （更多地关注阻塞时间）并且由于补液和其他原因，Gatsby网站的脚本评估/主线程得分历史上较低。

@dougwithseismic如何在不使用样式表的情况下链接typekit字体？

我也有类似的经历，在灯塔5.7.1上，我的表现得分约为91，但是在灯塔6上，我的表现得分急剧下降至约60。

从100下降到79〜https : //dougsilkstone.com/。 删除Google跟踪代码管理器（和Google Analytics（分析））时，跳转到90。

我会在测试时报告更多发现。

编辑：从gatsby-plugin-web-font-loader删除Typekit加载的字体时，命中100（也使用preload-fonts缓存）。

我什至没有安装这些插件，但是我的手机得分从90+下降到60〜70+

同样在这里。 在多个站点上从90欧元大量下降到60欧元。

+1下降约30+点

有人在解决这个问题吗？ 如果Gatsby不能立即提供更好的成绩，那么在Next上使用Gatsby似乎毫无意义。

有人在解决这个问题吗？ 如果Gatsby不能立即提供更好的成绩，那么在Next上使用Gatsby似乎毫无意义。

您有下一个号码吗？

我想知道这些分数是否是快速网站的新常态（不是静态的，不含JS的，也可能不含图像的）

您有下一个号码吗？

https://nextjs.org/的得分为85分，其中最大的满意油漆（3.8）和第一满意油漆（2.8）都是主要违规者。 它还有很多“未使用的JS”。 这与Lighthouse 5.7.1中的〜95相比有所下降。 它“仅”下降了约10点，而盖茨比网站似乎损失了两倍。

我对这个世界很陌生，但是当我的gatsby网站在npm的6.0.0灯塔上进行测试时损失了大约25点后，我正在关注这个问题。 有趣的是，如果我使用的是Pagespeed见解，而不是npm lighthouse，那么我的网站可以追溯到99左右。 而gatsbyjs.org的Pagespeed洞察力约为70，而npm lighthouse约为84。 我猜可能是某个地方有一些调整。 他们都收到“未使用的JS”警告

有人在解决这个问题吗？ 如果Gatsby不能立即提供更好的成绩，那么在Next上使用Gatsby似乎毫无意义。

您有下一个号码吗？
我想知道这些分数是否是快速网站的新常态（不是静态的，不含JS的，也可能不含图像的）

Next.js网站-> https://masteringnextjs.com/ 77手机评分。 很多“未使用的JS”。

我在lighthouse-metrics上看到了更好的分数https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

但是我也没有看到图像，以我的经验，图像似乎具有很高的影响力（也是合法的IMO）

但是，gatsbyjs.org都没有图像，并且其得分（相对）很差https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff （与@cbdp示例相比）

让我们看看盖茨比开发者对此有何看法

进行一些调整后，网站恢复了最高分。

在我看来，就像Google将目标职位移至更多情况
对性能要求严格-特别是FCP。

我们的网站无论如何都不会变慢，而且只是以不同的方式进行判断
标准。 我会帮忙这个✌️

在2020年6月9日星期二18:48 kuworking上， notifications @github.com写道：

有人在解决这个问题吗？ 使用Gatsby似乎毫无意义
如果无法立即提供更好的成绩，则接下来。

您有下一个号码吗？
我想知道这些分数是否是快速网站的新常态（
不是静态的，不含JS的，也可能不含图像的）

Next.js网站-> https://masteringnextjs.com/ 77手机评分。 很多
“未使用的JS”。

我发现灯塔指标得分更高
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

但是我也看不到图像，根据我的经验，图像似乎
产生很大（和合法的IMO）影响

但是，gatsbyjs.org都没有图像，并且其得分（相对）很差
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
（与@cbdp https://github.com/cbdp示例相比）

让我们看看盖茨比开发者对此有何看法

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ，
或退订
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
。

只是想抛弃这个有用的计算器，以比较v6和v5的结果： https :

即使通过PageSpeed Insights使用它，灯塔分数通常也会有很大差异。 例如，对于https://www.gatsbyjs.org/，我在运行5次后获得了从64到88的移动性能。 因此，为了追踪该问题，计算器可能对于查看同一次运行中不同权重的后果很有用（注意：由于指标略有不同，因此必须使用以前的测量值来假设某些值，例如FMP）。

PS：在这里，我比较了PageSpeed Insights对gatsbyjs.org的两次运行：
运行1-v6：67-v5：85
运行2-v6：78-v5：87
最大的影响是由新指标“总阻止时间”造成的，该指标在两次运行中均低于70分，权重也为25％。

是的，要添加到@Pyrax中：在Lighthouse v6中，LCP（最大满足要求的涂料）和TBT分别占25％ 。 因此，我们集中精力解决这些问题。 我们找到：

LCP

• 删除任何可能在加载时触发的动画（例如cookie💩横幅）。
• 切换到gatsby-img的tracedSVG似乎有所帮助，因为大多数页面上都有大英雄图像。 （不知道为什么会这样，未经进一步调查。UX也有所改进。）

技术性贸易壁垒

• 从长远来看，从长远来看，来自盖茨比（Gatsby）捆绑销售的Unused JS似乎是最大的骗局（备份了web.dev的文档）。 页面级的树状摇晃肯定可以在这里得到改善吗？

最近的Lighthouse更新似乎已经使每个人的性能得分搞砸了，包括他们自己的：

我唯一的一个尚未真正消失的盖茨比网站是一个基本上只有一个页面并且像99％的html的网站。 但是，即使是那一下降约5-10点。

我看到的却是大多数人的反面，也就是说，Chrome浏览器中的Lighthouse仍然为我的网站显示出不错的分数，但是当在PageSpeed Insights上运行时，perf得分下降了20-30点...也许是我的Chrome Lighthouse版本在后面？ Chrome是最新的，不确定如何检查内置的Lighthouse版本...

最近的Lighthouse更新似乎已经使每个人的性能得分搞砸了，包括他们自己的：

我唯一的一个尚未真正消失的盖茨比网站是一个基本上只有一个页面并且像99％的html的网站。 但是，即使是那一下降约5-10点。

我看到的却是大多数人的反面，也就是说，Chrome浏览器中的Lighthouse仍然为我的网站显示出不错的分数，但是当在PageSpeed Insights上运行时，perf得分下降了20-30点...也许是我的Chrome Lighthouse版本在后面？ Chrome是最新的，不确定如何检查内置的Lighthouse版本...

灯塔版本显示在审核的底部。

@dylanblokhuis啊，是的。 我使用的是5.7.1，Chrome浏览器中尚未提供v6吗？

@dylanblokhuis啊，是的。 我使用的是5.7.1，Chrome浏览器中尚未提供v6吗？

它不是。 仍然没有。 如果您想要最新的版本，可以从npm安装它，然后运行lighthouse https://yoursite.com --view然后以与Chrome审核相同的格式获得分数：）

对于在分数上大受好评的其他人，＃24866也可能是相关的。 Gatsby处理分块的方式似乎已经发生了相当重大的变化。 尽管更改确实看起来很有意义，但至少对我们而言，此更改导致分布在各个块中的代码集中在commons和app块中。 意味着更大的js加载/解析。

这里最相关的是这些指标将很快开始影响Page Rank。

我已经剔除了所有第三方请求（标签管理器/ Typekit / Pixel / Analytics / ReCaptcha），但这只会带来相对较小的得分提升，因此还有其他作用。

此外，对于希望在本地运行Lighthouse 6的任何人，Chrome Canary现在都可以使用它，并计划在7月发布到Chrome。

首先：我与正在处理web.dev的Google工程师取得联系，并询问了有关此问题。 不知道这是否会导致更多的解释，但他们似乎打算提供帮助。 当我设法与他们聊天时，我会跟进。

我的成绩从94-99上升到40-55。 😢

我的网站上最大的Contentful Paint主要适用于具有大图像的页面。 出于某种原因，这意味着加载图像需要大约14秒钟的时间。

如果您打开任何最小的Gatsby入门站点，则任何带有图像的页面似乎都不会超过70秒。

这是我看到的很多图像的前两个入门：

ghost.gatsby.org ：

gcn.netlify.app ：

但是，盖茨比（Gatsby）入门博客的性能为98（当然，这是一个非常小的页面，只包含一些文本）：

gatsbyjs.com ：

在Chrome中将旧分数与新分数进行比较

您仍然可以在不使用CLI的情况下比较新旧Lighthouse方法的得分。 我发现查看已更改的内容很有用。

查看旧的灯塔测试

要查看旧的Lighthouse得分，请从您的chrome开发人员工具（而不是浏览器工具栏）运行Lighthouse chrome扩展程序。

查看新的Lighthouse测试

点击您的Chrome扩展程序栏中的图标。

我的页面改变

这是我在同一页面上得到的两个分数：

旧灯塔（通过Chrome开发工具）

新灯塔（通过地址栏上的Chrome扩展程序）

♂‍♂️

@nandorojo我对图像的印象是，仿真是通过非常慢的连接完成的，因此图像的渲染时间很长

由于并非总是可以选择删除图像，因此这70分数可能是此类页面的正常分数

而且，延迟加载以使用户可以更快地开始其交互的选项似乎并不能解决问题（就我而言）

嘿，很抱歉回答迟了。 我从事过Lighthouse的工作，我会尽力解释。

Chrome开发人员已经发布了“ Web Vitals”，这是健康网站的基本指标。 它包含许多指标，但核心指标是最大内容绘画（LCP） ，首次输入延迟（FID）和累积布局偏移（CLS） 。 对于诸如Lighthouse FID之类的工具，总交换

Lighthouse v6也考虑了这些指标，并且已经发生了变化。 这并不意味着盖茨比很慢。 可能需要进行一些不同的优化。

事情就是这样改变的：

如果您想了解有关LCP的更多信息，请查看https://www.youtube.com/watch?v=diAc65p15ag。

因此，让我们谈谈盖茨比。 盖茨比（Gatsby）本身仍然相当快，我们正在进一步改进它。 我们正在创建新的API，以便页面构建器（例如MDX，Contentful的富文本格式）也可以优化捆绑包。 通过优化LCP，可以做很多事情。 确保在使用字体和图像时，它们不会延迟加载并尽快加载。 这些资产应从与您的站点相同的来源加载，而不应从CDN加载。

可悲的是，TBT是一个很难解决的问题，这也是React无法优化的。 如果您想删除TBT，则应签出preact 。 Preact与React具有相同的API，但JavaScript占用空间较小。 他们做的事情不同，但是React组件是兼容的。 您可以通过运行gatsby recipes preact安装它。

在分析gatsbyjs.com和gatsbyjs.org时，我注意到的一些事情是，我们应该比现在延迟一些时间加载Google Analytics（分析）等，以确保它不会成为TBT的一部分。

如果我们通过推迟分析和GTM来查看.com并确保字体加载速度更快，我们已经可以看到+17的改进。 如果将预言添加到混合中，我们将看到+6。

我们可以对.org做同样的事情，我们的得分从63开始。通过对LCP和TBT的一些优化，我们可以达到75。

我不确定该如何处理。 我觉得我们可以关闭它，因为我们在这里无能为力。 你们怎么想

@wardpeet Ty提供了更多见解。

我们在一个大型的Gatsby项目中对此事进行了大量研究，该项目使用了Contentful，将为我们在多个站点上使用（Gatsby主题很棒）。 我将分享一些发现，以防它们对其他人有帮助。

1. 我们有一种情况可能并不十分常见，但我已经看到足以相信它也不是那么独特了，在这种情况下，我们不得不使用useStaticQuery来捕获来自Contentful和.find 1通过标识符。 我们一直都知道这是错误的，但是直到站点的规模增长到拥有300幅以上的图像并且LH6出现并向我们发送邮件时，它才受到明显的惩罚。

这样做的原因是因为图像是Rich Text嵌入的一部分，我们无法在页面查询级别对其进行graphql（本质上是Contentful有要解析的包的json字段）。 使用Webpack捆绑分析器时，我们注意到一个巨大的JSON文件（约720 KB），并将其跟踪为该查询的数据，该文件被分组为Webpack用于大多数页面的模板。 这意味着访问我们网站的每个用户都将其作为整个页面模板的一部分

对于我们而言，这很重要，但是如果其他任何人正在执行大型静态查询（您当然不能传递参数以缩小大小），请确保当心这些情况并密切注意捆绑数据块。

1. 就在今天，我们通过在折叠后的图像（对我们而言是英雄图像）上使用Gatsby图像的loading道具取得了一些成功。 我们一直在努力研究内容最大的涂料，并且在一些初步测试中取得了良好的结果。 我几乎错过了一个重要的部分：如果您为最上面的图像设置了loading="eager" ，则可能还要为该图像设置fadeIn={false} ，因为base64和完全加载之间的过渡图像需要时间，这会延迟LCP。

这是我要引用的道具文档，有关fadeIn的注释在底部： https: //www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

我想分享屏幕截图，但是对不起，我不知道是否可以。 如果您使用Chrome devtools并查看性能面板，则在FP，FCP，FMP和LCP的“时间”行下会得到漂亮的小标签。 当我们切换到严格加载第一张图像时，我们不仅看到〜8-10的性能得分提高，而且可以看到LMP标签在FMP之后立即加载，而在我的情况下大约是第二秒之后加载。

希望对任何对此问题有帮助的人，并感谢到目前为止已做出响应的每个人。

在分析gatsbyjs.com和gatsbyjs.org时，我注意到的一些事情是，我们应该比我们所知道的要晚一些时间加载Google Analytics（分析），以确保它不会成为TBT的一部分。

@wardpeet您如何推迟分析和GTM？

@wardpeet感谢您的回复。 它是有益的。 此问题的最佳输出可能是一些文档，概述了如何针对新Lighthouse中的每个指标进行优化。 我相信我们的网站对用户的感觉很快，而且盖茨比本身在为实际用户优化网站方面做得很好。 但是，如果Google的网络生命力开始通知页面排名，那么对于大多数网站而言，获得良好的灯塔得分将变得至关重要。

@Jimmydalecleveland我们有一个类似的问题，需要加载资源的所有项目，以便我们可以使用markdown内的数据来配置过滤器（即我们无法使用GraphQL进行过滤）并通过使用不同的片段进行优化（加载完整资源与加载所有资源进行过滤时相比，字段子集要小得多）。 这极大地减少了我们的JSON，因此减少了我们的捆绑包大小。

@treyles，您需要注意延迟Analytics（分析）的加载，因为这可能意味着您的统计信息不完整。 例如，这可能意味着您报告的跳出率不正确。 有一些脚本不允许市场营销延迟（像素，分析，hotjar以及标签管理器），但是其他脚本（例如对讲机）很好，值得优化。 就如何延迟这些脚本而言，第三方提供的脚本通常会加载异步，但是仅此一项是不够的。 您可能需要做的是用自己的脚本替换这些脚本。 监听window.load，然后触发下载。 尽管某些脚本依赖window.load进行初始化，但您仍需要小心，如果使用它加载脚本，它将不会再次触发，因此您需要手动进行初始化。 以对讲为例，我们：

• 删除了对讲机提供的degault <script>...</script> 。
• 为window.load添加了一个侦听器
• 在此侦听器中添加了短暂的延迟
• 触发了对讲机的默认脚本的修改版本，该脚本加载了他们的lib异步。
• 进行轮询以查看何时加载了脚本（对讲机未提供可靠的事件）
• 手动初始化他们的脚本（通过默认脚本在page.load上完成）。

@wardpeet感谢您提供了非常有用的见解！

关于此解决方案：

确保在使用字体和图像时，它们不会延迟加载并尽快加载。 这些资产应从与您的站点相同的来源加载，而不应从CDN加载。

这不符合盖茨比图像的工作原理吗？ 此外，大多数CMS在服务器上处理映像转换，并在其自己的CDN中托管。 （这是一件好事，imo）。 但是，如果我们将其托管在自己的网站中，这还会适得其反吗？

除了@Undistraction所说的之外，盖茨比网页排名更新中加入这一点。

@Jimmydalecleveland我找到了一种在内容查询的富文本中使用gatsby图像的方法，而无需该查询技巧！ 这是要点。 该代码是从gatsby-source-contentful复制粘贴的。 基本上，您可以在GQL之外生成内容丰富的流体或固定道具。 对于内容丰富的富文本格式而言，这是完美的选择。

我还创建了一个请求请求，因此我们可以直接从gatsby-source-contentful访问API。

只是有些事情对我不利。 我建立了一个非常简单的网站，每页大约有一个图像，我使用SVG拍摄了没有gatsby-image的图像，我还尝试删除了Google Analytics（分析），但并没有太大的区别，我的得分大约是50-60。

让我真正感到困惑的是，只有主页（index.js）的得分很低，而其他页面（例如服务页面或联系页面）的得分却是80分左右。 我建立的站点相当一致，因此页面之间没有太大差异，但是由于某种原因，主页的得分约为50，而服务页面的得分约为80。

就像我之前提到的那样，在灯塔v5中，得分约为90，完全没有道理，像这样的简单网站现在得分约为50。

顺便说一句，您有没有尝试过将上述折页图像设置为eager ？
这将禁用延迟加载，并可能增加得分。 模糊或svg
加载效果可能会混淆Lighthouse（如果是这种情况，
他们算法中的缺陷）。

2020年6月13日星期六，t2ca [email protected]上午10:48写道：

只是有些事情对我不利。 我建立了一个非常简单的网站
每页约有一张图片，我将SVG用于没有gatsby-image的图片，
我还尝试删除了Google Analytics（分析），但并没有太大的作用
差异，我的成绩约为50-60。

让我真正困惑的是，只有主页
（index.js）得分很低，而其他页面（例如
服务页面或联系页面得分约为80。 我建了这个
网站相当一致，因此两者之间没有太大差异
网页，但由于某种原因，首页的得分约为50，而
服务页面得分约为80。

就像我之前提到的，在灯塔v5中，得分约为90，
根本没有道理，像这样的简单网站现在
分数约为50。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ，
或退订
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
。

@KyleAMathews我们拥有，并且它的性能得分和首次油漆都得到了显着提高。 这就是我在以上冗长的评论中概述为第2点的内容。 取消fadeIn终于使LH高兴了。

编辑：我（可能很无知）觉得，关注LCP并不是普遍关注图像的正确方法。 显然是轶事，但我觉得当所有内容都加载并且图像用后言淡入淡出时，网站的感觉要快得多，除非图像对内容至关重要。

一个常见的例子是“中型”文章。 当然，您可以说这是一个设计缺陷，但是大多数中型文章（以及许多其他博客）都在顶部以大的ol'图像开头，仅用于创建情绪或风景，我不在乎是否懒惰加载。

顺便说一句，您有没有尝试过将上述折页图像设置为eager ？ 这将禁用延迟加载，并可能增加得分。 模糊或svg加载效果可能会混淆Lighthouse（如果是这种情况，则是其算法中的缺陷）。
…

我现在尝试。

我想我在这里取得了一些进展。 我的得分从57分提高到84分，并且进行了非常基本的更改。 我的LCP从12s变为2s 。

也就是说，这是不一致的。 由于将在下面进行描述，因此我的得分从69-84不等。性能得分显然存在一些随机差异。

TLDR

首先，就像@KyleAMathews和@Jimmydalecleveland建议的那样，我尝试在折叠后的gatsby图像组件上设置loading="eager"和fadeIn={false} 。

接下来，我摆脱了查询中的base64 。

这些产生了巨大的变化。

好的

• 将_noBase64到我的图像片段中，我的得分提高了20分！

  • 似乎base64图像在移动设备上增加了很多重量。 我正在使用localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64从内容查询图像。

• loading="eager"和fadeIn={false}使我最大的内容绘画时间减少了约50％！

  • 由于某些原因，我的实际成绩仅上升了6-7点，但是LCP肯定正在取得进步...

我的查询如下所示：

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

我的gatsby-image看起来像这样：

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

不太好

我的网站上的UX现在看起来差很多。 base64 +淡入提供了出色的UX。 现在，它有点断断续续。 我想这是我们现在必须考虑的折衷方案？

eager和fadeIn={false}之前和之后

这是完全相同页面的一些并排比较。 唯一的区别是在右侧，图像具有loading="eager"和fadeIn={false} 。

1.主页

LCP下降49％。 成绩得分上升6分。

2.产品页面

LCP下降46％。 成绩得分上升7分。

上面的示例有什么奇怪之处：左侧的屏幕截图具有默认的gatsby图像行为（它们会逐渐淡入，并且没有eager 。）但是，即使性能得分较低，底部的小屏幕截图使其看起来比右图的加载速度更快。

就像@KyleAMathews提到的那样，也许他们在判断性能方面处于误差范围之内，或者可能是与效果

在图像片段中设置_noBase64之后

这是与上面示例相同的屏幕。 他们在Gatsby Image上都有loading="eager" ， fadeIn={false}道具。 另外，graqhql中的图像片段为GatsbyImageSharpFluid_withWebp_noBase64

有点莫名其妙，但是我正在完全相同的页面上一遍又一遍地进行灯塔测试，结果分别为84、75和69。

Kinda很奇怪，但是无论如何，它提高了我的分数。

我认为Lighthouse算法在这里感觉异常慷慨大声笑^

经过进一步调查，我发现灯塔在抱怨影响LCP评分的特定元素。

我所做的只是简单地移动了该元素，它只是一个段落，我的分数跃升到80以上。 不完全确定为什么移动段落将我的得分从〜50提高到〜80。

@nandorojo感谢您的详尽撰写。 我们还没有尝试完全删除base64，但是如果我们不得不这样做的话，那就太麻烦了。 我们也只将急切加载放在页面的第一张图像上，因此，如果您尚未执行此操作，那么可以控制它是值得尝试的。

经过进一步调查，我发现灯塔在抱怨影响LCP评分的特定元素。

我所做的只是简单地移动了该元素，它只是一个段落，我的分数跃升到80以上。 不完全确定为什么移动段落将我的得分从〜50提高到〜80。

@ t2ca这就是我得到的（尽管我是一个标头标签）。 但是，您将其移到了哪里？

@ t2ca这就是我得到的（尽管我是一个标头标签）。 但是，您将其移到了哪里？

@michaeljwright我

最后，我决定只是将段落移动，我在div内使用framer-motion，然后将段落移至div之外。 这给了我相同的结果，就像我删除该段落时一样。

@ t2ca我认为LCP会对我们的英雄页面中的所有动画进行惩罚，这

这是我的LCP分数，其中段落标签是LCP

带有动画：

没有动画：

@ t2ca我认为LCP会对我们的英雄页面中的所有动画进行惩罚，这

这是我的LCP分数，其中段落标签是LCP

带有动画：

没有动画：

@ daydream05谢谢您的确认！

@ daydream05

这不符合盖茨比图像的工作原理吗？ 此外，大多数CMS在服务器上处理映像转换，并在其自己的CDN中托管。 （这是一件好事，imo）。 但是，如果我们将其托管在自己的网站中，这还会适得其反吗？

不可以，因为gatsby-image也可以使用本地图像，因此无需将其托管在其他CDN上。 一切都取决于优化您的第一个渲染（视口中的内容）。 将其托管在其他域/ CDN上意味着您必须打开一个新连接（dns resolve，tls handshake等），这在缓慢的设备上最多可能需要300毫秒，然后您仍然必须下载映像。

除了@Undistraction所说的之外，盖茨比网页排名更新中加入这一点。

我们将进一步优化盖茨比，以确保我们的用户可以免费获得100张。

@ t2ca我认为LCP会对我们的英雄页面中的所有动画进行惩罚，这

这是可以预期的，因为您的屏幕永不停止绘画。 通常，LCP应该忽略CSS动画，但这取决于您如何制作动画。

@ t2ca

如果您可以向我们展示该网站，我们可以帮助您找出如何进行改进的方法，但这可能会使我们的形象更加迫切。

@nandorojo

很棒的文章！ 您是否有机会向我们提供这些灯塔报告的链接？

这是可以预期的，因为您的屏幕永不停止绘画...

@wardpeet您介意对此进行扩展吗？

@DannyHinshaw我从灯塔收到了这个解释
“我认为这是因为LCP确实关心图像是否完全加载，报告的时间是图像完全加载的时间，而不是图像首次可见的时间。由于渐进式图像和迭代绘制，因此该时间可能有所不同。 ”

然后这个链接，也许有帮助
https://web.dev/lcp/#when -is-largest-contentful-paint-reported

同时，您也可以尝试将最大内容绘画（LCP）从图像更改为文本（如果您愿意的话），预加载/预取字体并延迟加载图像。 在我的情况下，这意味着要减小移动设备上英雄形象的大小，这将使我们的得分重新回到90年代，而这个问题正在讨论中。

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/zh-CN/docs/Web/HTML/Preloading_content

这是可以预期的，因为您的屏幕永不停止绘画...

@wardpeet您介意对此进行扩展吗？

当然，我不知道这是哪个站点，我试图在此线程中找到URL，但这很难。 LCP不考虑CSS动画（过渡，css中的动画道具）。 但是，如果您具有使用setTimeout / setInterval来切换反应组件的内容，则会将其考虑在内。 后一种方法会使您的CLS分数非常差。

因此，如果要为英雄文本/图像制作动画。 请使用CSS动画。

嗨，您好，

我试图弄清楚为什么我的项目在Google Page Speed Insights，Google Lighthouse审核等方面得分如此之低。

没有从头开始，我不确定是什么问题。 我使用了这个入门/主题来入门： https :

我主要是在改变css的过程中，例如从布尔玛移到chakra-ui。

这是我的仓库： https :
我尝试删除所有帐户资料和gatsby-plugin-appollo-shopify资料，但这并没有改变。

这是实时链接： https :

我似乎没有做任何改变。 我宁愿不必从头开始。 如果有人可以给我提示或其他提示，我将不胜感激。

猜猜我太习惯了盖茨比给90-100s

感谢您的讨论，因为需要讨论如何获得良好的灯塔评分。 v6的出色评分变得更加困难，这主要归功于新的LCP指标。 我的网站（https://www.jamify.org）在Lighthouse v6中从〜100下降到了〜70。

为了将其恢复到台式机上的100，我不得不

• 删除不需要的背景图像（因为它被错误地选择为LCP）
• 优化图像尺寸
• 将gatsby-image为loading="eager"和fadeIn=false
  （当我喜欢模糊效果时，这实在太可惜了）

在移动设备上，由于5秒的LCP，我仍然停留在80。 可以通过适当调整手机图像的大小来改善此问题：

总的来说，这些优化是相当可行的，但是，我很不高兴我现在必须在具有模糊效果或Lighhouse得分高的延迟加载图像之间进行选择：：

有人在lighthouse v6.1上进行过任何测试吗？ 我注意到我的成绩有所提高。

向Google的Addy询问了有关LCP的模糊问题，这是他们正在努力解决的问题https://twitter.com/addyosmani/status/1277293541878673411

这里的教训是，暂时还不能将新的性能得分视为绝对值，它们仍在完善边缘情况。

我相信，随着Lighthouse 6.1的出现，这个问题会更加严重。 关于LCP，这里有一些好的建议，但我们对TBT的关注不多，我认为这是造成移动设备评分低下的原因，也是最难解决的原因。

您可以在Chrome Canary中测试Lighthouse 6.1。 我已经比较了我的站点在6.0和6.1之间以及此处提到的其他站点，并且TBT急剧增加。 例如在我的6.1测试中：

• gatsbyjs.org TBT：2550ms
• 我的网站待定：2200ms
• @styxlab网站：1250毫秒

任何超过600的TBT均为红色，根据计算器的重量为25％，因此是主要因素。 TBT是由在FCP和交互时间之间执行花费超过50ms的功能引起的。

上面的屏幕截图是我网站上的个人资料。 如果您在Chrome中使用Lighthouse，则可以单击“查看跟踪”按钮以将结果加载到配置文件标签中以查看结果。 FCP之后任何带有红色标记的任务都将计入TBT。 我尚未深入研究任务是什么，所以也许对盖茨比有更多了解的人可以在这个领域提供帮助，也许@wardpeet可以在可能的

@IanLunn这是一个有趣的痕迹，您是否能够了解这些任务的基本内容？

每个Gatsby网站拥有多少JS与在浏览器主线程上变得昂贵之间，可能存在相关性。 但是，我认为讨论的余地可能很大，盖茨比是否有办法通过完全加载查询和脚本来帮助“减轻”影响？

目前，我想从三个方面更好地理解：

• 默认情况下，Gatsby会为每个所需脚本（按照PRPL模式）添加<link rel=preload/> ，无论有多少个脚本。 我注意到在测量的FCP中有一些差异（我非常惊讶），但是在删除这些FCP / LCP之间主要存在差异（如果没有其他更改，这可能不是一个好主意）。 灯塔上的这个问题讨论后者。
• 查询最终创建在主线程上评估的JSON（page-data.json和用于静态查询的哈希值）。 参见https://github.com/gatsbyjs/gatsby/issues/18787，但似乎我们没有找到（或如果有的话）不阻塞主线程的替代方法。 数据越大，对性能的影响就越大（因此，非常欢迎
• 实际的块在<script src=foo.js async />的末尾添加为</body> 。 这意味着浏览器一旦完成对HTML的解析（在跟踪中应该很快），它将开始解析并执行这些脚本（因为它们已经预先加载）。 当请求主线程解析并执行所有这些javascript时，不可避免会出现长任务。 是否有更好的方法来处理此问题（至少在开始解析这些脚本时）以避免阻塞主线程？ 有什么方法可以在增量小任务中做到这一点（解析或执行），既不会延迟输入反馈（从而损害TTI），又不会在一段时间内阻塞主线程（从而损害TBT）？

由于LCP尚未从gatsby-image识别出LQIP模式，因此目前的盖茨比站点正在受到一定的惩罚–当涉及到与TBT / TTI有关的任何事情时（可能会对价格造成重大损失） Javascript与Lighthouse v5相比）我认为灯塔团队的路线图中没有什么可以从当前分数上得到改善。

@juanferreras最大的任务似乎是domready / ready.js（第三方）。 我感到您关于Lighthouse惩罚JavaScript的说法是正确的，尽管在Gatsby中可能可以进行一些小的优化，但这并不是可以解决的。

如果这是在Lighthouse中的情况，我很想至少请他们减轻TBT的重量或提供设置所需测试环境的选项。 根据预算电话提供分数并不总是适合所测试的网站。 我们应该能够向老板/客户表明，是的，例如预算电话获得75分，但高端电话（例如95％的用户获得90分）。

• 查询最终创建在主线程上评估的JSON（page-data.json和用于静态查询的哈希值）。 参见＃18787，但似乎我们没有找到（或如果有的话）不阻塞主线程的替代方法。 数据越大，对性能的影响就越大（因此，非常欢迎

@juanferreras ，关于在主线程上解析json数据的问题，想到的是Web worker。 如果客户可以使用Gatsby，可以注册一个网络工作者，并将其缓存在其中，不需要立即进行补液过程，所以我相信这是可行的

包括ie10在内的主要浏览器均支持Web worker。

…我们对TBT的关注不是很多，我认为这是导致移动设备评分不佳的最主要原因，也是最难解决的原因。

我想添加一些我认为与总阻止时间有关的内容。 在使用Webpack包分析器检查了我的包之后，我注意到来自静态查询的数据包含在JavaScript包中。 我敢肯定有一个很好的理由，但是它可以解决低TBT的问题。

TBT是一个很难解决的问题，尤其是因为React不是为此而构建的。 采取行动是一个很好的第一步。 在未来的几个月中，我们将越来越多地改善TBT，我们希望Gatsby的足迹很小。

在> 2.24.0的gatsby版本中，我们提供了改进的polyfill支持，因此我们仅在IE11等旧版浏览器上加载polyfill。 几天前（@MarkosKon），我们还从Webpack中删除了静态查询。

@Teclone可悲的是，网络工作者不适用于JSON解析。 您仍然需要为在线程之间进行序列化和反序列化付出代价。 使用ShardArrayBuffer会是另一Meltdown / spectre ，默认情况下将它们禁用

我刚好在Chrome内置Lighthouse（6.0）上的所有功能上获得了100/100，然后使用了web.dev版本（6.1），由于LCP（在大约5-6秒内），它的性能恢复了70年代6.1，在6.0中约为0.5秒）。 它是装饰性的标题图像（使用gatsby-background-image），它正在抱怨。

从我自己的网站来看，Webpack运行时具有最多的JavaScript执行时间。 在用户开始与页面交互之前，页面甚至不需要这些东西。

Gatsby似乎只是一次加载所有这些资源（块）。 js文件本身很小，它是一个加载程序，您可以看到传递文件只需要2毫秒。 但是文件本身会加载块和模板文件。

实际上，当我检查块文件时，发现它们都是动态导入，我们希望它们仅在需要时才加载，但是不，它们都是默认加载的。 这种行为不是我所期望的。

对我们的标头图像做了一些优化，例如直接使用图像而不是Gatsby-Image并减少分辨率和压缩，我们的图像要好一些。 只是，我刚刚发现Safari不支持WebP（grr）的困难方式。 而且，至少对于我们的“隐藏”开发网站而言，Lighthouse的网络版本比Chrome内置的版本宽容得多。 时间将证明汇总的用户数据一旦投入使用是否会有所帮助-我不相信在现实世界中会使用Moto G5的人很多！

@derykmarl应该很快得到支持： https : //www.macrumors.com/2020/06/22/webp-safari-14/
我不明白为什么苹果花了这么多时间来支持广泛的图像格式...

我读到pagespeedinsight模拟了分数的计算方式。 他们似乎并没有限制网络，因此您可以更快地获取报告。 我个人使用https://lighthouse-metrics.com/，但它们尚不支持6.1。

灯塔6.x的问题在于它依赖于感知时间，您可以运行10次相同的测试，并且根据网络条件您将不会获得相同的结果。

由于LCP，它在70年代恢复了性能

我有一个LCP，这是我网站的背景图像，通过将图像分成6个子图像，我可以大大减少LCP。 我制作了一个python脚本来轻松做到这一点，只要您知道每个细分的高度

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

我还发现该图像压缩网站在缩小图像尺寸而又不会损失太多质量的情况下非常有效。 我通常可以降低到20％-30％的质量标记，然后大幅度减少文件大小。

我在网上问了一些有关此问题的建议，有人建议我只将图像分成2张，高于折页和折页以下，但是我发现将图像分成6张可以更好地工作。

在TBT / TTI注释上使用@wardpeet ，我们也许能够看到其他基于反应的站点现在如何减轻对浏览器主线程的总体影响。

reactjs.org本身（据我所知也是由Gatsby构建的）似乎比新的gatsbyjs.com的TTI小得多（7-8〜vs 12〜）（顺便恭喜！）。 尽管NextJS本身是基于React的，但它在TTI / TBT上也保持了很好的数字（这也可能是由于脚本的相对大小-根据PSI，gatsby.com大约有628.3kb的脚本，reatjs.org 466.1kb ，而nextjs.org仅216.8kb）

（显然，这是一次运行，因此不应将其用作实际比较，但跨多次运行的趋势是相当一致的）。

分数差异的大部分是归因于Javascript™的整体成本吗？ 如果Gatsby团队在某个时候优化了新网站，这可能是一个很好的机会，可以分享有关流程的一些见解，但前提是没有太多的魔术可以添加到gatsby框架已经在内部处理javascript的方式中。

@juanferreras @wardpeet ，我在自己的项目中也发现了一些东西。 如果您使用样式化组件，则由于某些原因，在水合期间会重新计算/重新生成样式，然后将样式重新注入浏览器。 这需要很多主线程。

这是由于盖茨比水化问题。 https://github.com/styled-components/styled-components/issues/2171

Gatsby还致力于在开发过程中运行ssr， https：//github.com/gatsbyjs/gatsby/issues/25729 ，这将有助于消除此类性能问题。 太。

@teclone

https://github.com/styled-components/styled-components/issues/2171似乎没有提供解决方案。 您如何在项目中修复它？

@dfguo到目前为止，还没有解决办法，因为没人知道确切的原因，为什么在补水过程中会重新生成样式，因为生产中的gatsby无法提供补水错误的开发帮助。

也就是说，React在补液期间没有指向差异的控制台日志，因为它在gatsby的生产版本中被禁用。

正在进行中的这项工作＃25729的目的是在开发中运行真正的SSR，因此我们将能够看到原因。 包括盖茨比队。

顺便说一句，您可以使用gatsby build --no-uglify构建一个Gatsby网站，使用React的开发版本来查看日志。 https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR在将来对此类问题将非常有帮助！

因此，我决定将网站从@emotion和theme-ui迁移到linaria同时使用自定义CSS变量实现dark-light模式

目的是减少阻塞时间/主线程/与js相关的css不再在运行时求值，而是在构建时进行编译（实际上linaria与gatsby更加一致）就此而言，与@emotion相比， gatsby语句）

这个过程并不完全顺利，我使用@emotion所做的大部分事情都只能与linaria ，但是其他一些则不能，您必须重写它们和/或通过自定义CSS重新实现它们。变数

使用gatsby的DX经验很差______，无法进行热重装（由于浏览器似乎失去连接，您必须停止并重新启动任何更改），但是总体而言，此过程非常好，因为它迫使您对什么内容更加谨慎您真的需要@emotion运行时功能

__也就是说，灯塔指标非常相似__

我可以比较两个netlify部署，实际上@emotion网站的高70s，而linaria网站的低70s

不用说，我不是很兴奋

分析捆绑包：

• 站点文档从14 Kb增加到28 kb
• 框架脚本保持相同，为38.7 kb
• 应用程序脚本从58.2 kb减少到46.1 kb
• 第四个脚本（ component--content.. ，然后是20bae078..现在）从44.2 kb变为46.8 kb

因此，我假设js中的样式已移至css中的样式（〜12 kb是重要的IMO），但这对灯塔指标没有任何实际影响（这很重要，不是吗？）

因此，我一点也不说转移到linaria没有任何意义，如果有人也这样做并取得更好的结果，我也不会感到惊讶（理论上应该是这种情况（？）），但是在我看来，这个过程并不值得

尽管如此，在探索应用程序脚本时，我已经打开了一个新问题，试图弄清楚如何减少js捆绑包https://github.com/gatsbyjs/gatsby/issues/26655

使用gatsby的DX体验很差，无法进行热重装（由于浏览器似乎失去连接，您必须停止并重新启动任何更改），但是总体而言，此过程一直很不错，因为它迫使您更加谨慎地考虑您真的需要@emotion运行时功能

@kuworking我遇到了类似的问题，但是注意到它只在gatsby版本比2.24.9 ； 不确定原因是否相同，但是我认为这可能会帮助某人知道人们在谈论问题＃26192 。

@kuworking我遇到了类似的问题，但是注意到它只在gatsby版本比2.24.9 ； 不确定原因是否相同，但是我认为这可能会帮助某人知道人们在谈论问题＃26192 。

我会说"gatsby": "2.24.14"已经有几个星期了，到目前为止，我只在linaria经历过
但是知道了这一点，直到解决了这个问题，我才更新gatsby，谢谢👍

@kuworking我的意思是，如果您降级到2.24.9那么即使linaria也不会发生开发服务器停止的问题； 但这只是一个主意。 我很想知道是否是这种情况。

使用gatsby的DX体验很差，无法进行热重装（由于浏览器似乎失去连接，您必须停止并重新启动任何更改），但是总体而言，此过程一直很不错，因为它迫使您更加谨慎地考虑您真的需要@emotion运行时功能

您是否尝试过快速刷新？

我最近迁移了一个生产gatsby网站（约120页）以进行改进，以期改善TBT和LCP。 我们的网站使用的是由svgr生成并使用material-ui样式设置的react svg组件，因此svg繁重。 平均性能结果在初始分数的+ -5范围内（从v6之前的〜85降低到〜45移动性能），尽管使用该主题迁移相对轻松，但确实需要迁移到快速刷新，即不。

老实说，我感到失望的是，除了通用的“删除未使用的javascript”灯塔警告外，我没有找到其他可以尝试使用的优化措施或更详细的指标了。

速度是我们选择gatsby的主要原因之一，即使页面仍然可以快速加载，但是当您的洞察力得分如此之高时，从SEO的角度来看很难证明这一点。

耳语：我改用NextJS，成绩也越来越好🤭

耳语：我改用NextJS，成绩也越来越好🤭

斯维尔特呢？

最好知道盖茨比（Gatsby）开发人员是否在路线图中赋予了这种特定的重要性/优先感（不是预期的），因为我认为目前尚无立即解决方案，但未来可能会有一些方向和实现重点这个或那个

由于gatsby使用gatsby-node *进行了一些编译，所以我想知道他们是否正在探索增加该部分并去杠杆化客户部分的方法。

*为了减少我正在使用的pageContext （有关所有已发布帖子的数据），我目前（通过gatsby-node ）将大部分数据存储在json文件中并在需要时从网站上获取它们，这样可以减少捆绑包的大小，但也更合乎逻辑

不要太在意灯塔的得分-特别是当他们
是作为与其他网站的基准，而不是我们应该
努力取得完美的成绩。

直到最近，盖茨比才确定纯100
有一些问题需要解决，但目前的SEO游戏是速度加内容
加上链接，我们将其覆盖。

我的两分钱。

2020年8月28日星期五，kuworking，16：57， notifications @ github.com写道：

耳语：我改用NextJS，成绩也越来越好🤭

斯维尔特呢？

最好知道盖茨比开发人员是否为此提供了一些具体信息
路线图中的重要性/优先级（预期之外）
一个），因为我认为没有立即解决方案，但也许有一些解决方案
这种或那种重点的未来方向和实现方式

由于gatsby使用gatsby-node *进行了一些编译，我想知道它们是否
正在探索增加该部分并去杠杆客户部分的方法

*为了减少我正在使用的pageContext（关于所有的数据
已发布的帖子），我目前（通过gatsby-node）存储的大部分
将这些数据保存在json文件中，并在需要时从网站获取它们，
这减小了捆的大小，但也感觉更合逻辑

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ，
或退订
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
。

抱歉，响应时间太晚，性能有很多问题，负载指标只是一小部分难题。 我们在本季度和下一个季度的动力是使Gatsby变小并降低TBT。 目前最大的问题是React包大小，MDX，大页面（内容/样式），跟踪脚本以及字体/图像作为首次加载时的主要内容。

我目前正在研究gatsby图像和分析脚本，以了解我们如何改善加载时间和推迟分析。

可悲的是，我无法给出任何估计。 我们还在查看我们的.com网站和我们的客户，以了解常见的问题是什么，因此我们可以将这些优化应用于gatsby或插件中。

编辑：

我很高兴查看您的任何源代码，以获取有关您在做什么方面的更多见解，以了解我们如何进行改进。

我在一篇reddit帖子中尝试汇总了所有可以找到的改进技巧。 如果您能提出更多建议，请列出它们

仅删除gatsby图像（家庭英雄图像和任何背景图像），我的得分就会提高10-20点。

在最近的一些测试中，我发现使用tracedSVG实际上可以显着提高Largest Contentful Paint的性能得分。 我想这将在Lighthouse中修复，但是到目前为止，这是因为SVG被认为与全分辨率图像具有相同的尺寸，因此它永远不会从作为LCP目标的SVG交换为完整图像。

使用base64时，较小的分辨率使其不适合作为LCP的候选对象，因此，每当装入时，Lighthouse都会使用全分辨率图像。

因此，如果您不介意所跟踪的SVG的外观（我个人更喜欢它们），则可以尝试一下。

为什么v5比v6更好的结果？ 我正在使用NextJS，结果总是从60更改为85。

+1

我一直在研究盖茨比图像的继任者。 那里还不是100％，仍然需要编写可组合的版本，以便您可以创建自己的gatsby图像样式，但是它将解决大多数不良的灯塔问题。

您已经可以使用它，但尚未经过战斗测试。
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

您可以通过npm install --save @wardpeet/gatsby-image-nextgen安装它。 现有的gatsby-image用户有一个

目前尚不支持的功能：

• 对象拟合需要由组件外部的CSS完成
• 艺术方向

当前的gatsby图像演示：
网站： https ：
pagespeed-insights： https : =https% 3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
网页测试： https ：//webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

新的gatsby-image-nextgen演示：
网站： https ：
pagespeed-insights： https : =https% 3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
网页测试： https ：//webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet当前演示的pagespeed-insights链接转到nextgen，因此它们显示相同的分数。
棒极了，顺便说一句。 看到进展真令人兴奋。

谢谢修复！

此更新向我指出了我之前没有连接过的东西，我没有使用gatsby-image但实际上是gatsby-background-image ，显然没有在后台使用gatsby-image ...如果可能的话，我可能必须用这个新的@wardpeet/gatsby-image-nextgen重写该组件。

本文列出了一些额外的提示https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/虽然我觉得很多人已经在这个线程中提到...

@DannyHinshaw插件功能齐全时。 我也会看一下该插件。 我也要看评论图片

我已经发布了@wardpeet/gatsby-image-nextgen -0.0.2的新版本。

1. 缩小HTML中的CSS和JS
2. 仅加载必要的位，当启用本机图像加载时，我们仅加载约2kb（未压缩）。
3. 确保仅在首次加载时调用占位符，立即加载缓存的图像
4. 通过解码异步来修复模糊动画

我想知道有多少人需要一个可组合的Image组件，您可以在其中构建自己的包装器，而实际上有多少人实际上在使用art-direction，并且希望默认情况下在gatsby-image中使用它？ 我的第一个想法是禁用该功能，但使用可组合的gatsby-image启用它，因此您必须制作自己的图像组件以支持它。

最新演示： https ：

@wardpeet太好了！ 我严重依赖gatsby-image的内置艺术指导。 但是我想一个例子/平滑的升级路径也可以！

我总是在移动设备上收到99，而现在在移动设备上收到76。除了我的LCP（7.0秒）外，一切都很棒，它说出了我的英雄形象。 没有意义。 当我用任何手机打开网站时，它的速度很快。 人们赞叹不知道？ 它还告诉我将图像放入webp或其他图像，但是我已经使用了childImageSharp_withWebp，所以我不明白。 我开始发现Gastby Image和background-image无法在lighthouse和pagespeedinsight上使用此新版本。 我的头脑陷入困境。 我去杀了动画，将我所有图像的大小都缩小了一半，而且一点都没有退缩。 我正在阅读此书，看不到有什么对我有帮助....哦，我只是抬头...我想

@davidpaulsson介意分享有关如何执行此操作的示例？ 由于新的gatsby图像仍然可以进行艺术指导，因此您必须执行一些手动步骤。

@davidpaulsson介意分享有关如何执行此操作的示例？ 由于新的gatsby图像仍然可以进行艺术指导，因此您必须执行一些手动步骤。

当然！ 我现在这样使用

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet嗨，沃德。 blurha.sh对gatsby image nextgen有用吗？

@wardpeet我使用了您的gatsby-image-nextgen插件，实际上确实改善了我的LCP时间（将它从〜5s减少到〜1.5s）。 这次真是万分感谢！

但是，我们也使用艺术指导，类似于@davidpaulsson的使用方法，而且我似乎无法使其像gatsby-image一样工作。

您能否详细说明使nextgen插件成为可能的手动步骤？ 再次感谢！

@Jimmydalecleveland谢谢吉米！ 用GatsbyImageSharpFluid_withWebp_tracedSVG代替GatsbyImageSharpFluid_withWebp极大地改善了我的新盖茨比Webiste的性能得分。 我得到的不超过54％，现在使用tracedSVG得到的超过80％。 那是一个巨大的进步

在最近的一些测试中，我发现使用tracedSVG实际上可以显着提高Largest Contentful Paint的性能得分。 我想这将在Lighthouse中修复，但是到目前为止，这是因为SVG被认为与全分辨率图像具有相同的尺寸，因此它永远不会从作为LCP目标的SVG交换为完整图像。

使用base64时，较小的分辨率使其不适合作为LCP的候选对象，因此，每当装入时，Lighthouse都会使用全分辨率图像。

因此，如果您不介意所跟踪的SVG的外观（我个人更喜欢它们），则可以尝试一下。

@abdullahe我们之前已经检查过它，并且它依赖于canvas，而node-canvas并不是超级可靠的。 或者至少不是过去。 如果我们再考虑一遍，我将通知您：)

@guydumais确保将loading="eager"放进去，它也会改变您的得分。

@BenjaminSnoha和@davidpaulsson我将分享一个例子。 如果图像之间的宽高比发生变化（例如水平到垂直），则艺术方向的最大问题。

@wardpeet如何将@wardpeet/gatsby-image-nextgen与gatsby-remark-images ？ 是否只是将它作为gatsby-config.js的插件指向一种情况，还是直到它被合并到gatsby monorepo中才有可能吗？

尽管这可能与灯塔无关，但我想知道为什么gatsby页面数据JSON文件不像js文件那样支持内容哈希。

我知道js文件的内容哈希是由Webpack执行的，但是gatsby也可以对页面数据JSON文件执行相同的操作。 这样可以节省很多CDN网络请求

如果正确设置了缓存，则不应反复下载@teclone page-data.json文件。 它们将加载一次，然后浏览器将对其进行重新验证。 页面数据（相对于JS / CSS文件）的内容哈希处理的问题在于，它们太多了。 对于内容哈希，在加载文件之前，您需要加载一个清单，该清单从x为x.LONG_HASH因为哈希是不可预测的。 使用JS / CSS，加载清单是合理的，因为即使在非常大的站点上也只有这么多JS文件。 但是对于页面数据，每页只有一个，因此清单可能会变得很大。 我们曾经这样做，在一个10k页的站点上发现清单已被压缩约500k。 https://github.com/gatsbyjs/gatsby/pull/13004

如果确实看到一遍又一遍下载的page-data.json文件，请检查您是否没有禁用devtools中的缓存，并使用https://www.npmjs.com/package/check-gatsby-caching检查缓存头

@KyleAMathews ，感谢您澄清这一点。 那是一个非常明智的方法

@wardpeet是不是image-nextgen不支持fadeIn="false"或fadeIn="{false}"

它的效果要好得多，从〜80变为〜95

@MelleNi不需要，我认为没有必要，但我们很乐意考虑。

您可以在https://github.com/gatsbyjs/gatsby/discussions/27950上查看我们要运送的产品。

@wardpeet如何将@wardpeet/gatsby-image-nextgen与gatsby-remark-images ？ 是否只是将它作为gatsby-config.js的插件指向一种情况，还是直到它被合并到gatsby monorepo中才有可能吗？

我们也将把评论移至该插件:)

@MelleNi不需要，我认为没有必要，但我们很乐意考虑。

您可以查看＃27950来了解我们的发货情况。

@wardpeet如何将@wardpeet/gatsby-image-nextgen与gatsby-remark-images ？ 是否只是将它作为gatsby-config.js的插件指向一种情况，还是直到它被合并到gatsby monorepo中才有可能吗？

我们也将把评论移至该插件:)

很高兴听到这个评论，因为我看到速度有了很大提高。

但是，我注意到如果不禁用Gatsby的javascript（并手动重新集成特定功能）就无法获得99-100。 我可以使用fadeIn={false}来使旧的Gatsby图像在不使用javascript的情况下工作，但不能使用image-nextgen。 （也许我错过了一些东西，这绝对有可能吗？）现在没有javascript，没有nextgen我永远也不会跌破99。

我了解到，禁用javascript会破坏Gatsby的想法，但是很好。

有趣的是，当我停止使用自托管字体（fontsource）并切换为“系统”字体时，我看到了移动性能得分的改进（从70到90）。

@wardpeet有机会分享如何构建具有美术指导的可@BenjaminSnoha和@davidpaulsson在同一条船上，而且我不介意在自己的项目中创建可组合组件。

我看到的最大问题是处理媒体查询和SSR。 菲涅耳这样的库可以工作，但是会因加载所有组件而使性能window组件可用后清理DOM。

在我的网站上，似乎所有用createPage创建的页面在pagespeed大量javascript（删除未使用的JavaScript）中都具有源代码（markdown和markdown反应markdown中的组件）

我刚刚启动了Plaiceholder ，它可用于创建纯CSS模糊的占位符。 也许这会很有趣？ 很高兴与任何核心团队就期权转发进行交谈

我制作了Jamify Blog Starter的Next.js版本，在最新的Lighthouse 6.4.0中得分很高：

您可以在next.jamify.org上查看演示站点。

我将其发布在这里，不是建议您切换到Next.js。 相反，要了解如何通过盖茨比实现相同的目标。 我认为成功的关键因素是：

• 高度优化的图像（Next通过lambda优化器实现，但是也可以使用gatsby-plugin-sharp来完成）。
• 一个简单的占位符svg（诸如模糊之类的精美效果会减慢页面速度）。
• 使用相交观察器仅在查看时显示图像（请参阅下一个/图像）。
• 确保图像的延迟加载。
• 小捆装。

如果您想进一步讨论，可以通过twitter与我联系。

@styxlab我在web.dev/measure中得到的结果略低

但发布结果更好，在任何情况下绝对具有非常好的价值，并且与gatsby版本https://demo.jamify.org/明显不同

我还将在一个站点上发布，我已将gatsby更改为11ty ，并且性能有所提高，但并没有显着提高

（盖茨比）

（不同的设计，基本上相同的内容，11个）

或在类似页面中，这次带有图片

（盖茨比）

（不同的设计，基本上相同的内容，11个）

我会说11ty开发人员的经验非常好（您也可以--experimentally使用jsx和styled-components ），但是客户端上的任何js都会丢失（您可以将其插入并与webpack战斗，那一刻就是您错过盖茨比的地方）

当我使用11ty时，我还考虑了gatsby启用某种11ty渲染策略有多么好，这样一个人就可以在一个框架中部署混合的React和无反应的静态页面...

有任何更新吗？ 我没有任何图像，由于总阻塞时间，我的性能得到76