Lighthouse 6는 몇 가지 새로운 지표를 도입하고 v5에서 다른 지표를 제거하여 점수가 변경 될 가능성이 높습니다. 이 문서에서는 변경된 사항에 대해 설명합니다.

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

또한 점수를 분석하고 어떤 요인이 가장 많이 기여하고 있는지 이해하는 데 정말 유용한 점수 계산기에 대한 링크도 있습니다.

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

v6의 메인 스레드 상호 작용에 더 중점을두고 있다는 인상을 받았으므로 사이트에 큰 JS 번들이 포함되어 있다면 아마도 중요한 요소 일 것입니다.

예 @shanekenney , 알고 있지만 어떤 부분이 이것을 유발하는지 확인하기 위해 사이트의 일부를 제거하는 것 외에 그것을 줄이는 방법을 실제로 모릅니다.

gaysbyjs 및 테마 UI 사이트에도 영향을 미칩니 까? 궁금합니다 / 사이트에서 어떤 최적화를 고려하고 있는지 또는 특정 원인을 발견했는지 알고 싶습니다.

이 문제는 훌륭하므로 전체 Lighthouse / PageSpeed ​​인사이트 점수와 v6에서 볼 수있는 가능한 회귀에 대해 논의 할 수 있습니다.

@kuworking 한 가지 주목할 가치가있는 점은 lighthouse-metrics.com이 5.6에 _ "Emulated Nexus 5X"_를 사용하고 6.0에 _ "Emulated Moto G4"_를 사용하는 것으로 보이며 비교에 약간의 노이즈를 추가 할 수 있습니다.

922 개 사이트에 대한이 벤치 마크는 v5에서 Gatsby 사이트의 중간 성능 점수가 75라고 주장 합니다. 로컬 네트워크가 또 다른 가변성 요소가되는 것을 방지하기 위해 호스팅 된 솔루션을 사용하여 빠른보기를 시도 할 것입니다.

현재 (Lighthouse v5.6 / PageSpeed ​​Insights 포함)

PSI는 "Fast 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 (Mobile 77/100, TTI 6.6s) 소스

그러나 일부 다른 사이트 (및 대부분의 시작)는 PageSpeed ​​Insights에서 매우 잘 작동합니다.

• store.gatsbyjs.org (Mobile 99/100, TTI 2.5s) 소스
• thirdandgrove.com (모바일 91/100, TTI 4.0s) 소스

평균 TTI는 눈에 띕니다. v6는 TTI의 전체 가중치를 33 %에서 15 %로 변경하고 First CPU Idle을 떨어 뜨 렸지만 가중치가 25 % 인 TBT를 추가합니다. 전반적인 JS 구문 분석 및 실행.

Lighthouse v6 ( WebPageTest.org 포함 )

• 이것은 _3G Fast (1.6mbps / 768kbps 150ms RTT) _의 연결로 _Moto G (gen 4), Moto G4-Chrome_에서 WPT를 실행했습니다. 이것은 PSI가 기본 등대 버전을 업데이트하기 전에 얻을 수있는 것처럼 장치 / 네트워크 의 일치만큼 가까운 것 같습니다.
• _Chromium_에서 ​​_Capture Lighthouse Report_를 확인하십시오. 처음 방문자가 페이지를 처음로드 할 때 범위를 유지하기 위해 반복보기를 비활성화했습니다.

결과는 다음과 같습니다. 번호를 클릭하면 Lighthouse 보고서를 볼 수 있습니다. 그 보고서에서 값을 추출하고 있습니다.

• 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. 전체 TTI (및 TBT)가 JS 구문 분석 + 실행으로 설명됩니까? 아니면 상호 작용에 해를 끼치는 다른 요인이 있습니까?
2. 그렇다면 첫 번째로드에 필요한 것을 _only_ 전송하도록 청크를 빌드 할 때 (예 : 세분화 된 청크 활성화 와 같은 최신 변경 사항과 같은 기본적으로 Gatsby에서 또는 일부 실험적 플래그 아래에서) 더 공격적 일 수 있습니까 (예 : app- [hash] .js 초과)? 또한 더 많은 지침과 함께 웹팩 구성을 확장하여 플레이하는 방법을 단순히 문서화 할 수도 있습니다.
3. Module / nomodule 과 같은 패턴이 청크를 줄이는 데 도움이 될 수 있습니까? @ loadable / components 사용을 권장 / 문서화 하시겠습니까? 부분 재수 화 ?
4. 이것은 높은 점수를 올리는 두 번째 단계 일 수 있지만 FMP는 더 이상 요소가 아니므로 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 레이블 (~ 800ms)

비슷한 일이 시작 기 https://parmsang.github.io/gatsby-starter-ecommerce/ 에서 발생하는 것을 볼 수 있습니다.

업데이트로-PageSpeed ​​Insights가 Lighthouse v6을 실행하기위한 업데이트를 소프트 런칭 한 것 같습니다 (아직 일부 지역에 있지 않을 수 있음).

https://gatsbyjs.org/ 테스트 링크 . 현재 주로 TBT 및 TTI의 값에 따라 60 년대 중반에서 80 년대 중반까지 다양한 결과를 얻고 있습니다.

@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 (preload-fonts 캐시도 사용)에서 typekit로드 된 글꼴을 제거 할 때 100을 누르십시오.

GTM은 전반적으로 내 프로젝트에 큰 영향을 미치고 있지만 제거해도 큰 변화는 아닙니다. 나는 여전히 더 많은 테스트를 할 필요가 있지만 그냥 그것을 버리고 싶었습니다.

@Jimmydalecleveland 흥미로운! 나는 또한 화면이 텍스트이고 LCP의 주요 원인으로 영웅 텍스트를 비난하는 또 다른 사이트가 있습니다. 그리고 LCP는보기에있는 모든 것을 설명합니다. 텍스트가 어떻게 그렇게 큰 문제가 될 수 있습니까?

@dougwithseismic 나는 또한

Lighthouse v6는 JS 프레임 워크에서 점수 가중치를 어떻게 변경했는지에 따라 정말 힘들다고 생각합니다. (차단 시간에 더 집중) 그리고 Gatsby 사이트는 재수 화 및 기타 사항으로 인해 역사적으로 스크립트 평가 / 메인 스레드 점수가 낮습니다.

@dougwithseismic 스타일 시트를 사용하지 않고 typekit 글꼴을 어떻게 연결 했습니까?

저도 비슷한 경험을하고 있습니다. lighthouse 5.7.1에서 제 성능 점수는 약 91 점이지만 lighthouse 6은 제 성능 점수를 약 60 점으로 크게 떨어 뜨 렸습니다.

최근 100에서 79로 떨어졌습니다 ~ https://dougsilkstone.com/ . Google 태그 관리자 (및 Google Analytics)가 제거되면 최대 90 개까지 이동합니다.

내가 테스트 할 때 더 많은 결과를보고 할 것입니다.

편집 : gatsby-plugin-web-font-loader (preload-fonts 캐시도 사용)에서 typekit로드 된 글꼴을 제거 할 때 100을 누르십시오.

이 플러그인도 설치하지 않았지만 모바일 점수가 90+에서 60 ~ 70 +로 떨어졌습니다.

여기도 마찬가지입니다. 여러 사이트에서 90ish에서 60ish로 대폭 감소했습니다.

약 30 점 이상 +1 드롭

이 문제를 해결하는 사람이 있습니까? 기본적으로 더 나은 점수를 제공하지 않으면 Gatsby over Next를 사용할 필요가없는 것 같습니다.

이 문제를 해결하는 사람이 있습니까? 기본적으로 더 나은 점수를 제공하지 않으면 Gatsby over Next를 사용할 필요가없는 것 같습니다.

다음 번호가 있습니까?

이 점수가 빠른 웹의 새로운 표준인지 궁금합니다 (정적이지 않고 JS가없고 이미지가 없을 가능성도 있음)

다음 번호가 있습니까?

https://nextjs.org/ 의 점수는 85 점으로 가장 큰 콘텐츠 페인트 (3.8)와 첫 번째 콘텐츠 페인트 (2.8)가 주범입니다. 또한 "Unused JS"가 많이 있습니다. Lighthouse 5.7.1의 95에서 감소했습니다. 개츠비 사이트는 두 배나 많은 포인트를 잃는 것처럼 보이는 반면, 약 10 포인트가 "단지"떨어집니다.

나는이 세상에 익숙하지 않지만 npm의 등대 6.0.0으로 테스트했을 때 내 개츠비 사이트가 약 25 점을 잃은 후이 문제를 따르고 있습니다. 흥미롭게도 npm 등대 대신 페이지 속도 인사이트를 사용하면 내 사이트가 약 99로 돌아갑니다. gatsbyjs.org는 pagespeed 인사이트에서 ~ 70을 얻지 만 npm 등대에서는 ~ 84를 얻습니다. 어딘가에서 뭔가 조정되고있는 것 같아요. 그들 모두는 'Unused JS'경고를 받고 있습니다.

이 문제를 해결하는 사람이 있습니까? 기본적으로 더 나은 점수를 제공하지 않으면 Gatsby over Next를 사용할 필요가없는 것 같습니다.

다음 번호가 있습니까?
이 점수가 빠른 웹의 새로운 표준인지 궁금합니다 (정적이지 않고 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, [email protected] 작성 :

이 문제를 해결하는 사람이 있습니까? Gatsby를 사용하면 의미가없는 것 같습니다.
다음으로 더 나은 점수를 즉시 제공하지 않는 경우.

다음 번호가 있습니까?
이 점수가 빠른 웹의 새로운 표준인지 궁금합니다.
정적이 아니며 JS가 없으며 이미지가 없을 가능성이 높습니다)

Next.js 웹 사이트-> https://masteringnextjs.com/ 77 모바일 점수. 많이
"Unused JS"의.

lighthouse-metrics로 더 나은 점수를 봅니다.
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://googlechrome.github.io/lighthouse/scorecalc/

Lighthouse 점수는 PageSpeed ​​Insights를 통해 사용하는 경우에도 일반적으로 많이 다릅니다. 예를 들어 https://www.gatsbyjs.org/의 경우 5 회 실행 후 64 ~ 88 개의 모바일 성능을 모두 받았습니다. 따라서이 문제를 추적하기 위해 계산기는 동일한 실행에서 다른 가중치의 결과를 확인하는 데 유용 할 수 있습니다 (참고 : 메트릭이 약간 다르기 때문에 FMP와 같은 일부 값은 이전 측정을 사용하여 가정해야 함).

추신 : 여기 gatsbyjs.org에 대한 PageSpeed ​​Insights의 두 실행을 비교했습니다.
실행 1-v6 : 67-v5 : 85
실행 2-v6 : 78-v5 : 87
가장 큰 영향은 두 실행 모두에서 70 점 미만이고 가중치가 25 % 인 새로운 메트릭 "총 차단 시간"에 의해 발생합니다.

네, @Pyrax 에 추가하려면 LCP (Largest Contentful Paint) 및 TBT의 무게 는 Lighthouse v6에서 각각

LCP

• 로드시 트리거 될 수있는 애니메이션 제거 (예 : 쿠키 💩 배너).
• gatsby-img의 tracedSVG 전환하는 것은 대부분의 페이지에 큰 영웅 이미지가 있기 때문에 약간 도움이되는 것 같습니다. (진짜 이유는 모르겠지만, 추가 조사없이. UX도 약간 향상됩니다.)

TBT

• 장기적으로 보면, Gatsby 번들링의 Unused JS 는 장기적으로 보면 가장 큰 컵릿 ( web.dev의 문서 백업) 인 것 같습니다. 페이지 수준 트리 쉐이킹이 확실히 개선 될 수 있습니까?

이 최근 Lighthouse 업데이트는 다음을 포함하여 모든 사람의 성능 점수를 망친 것 같습니다.

실제로 지워지지 않은 유일한 개츠비 사이트는 기본적으로 단일 페이지이고 99 % html과 같은 사이트입니다. 하지만 그것도 5 ~ 10 점 정도 떨어졌다.

그래도 대부분의 사람들은 반대를 보았습니다. 즉, Chrome 브라우저의 Lighthouse가 여전히 내 사이트에 대해 좋은 점수를 보여주고 있지만 PageSpeed ​​Insights에서 실행하면 성능 점수가 20-30 점 떨어집니다. 아마도 Chrome Lighthouse 버전 일 수도 있습니다. 뒤에 있습니까? Chrome은 최신 버전이며 내장 된 Lighthouse 버전을 확인하는 방법을 모르겠습니다 ...

이 최근 Lighthouse 업데이트는 다음을 포함하여 모든 사람의 성능 점수를 망친 것 같습니다.

실제로 지워지지 않은 유일한 개츠비 사이트는 기본적으로 단일 페이지이고 99 % html과 같은 사이트입니다. 하지만 그것도 5 ~ 10 점 정도 떨어졌다.

그래도 대부분의 사람들은 반대를 보았습니다. 즉, Chrome 브라우저의 Lighthouse가 여전히 내 사이트에 대해 좋은 점수를 보여주고 있지만 PageSpeed ​​Insights에서 실행하면 성능 점수가 20-30 점 떨어집니다. 아마도 Chrome Lighthouse 버전 일 수도 있습니다. 뒤에 있습니까? Chrome은 최신 버전이며 내장 된 Lighthouse 버전을 확인하는 방법을 모르겠습니다 ...

Lighthouse 버전은 감사 하단에 표시됩니다.

@dylanblokhuis 아,

@dylanblokhuis 아,

그렇지 않습니다. 어쨌든 아직. 최신 버전을 원하는 경우 npm에서 설치 한 다음 lighthouse https://yoursite.com --view 를 실행하면 Chrome 감사에서 사용하던 것과 동일한 형식으로 점수를받을 수 있습니다. :)

점수에서 큰 인기를 얻은 다른 사람에게는 # 24866도 관련이있을 수 있습니다. Gatsby가 청킹을 처리하는 방식에 겉보기에는 상당히 중요한 변화가있었습니다. 변경 사항이 확실히 의미가있는 것처럼 보이지만, 적어도 우리에게는이 변경 사항으로 인해 청크에 분산 된 코드가 commons 및 app 청크에 집중되었습니다. 훨씬 더 큰 js로드 / 파싱을 의미합니다.

여기서 가장 우려되는 점은 이러한 메트릭이 상대적으로 곧 페이지 순위에 영향을 미치기 시작할 것이라는 점입니다.

모든 제 3 자 요청 (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha)을 제거했으며 상대적으로 적은 점수 만 제공하므로 다른 작업이 진행 중입니다.

또한 Lighthouse 6를 로컬에서 실행하려는 모든 사용자를 위해 현재 Chrome Canary에서 사용할 수 있으며 7 월에 Chrome으로 출시 될 예정입니다.

첫째 : web.dev에서 작업하는 Google 엔지니어와 연락하여 이에 대해 물었습니다. 그것이 더 큰 설명으로 이어질지 확실하지 않지만 그들은 도움을 주려는 것 같습니다. 내가 그들과 채팅 할 수있게되면 후속 조치를 취하겠습니다.

내 성과 점수는 94-99에서 40-55로 떨어졌습니다. 😢

내 웹 사이트를위한 가장 큰 콘텐츠 페인트 는 대부분 큰 이미지가있는 페이지에 적용됩니다. 어떤 이유로 이미지를로드하는 데 14 초 정도 걸린다고합니다.

최소한의 Gatsby 시작 사이트 를 열면 이미지가있는 모든 페이지가 최대 70 초인 것 같습니다.

다음은 많은 이미지로 본 처음 두 개의 스타터입니다.

ghost.gatsby.org :

gcn.netlify.app :

그러나 Gatsby 스타터 블로그 는 98 개의 성능을 가지고 있습니다 (허용되며 일부 텍스트 만있는 매우 최소한의 페이지입니다).

gatsbyjs.com :

Chrome에서 이전 점수와 새 점수 비교

CLI를 사용하지 않고도 이전과 새 Lighthouse 방법 점수를 비교할 수 있습니다. 무엇이 변경되었는지 확인하는 것이 유용하다고 생각합니다.

이전 Lighthouse 테스트보기

이전 Lighthouse 점수를 보려면 브라우저 툴바 대신 Chrome 개발자 도구에서 Lighthouse Chrome 확장 프로그램을 실행하세요.

새로운 Lighthouse 테스트보기

크롬 확장 프로그램 바에서 아이콘을 클릭합니다.

내 페이지 변경

다음은 정확히 동일한 페이지에 대한 두 가지 점수입니다.

오래된 등대 (Chrome 개발 도구를 통해)

새 등대 (주소 표시 줄의 Chrome 확장 프로그램을 통해)

🤷‍♂️

@nandorojo 이미지에

이미지를 제거하는 옵션이 항상 가능한 것은 아니기 때문에 아마도 이러한 70 점은 이러한 유형의 페이지에 대한 일반적인 점수 일 것입니다.

그리고 사용자가 상호 작용을 더 빨리 시작할 수 있도록 로딩을 지연시키는 옵션은 트릭을 수행하지 않는 것 같습니다 (제 경우)

늦어서 죄송합니다. 저는 Lighthouse에서 일해 왔으며 가능한 한 잘 설명하려고 노력할 것입니다.

Chrome 개발자는 건강한 사이트를위한 필수 측정 항목 인 'Web Vitals'를 게시했습니다. 여기에는 많은 메트릭이 포함되어 있지만 핵심은 LCP (Largest Contentful Paint) , FID (First Input Delay) 및 CLS (Cumulative Layout Shift) 입니다. Lighthouse FID와 같은 도구의 경우 총 차단 시간 (TBT)으로 바뀝니다.

Lighthouse v6도 이러한 메트릭을 고려하여 변화했습니다. 이것은 Gatsby가 느리다는 것을 의미하지 않습니다. 몇 가지 다른 최적화가 필요할 수 있습니다.

이것이 변경된 방식입니다.

LCP에 대해 더 알고 싶다면 https://www.youtube.com/watch?v=diAc65p15ag를 확인하십시오.

그럼 개츠비에 대해 이야기합시다. Gatsby 자체는 여전히 매우 빠르며 더욱 개선하고 있습니다. MDX, Contentful의 서식있는 텍스트와 같은 페이지 빌더도 번들을 최적화 할 수 있도록 새 API를 만들고 있습니다. LCP를 최적화하면 많은 작업을 수행 할 수 있습니다. 글꼴 및 이미지를 사용할 때 느리게로드되지 않고 가능한 한 빨리로드되는지 확인하십시오. 이러한 자산은 사이트와 동일한 출처에서로드해야하며 CDN에서로드하면 안됩니다.

슬프게도 TBT는 해결하기 어려운 문제이며 React가 최적화하지 않는 문제입니다. TBT를 삭제하려면 preact 를 체크 아웃해야합니다. Preact는 React와 동일한 API를 가지고 있지만 자바 스크립트 풋 프린트가 더 작습니다. 그들은 다르게 일을하지만 React 컴포넌트는 호환됩니다. gatsby recipes preact 를 실행하여 설치합니다.

gatsbyjs.com 및 gatsbyjs.org를 프로파일 링 할 때 눈에 띄는 것은 TBT의 일부가되지 않도록 지금보다 조금 늦게 Google 애널리틱스 등을로드해야한다는 것입니다.

분석과 GTM을 연기하고 글꼴이 더 빨리로드되도록하여 .com을 살펴보면 이미 +17의 개선을 볼 수 있습니다. 믹스에 프리 액트를 추가하면 +6이 표시됩니다.

.org에 대해서도 동일한 작업을 수행 할 수 있습니다. 63 점부터 시작합니다. LCP 및 TBT를 최적화하면 75 점에 도달 할 수 있습니다.

이 문제로 무엇을해야할지 모르겠습니다. 여기서 할 수있는 일이 많지 않기 때문에 닫을 수 있다고 생각합니다. 다들 어떻게 생각하세요?

추가 통찰력을 위해 @wardpeet Ty.

우리는 Contentful을 사용하는 대규모 Gatsby 프로젝트에서이 문제를 많이 파헤 쳤으며 우리를 위해 여러 사이트에서 사용될 것입니다 (Gatsby 테마는 훌륭합니다). 이것을보고있는 다른 사람에게 도움이되는 경우 몇 가지 결과를 공유하겠습니다.

1. 우리는 매우 일반적이지 않을 수있는 상황이 있지만, Contentful 및 .find 에서 오는 이미지를 가져 오기 위해 useStaticQuery 를 사용해야하는 고유 한 상황도 아니라고 믿을만큼 충분히 보았습니다 .find 하나는 식별자로. 우리는 항상 이것이 틀렸다는 것을 알고 있었지만 사이트의 규모가 300 개 이상의 이미지로 커지고 LH6가 와서 우리를 때릴 때까지 눈에 띄게 처벌받지 않았습니다.

그 이유는 이미지가 리치 텍스트 임베드의 일부이고 페이지 쿼리 수준에서 해당 이미지에 대해 graphql 할 수 없기 때문입니다 (기본적으로 Contentful에 구문 분석 할 패키지가있는 json 필드). Webpack 번들 분석기를 사용할 때 우리는 방대한 JSON 파일 (약 720KB)을 발견하고 해당 쿼리의 데이터로 추적했으며, Webpack에서 대부분의 페이지에 사용하는 템플릿으로 그룹화되었습니다. 이것은 우리 사이트를 방문 하는 다운로드 한다는 것을 의미합니다.

우리 쪽에서는 큰 문제가 있지만 다른 누군가가 큰 정적 쿼리를 수행하는 경우 (물론 크기를 줄이기 위해 매개 변수를 전달할 수 없음) 이러한 상황을주의하고 번들 청크를 주시하십시오.

1. 우리는 접힌 부분 위에있는 이미지에 Gatsby 이미지에 대한 loading 소품을 사용하여 오늘 몇 가지 성공을 거두었습니다 (Hero 이미지). 우리는 가장 큰 콘텐츠가 포함 된 페인트 작업을 시도해 왔으며 일부 초기 테스트에서 좋은 결과를 얻었습니다. 내가 거의 놓친 중요한 부분이 있습니다. 최상위 이미지에 loading="eager" 를 설정하면 base64와 완전히로드 된 이미지 사이의 전환 때문에 해당 이미지에 대해 fadeIn={false} 도 설정하는 것이 좋습니다. 이미지는 LCP를 지연시키는 시간이 걸립니다.

다음은 제가 언급하고있는 소품 문서이며 fadeIn 에 대한 메모는 하단에 있습니다. https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

스크린 샷을 공유하고 싶지만 허용되는지 모르겠습니다. 죄송합니다. Chrome devtools를 사용하고 성능 패널을 보면 FP, FCP, FMP 및 LCP에 대한 "타이밍"행 아래에 멋진 작은 태그가 제공됩니다. 첫 번째 이미지를 비판적으로로드하도록 전환했을 때 성능 점수가 8 ~ 10 점 증가했을뿐만 아니라 내 경우에는 FMP 직후에 LCP 태그가로드되는 것을 볼 수 있습니다.

이 문제를 해결하는 데 도움이되기를 바라며 지금까지 응답 해 주신 모든 분들께 감사드립니다.

gatsbyjs.com 및 gatsbyjs.org를 프로파일 링 할 때 눈에 띄는 점은 TBT의 일부가되지 않도록 우리가 알고있는 것보다 조금 늦게 Google 애널리틱스 등을로드해야한다는 것입니다.

@wardpeet 분석과 GTM을 어떻게 연기하고 있습니까?

답장을 보내 주셔서 감사합니다. 쓸모있다. 아마도이 문제의 가장 좋은 결과는 새로운 Lighthouse의 각 메트릭에 대해 최적화하는 방법을 설명하는 문서 일 것입니다. 나는 우리 사이트가 사용자에게 빠르게 느껴지고 Gatsby 자체가 실제 사용자를 위해 사이트를 최적화하는 데 큰 역할을하고 있다고 확신합니다. 그러나 Google의 웹 바이탈이 페이지 순위를 알리기 시작하면 좋은 등대 점수를 얻는 것이 대부분의 사이트에서 미션 크리티컬이 될 것입니다.

@Jimmydalecleveland 우리는 마크 다운 내에서 데이터를 사용하여 필터를 구성하고 (즉, GraphQL을 사용하여 필터링 할 수 없음) 다른 조각을 사용하여 최적화 할 수 있도록 리소스의 모든 항목을로드해야하는 유사한 문제가있었습니다 (a 훨씬 작은 필드 하위 집합) 전체 리소스를로드 할 때와 필터링을 위해 모든 리소스를로드 할 때. 이것은 JSON으로 인해 우리의 번들 크기를 크게 줄였습니다.

@treyles 통계가 불완전하다는 것을 의미 할 수 있으므로 Analytics로드를 지연 시키려면주의해야합니다. 예를 들어보고 된 이탈률이 정확하지 않음을 의미 할 수 있습니다. 마케팅에서 지연을 허용하지 않는 스크립트 (픽셀, 분석, hotjar 및 태그 관리자)가 있지만 다른 스크립트 (예 : Intercom)는 괜찮고 최적화 할 가치가 있습니다. 이러한 스크립트를 지연하는 방법과 관련하여 타사에서 제공하는 스크립트는 일반적으로 비동기로드하지만 이것만으로는 충분하지 않습니다. 아마도 여러분이해야 할 일은이 스크립트를 여러분의 것으로 바꾸는 것입니다. window.load를 수신 한 다음 다운로드를 트리거합니다. 일부 스크립트는 초기화를 위해 window.load에 의존하고 스크립트를로드하는 데 사용한 경우 다시 실행되지 않으므로주의해야합니다. 따라서 수동으로 초기화해야합니다. 예를 들어 인터콤은 다음과 같습니다.

• 인터콤에서 제공하는 <script>...</script> degault를 제거했습니다.
• window.load 에 대한 리스너를 추가했습니다.
• 이 리스너 내에서 짧은 지연을 추가했습니다.
• lib async를로드 한 수정 된 버전 Intercom의 기본 스크립트를 트리거했습니다.
• 스크립트가로드 된시기를 확인하기 위해 폴링 됨 (인터콤은 신뢰할 수있는 이벤트를 제공하지 않음)
• 스크립트를 수동으로 초기화했습니다 (기본 스크립트에 의해 page.load에서 수행됨).

@wardpeet 매우 유용한 통찰력에 감사드립니다!

이 솔루션과 관련하여 :

글꼴 및 이미지를 사용할 때 느리게로드되지 않고 가능한 한 빨리로드되는지 확인하십시오. 이러한 자산은 사이트와 동일한 출처에서로드해야하며 CDN에서로드하면 안됩니다.

이것은 개츠비 이미지가 작동하는 방식에 반하지 않을까요? 또한 대부분의 CMS는 서버에서 이미지 변환을 처리하고 자체 CDN에서 호스팅됩니다. (좋은 것, imo). 그러나 우리가 자체 사이트에서 호스팅하면 역효과가 발생하지 않을까요?

@Undistraction이 말한 것에 페이지 랭킹 업데이트 에이 내용을 포함시킬 것입니다.

@Jimmydalecleveland 쿼리 해킹없이 콘텐츠가있는 리치 텍스트 내에서 개츠비 이미지로 작업하는 방법을 찾았습니다! 여기에 요점이 있습니다. 코드는 gatsby-source-contentful 에서 복사하여 붙여 넣었습니다. 기본적으로 GQL 외부에서 콘텐츠가 많은 유체 또는 고정 소품을 생성 할 수 있습니다. 콘텐츠가있는 리치 텍스트에 적합합니다.

또한 gatsby-source-contentful 에서 직접 API에 액세스 할 수 있도록 pull 요청을 생성했습니다.

나를 위해 뭔가 합산되지 않습니다. 나는 페이지 당 이미지에 대한 매우 단순한 웹 사이트를 구축했습니다. Im은 gatsby-image가없는 이미지에 SVG를 사용하고 Google 분석을 제거하려고 시도했지만 큰 차이는 없었습니다. 제 점수는 성능면에서 약 50-60이었습니다.

저에게 정말 혼란스러운 점은 홈페이지 (index.js)만이 매우 낮은 점수를 받고있는 반면 서비스 페이지 나 연락처 페이지와 같은 다른 페이지는 ~ 80 점을 받고 있다는 것입니다. 이 사이트를 상당히 일관되게 구축했기 때문에 페이지간에 큰 차이가 없지만 어떤 이유로 홈 페이지의 점수는 ~ 50 점이고 서비스 페이지의 점수는 ~ 80 점입니다.

앞서 언급했듯이 lighthouse v5에서는 점수가 ~ 90 점이었습니다. 이와 같은 단순한 사이트의 점수가 ~ 50 점이라는 것은 전혀 의미가 없습니다.

Btw, 스크롤없이 볼 수있는 이미지를 eager 로 설정해 보셨나요?
이렇게하면 지연로드가 비활성화되고 점수가 증가 할 수 있습니다. 흐림 또는 SVG
로딩 효과가 Lighthouse를 혼동 할 수 있습니다 (이 경우
알고리즘의 결함).

2020 년 6 월 13 일 토요일 오전 10시 48 분 t2ca [email protected] 작성 :

나를 위해 뭔가 합산되지 않습니다. 매우 단순한 웹 사이트를 구축했습니다.
페이지 당 이미지에 대해, 개츠비 이미지가없는 이미지에 SVG를 사용하고 있습니다.
나는 또한 구글 분석을 제거하려고 시도했지만 많은 것을 얻지 못했습니다.
차이, 내 점수는 성능에 대해 약 50-60이었습니다.

저에게 정말 헷갈리는 것은 홈페이지 만
(index.js)는 매우 낮은 점수를 받고 있지만
서비스 페이지 또는 연락처 페이지의 점수는 ~ 80 점입니다. 나는 이것을 만들었다
사이트는 상당히 일관 적이므로 큰 차이가 없습니다.
페이지에 있지만 어떤 이유로 홈 페이지의 점수는 ~ 50 점입니다.
서비스 페이지의 점수는 ~ 80 점입니다.

앞서 언급했듯이 lighthouse 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에 대한 초점이 이미지에 대한 관심을 가지고 보편적으로 취하는 올바른 접근 방식이 아니라고 생각합니다. 분명히 일화 적이지만 이미지가 콘텐츠에 중요하지 않는 한 모든 콘텐츠가로드되고 이미지가 나중에 희미 해지면 웹 사이트가 훨씬 빨라진다 고 느낍니다.

한 가지 일반적인 예는 Medium 기사입니다. 물론 디자인 결함이라고 말할 수는 있지만 대부분의 Medium 기사 (및 다른 많은 블로그)는 분위기 생성이나 풍경만을위한 상단의 큰 ol '이미지로 시작하며 게으른로드 여부는 상관 없습니다. .

Btw, 스크롤없이 볼 수있는 이미지를 eager 로 설정해 보셨나요? 이렇게하면 지연로드가 비활성화되고 점수가 증가 할 수 있습니다. 블러 또는 svg 로딩 효과는 Lighthouse를 혼란스럽게 할 수 있습니다 (이 경우 알고리즘의 결함).
…

지금 시도해 볼게요.

여기에서 좋은 진전이 있었던 것 같습니다. 아주 기본적인 변화로 57 점 에서 84 점으로 점수를 올렸습니다. 내 LCP는 12 초 에서 초로 변경 되었습니다.

즉, 일관성이 없습니다. 아래에서 설명 할 변경 사항을 적용한 이후로 내 점수는 69-84까지 다양합니다. 성능 점수에는 분명히 약간의 변동이 있습니다.

TLDR

먼저 @KyleAMathews 및 @Jimmydalecleveland가 제안한 것처럼 접힌 부분 위에있는 개츠비 이미지 구성 요소에 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 점 올랐습니다.

위의 예에서 이상한 점 : 왼쪽의 스크린 샷에는 기본 개츠비 이미지 동작이 있습니다 (페이드 인되고 eager 켜져 있지 않음). 그러나 성능 점수가 더 낮음에도 불구하고 , 하단의 작은 스크린 샷은 오른쪽 이미지보다 빠르게로드되는 것처럼 보입니다.

성능을 판단하는 방법에 대한 오류 범위 내에 있거나 @KyleAMathews가 언급했듯이 페이드 인 효과와 관련된 최종 버그 일 수 있습니다.

이미지 조각에서 _noBase64 설정 후

다음은 위의 예와 동일한 화면입니다. 그들은 모두 Gatsby Image에 loading="eager" , fadeIn={false} 소품을 가지고 있습니다. 또한 graqhql의 이미지 조각은 GatsbyImageSharpFluid_withWebp_noBase64

약간 설명 할 수 없지만 똑같은 페이지에서 등대 테스트를 반복해서 실행하고 있으며 84, 75, 69를 얻었습니다

좀 이상하지만 어쨌든 점수가 올라갔습니다.

여기서 라이트 하우스 알고리즘이 유난히 관대하다고 생각 해요 ^^

추가 조사 끝에 등대가 LCP 점수에 영향을 미치는 특정 요소에 대해 불평하고 있음을 발견했습니다.

내가 한 것은 단지 단락에 불과한이 요소를 옮기는 것이었고 내 점수는 80 점을 넘어 섰습니다. 단락을 이동하여 점수가 ~ 50에서 ~ 80으로 증가한 이유를 정확히 알 수 없습니다.

@nandorojo 철저한 글을

추가 조사 끝에 등대가 LCP 점수에 영향을 미치는 특정 요소에 대해 불평하고 있음을 발견했습니다.

내가 한 것은 단지 단락에 불과한이 요소를 옮기는 것이었고 내 점수는 80 점을 넘어 섰습니다. 단락을 이동하여 점수가 ~ 50에서 ~ 80으로 증가한 이유를 정확히 알 수 없습니다.

@ t2ca 이것은 내가 얻은 것입니다 (내 것이 헤더 태그 였지만). 하지만 어디로 옮겼습니까?

@ t2ca 이것은 내가 얻은 것입니다 (내 것이 헤더 태그 였지만). 하지만 어디로 옮겼습니까?

@michaeljwright 내가 가장 먼저 한 일은 단락을 삭제하고 등대 점수를 확인하는 것이 었습니다. 단락을 제거한 후 점수가 약 20 점 증가했습니다. 확인하기 위해 테스트를 여러 번 반복했습니다. 나는 또한 단락을 다시 넣고 추가 테스트를했고 내 통증이 다시 한 번 더 낮아졌습니다.

마지막으로 단락을 이동하기로 결정했습니다. Im은 div 내부에서 framer-motion을 사용하고 단락을 div 외부로 이동했습니다. 이것은 단락을 삭제할 때와 같은 결과를 제공합니다.

@ t2ca 나는 LCP가 우리 영웅 페이지의 모든 애니메이션에 불이익을

단락 태그가 LCP 인 LCP 점수는 다음과 같습니다.

애니메이션 :

애니메이션없이 :

@ t2ca 나는 LCP가 우리 영웅 페이지의 모든 애니메이션에 불이익을

단락 태그가 LCP 인 LCP 점수는 다음과 같습니다.

애니메이션 :

애니메이션없이 :

@ daydream05 확인 감사합니다!

헉헉

이것은 개츠비 이미지가 작동하는 방식에 반하지 않을까요? 또한 대부분의 CMS는 서버에서 이미지 변환을 처리하고 자체 CDN에서 호스팅됩니다. (좋은 것, imo). 그러나 우리가 자체 사이트에서 호스팅하면 역효과가 발생하지 않을까요?

아니요, gatsby-image는 로컬 이미지에서도 작동하므로 다른 CDN에서 호스팅 할 필요가 없습니다. 모든 것은 첫 번째 렌더 (뷰포트에있는 것)를 최적화하는 것입니다. 다른 도메인 / CDN에서 호스팅한다는 것은 새로운 연결 (dns resolve, tls handshake 등)을 열어야한다는 것을 의미합니다. 느린 장치에서는 최대 300ms가 걸릴 수 있으며 여전히 이미지를 다운로드해야합니다.

@Undistraction이 말한 것에 페이지 랭킹 업데이트 에이 내용을 포함시킬 것입니다.

사용자가 100을 무료로받을 수 있도록 Gatsby를 더욱 최적화 할 것입니다.

@ t2ca 나는 LCP가 우리 영웅 페이지의 모든 애니메이션에 불이익을

화면이 페인팅을 멈추지 않기 때문에 예상됩니다. 일반적으로 LCP는 CSS 애니메이션을 무시해야하지만 애니메이션을 수행하는 방법에 따라 다릅니다.

@ t2ca

사이트를 보여줄 수 있다면 개선 방법을 찾는 데 도움을 줄 수 있지만 아마도 이미지를 열성적으로 설정하고있을 것입니다.

뿡뿡

멋진 글! 등대 보고서에 대한 링크를 제공 할 수 있습니까?

화면이 그림 그리기를 멈추지 않기 때문입니다.

@wardpeet 이것에 확장 해 주시겠습니까?

@DannyHinshaw 등대에서이 설명을 받았습니다
"내 생각에 LCP는 이미지가 완전히로드되는 것을 신경 쓰고보고되는 ​​시간은 이미지가 처음 표시 될 때가 아니라 완전히로드 된 때입니다. 이번에는 점진적 이미지와 반복적 인 페인트로 인해 다를 수 있습니다. "

그리고이 링크는 아마도 도움이 될 것입니다.
https://web.dev/lcp/#when -is-largest-contentful-paint-reported

그 동안 시도해 볼 수있는 것은 LCP (Largest Contentful Paint)를 이미지에서 텍스트 (사치가있는 경우)로 변경하고 글꼴을 미리로드 / 프리 페치하고 이미지를 지연로드하는 것입니다. 제 경우에는 모바일에서 영웅 이미지의 크기를 줄여서 문제를 논의하는 동안 점수를 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/en-US/docs/Web/HTML/Preloading_content

화면이 그림 그리기를 멈추지 않기 때문입니다.

@wardpeet 이것에 확장 해 주시겠습니까?

물론 어떤 사이트인지 모르겠지만이 스레드에서 URL을 찾으려고했지만 힘들었습니다. LCP는 CSS 애니메이션 (전환, CSS의 애니메이션 소품)을 고려하지 않습니다. 그러나 반응 구성 요소를 전환하는 setTimeout / setInterval을 사용하는 콘텐츠가있는 경우이를 고려합니다. 후자의 접근 방식은 정말 나쁜 CLS 점수를 제공합니다.

따라서 영웅 텍스트 / 이미지에 애니메이션을 적용하려면. CSS 애니메이션을 사용하세요.

안녕,

내 프로젝트가 Google Page Speed ​​Insights, Google Lighthouse 감사 등에서 낮은 점수를받은 이유를 알아 내려고했습니다.

처음부터 시작하기에는 문제가 무엇인지 잘 모르겠습니다. 이 스타터 / 테마를 사용하여 시작했습니다 : https://github.com/alexislepresle/gatsby-shopify-theme

나는 주로 bulma에서 chakra-ui로 이동하는 것과 같은 CSS를 변경하는 과정에 있습니다.

이것은 내 저장소입니다 : https://github.com/Chizzah/genesis-style
모든 계정 항목과 gatsby-plugin-appollo-shopify 항목을 제거하려고 시도했지만 변경되지는 않았습니다.

다음은 라이브 링크입니다 : https://genesis-style.netlify.app

내가하는 일은 아무것도 바꾸지 않는다. 처음부터 시작할 필요가 없습니다. 누군가 나에게 힌트 나 무언가를 줄 수 있다면 나는 그것을 고맙게 생각할 것이다.

Gatsby가 무료로 90-100을주는 데 너무 익숙해 졌나 봐

좋은 등대 점수를 얻기위한 토론이 필요하므로이 스레드에 감사드립니다. v6에서는 새로운 LCP 메트릭으로 인해 최고 점수가 더욱 어려워졌습니다. 내 사이트 (https://www.jamify.org)가 Lighthouse v6에서 ~ 100에서 ~ 70으로 떨어졌습니다.

데스크톱에서 100으로 되돌리려면

• 필요하지 않은 배경 이미지 제거 (LCP로 잘못 선택되었으므로)
• 이미지 크기 최적화
• gatsby-image 을 loading="eager" 및 fadeIn=false
  (블러 업 효과가 마음에 들기 때문에 정말 부끄럽습니다.)

모바일에서는 5 초의 LCP로 인해 여전히 80에서 멈춰 있습니다. 이는 특히 모바일 용으로 이미지 크기를 적절하게 조정하여 개선 할 수 있습니다.

전반적으로 이러한 최적화는 상당히 실현 가능하지만, 블러 업이있는 지연 로딩 이미지 또는 좋은 Lighhouse 점수 중 하나를 선택해야한다는 점이 매우 불행합니다. : roll_eyes :

아직 lighthouse v6.1에 대한 테스트를 수행 한 사람이 있습니까? 내 성과 점수가 향상되었습니다.

블러 업 LCP 문제에 대해 Google에서 Addy에게 질문했으며 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
• 내 사이트 TBT : 2200ms
• @styxlab 사이트 TBT :

TBT에 대해 600이 넘는 것은 빨간색이고 계산기에 따른 무게는 25 %이므로 중요한 요소입니다. TBT는 FCP와 Time to Interactive 사이에 실행하는 데 50ms 이상 걸리는 함수로 인해 발생합니다.

위 스크린 샷은 내 사이트의 프로필입니다. Chrome에서 Lighthouse를 사용하는 경우 추적보기 버튼을 클릭하여 결과를 프로필 탭에로드하여 동일한 내용을 볼 수 있습니다. 모서리에 빨간색 플래그가있는 FCP 이후의 모든 작업은 TBT에 포함됩니다. 나는 아직 작업이 무엇인지 파고 들지 않았기 때문에 아마도 Gatsby에 대해 더 많은 지식을 가진 누군가가이 분야에서 도움을 줄 수 있고 아마도

@IanLunn 은 흥미로운 흔적입니다. 그 작업이 무엇인지 알 수 있었습니까?

각 개츠비 사이트의 JS 양과 브라우저의 메인 스레드에서 얼마나 비싸지는지간에 상관 관계가있을 수 있습니다. 그러나 토론의 여지가있을 수 있다고 생각합니다. Gatsby가 쿼리와 스크립트를 모두로드하는 방식에 따른 영향을 "완화"하는 데 도움이 될 수있는 방법이 있습니까?

현재 제가 더 잘 이해하고자하는 세 가지 영역이 있습니다.

• Gatsby는 얼마나 많은 스크립트가 있는지에 관계없이 필요한 모든 스크립트에 대해 기본적으로 <link rel=preload/> 를 추가합니다 ( PRPL 패턴에 따라 ). 나는 측정 된 FCP에서 약간의 차이를 발견했습니다 (매우 놀랐습니다). 그러나 FCP / LCP를 제거 할 때 주로 FCP / LCP 사이의 차이에 있습니다 (아마도 다른 변경없이 수행하는 것이 밝은 생각이 아닙니다). 등대에 관한 이번 호에서는 후자에 대해 논의합니다.
• 쿼리는 결국 메인 스레드에서 평가되는 JSON (page-data.json 및 정적 쿼리의 경우 해시 된 것)을 생성합니다. https://github.com/gatsbyjs/gatsby/issues/18787을 참조 쿼리 크기에 대한 성능 예산 은 당연히 환영받을 것입니다).하지만 데이터는 재수 화 프로세스까지 실제로 필요하지 않습니까?
• 실제 청크는 </body> 끝에 <script src=foo.js async /> 로 추가됩니다. 즉, 브라우저가 HTML 파싱을 마치 자마자 (추적에 곧 표시되어야 함) 해당 스크립트를 파싱하고 실행하기 시작합니다 (이미 사전로드되었으므로). 메인 스레드가 모든 자바 스크립트를 구문 분석하고 실행하도록 요청되므로 긴 작업이 필연적으로 발생합니다. 메인 스레드를 차단하지 않도록이 문제를 처리하는 더 좋은 방법이 있습니까 (적어도 해당 스크립트가 구문 분석을 시작하는 _when_)? 입력 피드백을 지연시키지 않고 (따라서 TTI에 해를 끼치 지 않고) 주 스레드를 차단하지 않는 (따라서 TBT에 해를 끼치 지 않는) 증분 소규모 작업에서이를 수행 (파싱 또는 실행) 할 수있는 방법이 있습니까?

지금은 사실이지만 Gatsby 사이트는 LCP가 아직 gatsby-image 의 LQIP 패턴을 인식하지 못하기 때문에 약간의 불이익을 받고 있습니다. Lighthouse v5와 비교 한 Javascript) 등대 팀의 로드맵에는 현재 점수에서 개선 될 부분이 없다고 생각합니다.

@juanferreras 가장 큰 작업은 domready / ready.js (타사) 인 것으로 보입니다. Lighthouse가 자바 스크립트에 페널티를주는 것에 대한 귀하의 진술이 옳다는 느낌을 받았으며 Gatsby에서 작은 최적화가 가능할 수도 있지만 해결할 수있는 것은 아닙니다.

이것이 Lighthouse에서 진행되는 방식이라면 적어도 TBT의 무게를 줄이거 나 원하는 테스트 환경을 설정하는 옵션을 제공하도록 요청하고 싶습니다. 예산 전화를 기준으로 점수를 제공하는 것이 테스트중인 사이트에 항상 적합한 것은 아닙니다. 예를 들어 예산 전화기는 75 점을 받지만 사용자의 95 %가 90 점을받는 고급 전화기는 예, 상사 / 고객에게 예를 보여줄 수 있어야합니다.

• 쿼리는 결국 메인 스레드에서 평가되는 JSON (page-data.json 및 정적 쿼리의 경우 해시 된 것)을 생성합니다. # 18787을 보라. 그러나 우리가 메인 스레드를 차단하지 않는 대안을 발견하지 못한 것 같다 (또는 존재한다면). 데이터가 클수록 성능 저하가 더 많이 발생합니다 (따라서 쿼리 크기에 대한 성능 예산 은 당연히 환영받을 것입니다).하지만 데이터는 재수 화 프로세스까지 실제로 필요하지 않습니까?

@juanferreras , 메인 스레드에서 json 데이터를 파싱하는이 문제와 관련하여 떠오르는 것은 웹 작업자입니다. Gatsby는 클라이언트에서 사용 가능한 경우 웹 작업자를 등록하고 이러한 종류의 것들을 버퍼링 할 수 있습니다. 재수 화 프로세스는 실제로 즉시 필요하지 않으므로 가능하다고 생각합니다.

웹 작업자는 ie10을 포함한 주요 브라우저에서 지원됩니다.

… 우리는 모바일에서 나쁜 점수를받는 가장 큰 이유이자 해결하기 가장 어려운 TBT를별로 보지 않습니다.

Total Blocking Time과 관련이 있다고 생각되는 것을 추가하고 싶습니다. Webpack 번들 분석기로 번들을 검토 한 후 정적 쿼리의 데이터가 JavaScript 번들에 포함되어 있음을 확인했습니다. 그럴만 한 이유가 있다고 확신하지만 낮은 TBT에 대해 작동합니다.

TBT는 특히 React가이를 위해 구축되지 않았기 때문에 해결하기 어려운 문제입니다. preact로 이동하는 것은 좋은 첫 단계입니다. 우리는 앞으로 몇 달 동안 TBT를 점점 더 개선 할 것입니다. 우리는 Gatsby가 정말 작은 공간을 갖기를 바랍니다.

개츠비 버전> 2.24.0에서는 개선 된 폴리 필 지원을 제공하여 IE11과 같은 레거시 브라우저에서만 폴리 필을로드합니다. 또한 며칠 전에 웹팩 (@MarkosKon)에서 정적 쿼리를 제거했습니다.

@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 초). 불평하는 장식용 헤더 이미지 (개츠비 배경 이미지 사용)입니다.

내 웹 사이트를 보면 Webpack 런타임은 자바 스크립트 실행 시간이 가장 많습니다. 사용자가 페이지와 상호 작용을 시작할 때까지 페이지에 필요하지 않은 것.

Gatsby는 이러한 모든 리소스 (청크)를 한 번에로드하는 것 같습니다. js 파일 자체는 매우 작으며 로더이므로 파일을 전달하는 데 2ms가 소요된다는 것을 알 수 있습니다. 그러나 파일 자체는 청크와 템플릿 파일을로드합니다.

사실, 청크 파일을 검사 할 때 모든 파일이 동적 임포트라는 것을 알게되었습니다. 필요한 경우에만로드되기를 바라지 만 기본적으로 모두로드됩니다. 이 동작은 내가 기대하는 것이 아닙니다.

Gatsby-Image 대신 이미지를 직접 사용하고 해상도와 압축을 줄이는 것과 같이 헤더 이미지를 상당히 최적화했습니다. 다만, Safari가 WebP (grr)를 지원하지 않는 어려운 방법을 방금 발견했습니다. 그리고 Lighthouse의 웹 버전은 적어도 "숨겨진"개발 사이트에서 Chrome에 내장 된 것보다 훨씬 덜 관대합니다. 시간이 지나면 집계 된 사용자 데이터가 실시간으로 도움이되는지 여부를 알 수 있습니다. 실제로 Moto G5를 사용하는 사람이 그렇게 많은지 확신 할 수 없습니다!

@derykmarl 곧 지원 될 예정입니다 : https://www.macrumors.com/2020/06/22/webp-safari-14/
Apple이 널리 퍼진 이미지 형식을 지원하는 데 시간이 많이 걸린 이유를 모르겠습니다.

나는 pagespeedinsight가 점수 계산 방법을 에뮬레이트한다는 것을 읽었습니다. 보고서를 더 빨리 얻을 수 있도록 네트워크를 조절하지 않는 것 같습니다. 개인적으로 https://lighthouse-metrics.com/을 사용하지만 아직 6.1을 지원하지 않습니다.

lighthouse 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에서 매우 좋은 수를 유지했습니다 (스크립트의 상대적 크기 때문일 수도 있습니다. 여기서 gatsby.com에는 PSI에 따라 약 628.3kb의 스크립트가 있습니다. reatjs.org 466.1kb) , nextjs.org 만 216.8kb)

(이것은 분명히 단일 실행이며 실제 비교로 사용해서는 안되지만 추세는 여러 실행에서 매우 일관 적입니다).

Javascript ™의 전체 비용으로 인해 점수 차이가 대부분입니까? Gatsby 팀이 프로세스에 대한 통찰력을 공유 할 수있는 좋은 기회가 될 수있는 새로운 웹 사이트를 최적화하는 경우, Gatsby 프레임 워크가 내부적으로 자바 스크립트를 처리하는 방법에 추가 할 수있는 마법이 많지 않습니다.

@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 , 현재로서는 수정이 없습니다. 왜냐하면 프로덕션의 개츠비는 재수 화 오류에 대한 개발 도움말을 제공하지 않기 때문에 재수 화 중에 스타일이 재생성되는 이유를 정확히 알 수 없기 때문입니다.

즉, 개츠비의 프로덕션 빌드에서 비활성화되어 있기 때문에 재수 화 중에 차이점을 가리키는 React의 콘솔 로그가 없습니다.

진행중인이 작업의 목적 # 25729는 개발중인 진정한 SSR을 실행하는 것이므로 그 이유를 알 수 있습니다. 개츠비 팀을 포함하여.

BTW, gatsby build --no-uglify 로 Gatsby 사이트를 구축하여 React의 개발 버전으로 사이트를 구축하여 로그를 볼 수 있습니다. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR은 앞으로 이와 같은 작업에 큰 도움이 될 것입니다!

따라서 사용자 지정 CSS 변수로 dark-light 모드를 구현하는 동안 내 사이트를 @emotion 및 theme-ui 에서 linaria 로 마이그레이션하기로 결정했습니다 theme-ui

목표는 블로킹 시간 / 메인 스레드 / js와 관련된 css 는 더 이상 런타임에 평가되지 않고 빌드 시간에 컴파일됩니다 (실제로 linaria 는 gatsby 이와 관련하여 @emotion 보다 gatsby 문)

이 프로세스는 완전히 매끄럽지 않습니다. @emotion 했던 대부분의 작업은 linaria 로만 작동하지만 다른 일부는 작동하지 않으며 사용자 지정 CSS를 통해 다시 작성하거나 다시 구현해야합니다. 변수

개츠비에 대한 DX 경험은 __bad__이며 핫 리로딩이 작동하지 않습니다 (브라우저가 연결이 끊어진 것처럼 보이기 때문에 변경시 중지했다가 다시 시작해야 함). 전반적으로 프로세스가 좋았습니다. @emotion 런타임 능력에서 정말로 필요합니까?

__ 즉, 등대 메트릭은 매우 유사합니다 __

두 개의 netlify 배포를 비교할 수 있으며 실제로 @emotion 사이트는 70이 높고 linaria 사이트는 중저가 70입니다.

말할 것도없이 나는별로 흥분되지 않는다

번들 분석 :

• 사이트 문서가 14Kb에서 28kb로 증가했습니다.
• 프레임 워크 스크립트는 38.7kb에서 동일하게 유지되었습니다.
• 앱 스크립트가 58.2kb에서 46.1kb로 감소했습니다.
• 그리고 네 번째 스크립트 ( component--content.. . 이제 20bae078.. )가 44.2kb에서 46.8kb로 변경되었습니다.

그래서 js의 스타일이 css의 스타일로 이동했다고 가정하지만 (~ 12kb는 중요한 IMO), 이것은 등대 메트릭에 실질적인 영향을 미치지 않았습니다 (중요한 것은 아닌가요?).

그래서, 저는 linaria 이동하는 것이 의미가 없다고 말하는 것이 아닙니다. 누군가가 똑같이하고 더 나은 결과를 얻는다고해도 놀라지 않을 것입니다 (이론상 이것은 케이스 (?)). 하지만 내 손에 그 과정은 가치가 없었습니다.

그래도 앱 스크립트를 탐색하여 js 번들을 줄이는 방법을 알아 내려고 새로운 문제를 열었습니다 https://github.com/gatsbyjs/gatsby/issues/26655

개츠비에 대한 DX 경험은 나쁘고 핫 리로딩이 작동하지 않습니다 (브라우저가 연결이 끊어진 것처럼 보이기 때문에 변경시 중지했다가 다시 시작해야 함). 전반적으로 프로세스가 좋았습니다. @emotion 런타임 능력에서 정말로 필요합니까?

@kuworking 비슷한 문제가 발생했지만 2.24.9 보다 새로운 gatsby 버전에서만 발생했음을 알았습니다. 원인이 동일한 지 확실하지 않지만 사람들이 문제 # 26192에서 이야기하고 있음을 아는 데 도움이 될 것이라고 생각했습니다.

@kuworking 비슷한 문제가 발생했지만 2.24.9 보다 새로운 gatsby 버전에서만 발생했음을 알았습니다. 원인이 동일한 지 확실하지 않지만 사람들이 문제 # 26192에서 이야기하고 있음을 아는 데 도움이 될 것이라고 생각했습니다.

나는 몇 주 동안 "gatsby": "2.24.14" 와 (과) 함께 있었으며 지금까지 linaria 에서만 이것을 경험했습니다.
그러나 이것을 알면 이것이 알아낼 때까지 개츠비를 업데이트하지 않을 것입니다. 감사합니다 👍

내가 제안하는 무엇을 의미 @kuworking하면 다운 그레이드 어쩌면 경우 그입니다 2.24.9 다음 개발 - 서버 중지 문제도 함께 발생하지 것입니다 linaria ; 그러나 그것은 단지 아이디어입니다. 그게 사실인지 궁금합니다.

개츠비에 대한 DX 경험은 나쁘고 핫 리로딩이 작동하지 않습니다 (브라우저가 연결이 끊어진 것처럼 보이기 때문에 변경시 중지했다가 다시 시작해야 함). 전반적으로 프로세스가 좋았습니다. @emotion 런타임 능력에서 정말로 필요합니까?

빠른 새로 고침 을 시도해 보셨습니까?

저는 최근 TBT 및 LCP를 개선하기 위해 프로덕션 개츠비 사이트 (~ 120 페이지)를 마이그레이션했습니다. 우리 사이트는 svgr로 생성되고 material-ui 스타일을 사용하여 스타일이 지정된 반응 svg 구성 요소를 사용하여 svg 무거운 것입니다. 평균 성능 결과는 초기 점수의 + -5 범위 (v6 이전 ~ 85에서 ~ 45 모바일 성능 감소)였으며 마이그레이션이 테마를 사용하는 데 상대적으로 고통스럽지 않았지만 빠른 새로 고침으로 마이그레이션해야했습니다. 아니.

솔직히 말해서 일반적인 "사용하지 않는 자바 스크립트 제거"등대 경고 외에 시도 할 수있는 다른 최적화 나 더 자세한 측정 항목이 없다는 점에 약간 실망했습니다.

속도는 우리가 개츠비를 선택한 주된 이유 중 하나이며 페이지가 여전히로드 속도가 빠르지 만 통찰력 점수가 그렇게 큰 히트를 치면 SEO 관점에서 정당화하기가 어렵습니다.

귓속말 : NextJS로 전환했고 더 좋은 점수를 얻고 있습니다 🤭

귓속말 : NextJS로 전환했고 더 좋은 점수를 얻고 있습니다 🤭

Svelte는 어떻습니까?

Gatsby 개발자가 로드맵 (예상 된 것 이외)에서 특정 중요성 / 우선 순위를 부여하고 있는지 여부를 아는 것이 좋습니다. 왜냐하면 즉각적인 해결책은 없지만 아마도 어떤 종류의 미래 방향과 구현에 초점을 맞춘 것이라고 가정하기 때문입니다. 이것이 아니면 그것이

개츠비는 gatsby-node *로 컴파일을하기 때문에 그 부분을 늘리고 클라이언트 부분을 디 레버리지하는 방법을 모색하고 있는지 궁금합니다.

* 사용하던 pageContext (게시 된 모든 게시물에 대한 데이터)를 줄이기 위해 현재 대부분의 데이터를 json 파일에 저장하고 있습니다 ( gatsby-node ). 필요한 경우 사이트에서 가져 와서 번들 크기를 줄이면서도 논리적으로 느껴집니다.

등대 점수에 너무 얽매이지 마세요. 특히
다른 사이트와 비교 한 벤치 마크로, 우리가해야 할 목표가 아닙니다.
만점을 얻기 위해 노력합니다.

최근까지 개츠비가 순수한 100을 기록한 것은 아닙니다.
해결해야 할 몇 가지 문제이지만 현재 SEO 게임은 속도와 콘텐츠입니다.
더하기 링크, 우리는 그것을 다룹니다.

내 2 센트.

2020 년 8 월 28 일 금요일 16:57 kuworking, [email protected] 작성 :

귓속말 : NextJS로 전환했고 더 좋은 점수를 얻고 있습니다 🤭

Svelte는 어떻습니까?

Gatsby 개발자가이 문제를 구체적으로 제공하는지 여부를 아는 것이 좋습니다.
로드맵의 중요도 / 우선 순위 (예상
하나), 즉각적인 해결책이 없다고 가정하기 때문에
이것 또는 저것에 초점을 맞춘 미래 방향과 실행의 종류

gatsby는 gatsby-node *로 컴파일을하기 때문에
그 부분을 늘리고 클라이언트 부분을 디 레버리지하는 방법을 모색하고 있습니다.

* 내가 사용했던 pageContext를 줄이려면 (모든
게시 된 게시물), 나는 현재 (개츠비 노드를 통해) 가장 많이 저장하고 있습니다.
json 파일의 해당 데이터 중 필요한 경우 사이트에서 가져옵니다.
번들 크기를 줄이면서도 더 논리적으로 느껴집니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

응답이 늦어 죄송합니다. 성능에 많은 부분이 있으며로드 메트릭은 퍼즐의 작은 조각 일뿐입니다. 우리는 이번 분기와 다음 분기에 Gatsby를 더 작게 만들고 TBT를 줄이기위한 동기를 부여 받았습니다. 현재 가장 큰 문제는 React 번들 크기, MDX, 대형 페이지 (컨텐츠 / 스타일링), 추적 스크립트 및 첫 번째로드의 주요 컨텐츠 인 글꼴 / 이미지입니다.

현재로드 시간을 개선하고 분석을 연기 할 수있는 방법을 알아보기 위해 gatsby-image 및 분석 스크립트를 조사하고 있습니다.

슬프게도 나는 어떤 추정도 할 수 없습니다. 또한 .com 사이트와 고객을 살펴보고 일반적인 문제가 무엇인지 확인하여 이러한 최적화를 gatsby 또는 플러그인에 적용 할 수 있습니다.

편집하다:

우리가 개선 할 수있는 방법을보기 위해 여러분 모두가하고있는 일에 대한 더 많은 통찰력을 얻기 위해 여러분의 소스 코드를 살펴 보게되어 기쁩니다.

내가 찾을 수있는 모든 개선 팁을 모 으려고 노력했던 reddit 게시물을 만들었습니다. 더 많은 팁을 얻을 수 있다면 목록을 작성하십시오.

개츠비 이미지 (홈 히어로 이미지 및 배경 이미지) 만 제거하면 10 ~ 20 점에서 점수가 향상됩니다.

최근 테스트에서 tracedSVG 실제로 가장 큰 콘텐츠가 포함 된 페인트의 성능 점수가 크게 향상된다는 사실을 발견했습니다. Lighthouse에서이 문제가 해결 될 것이라고 생각하지만, 지금은 SVG가 전체 해상도 이미지와 동일한 크기로 간주되기 때문에 이런 일이 발생하므로 SVG가 LCP 대상인 SVG에서 전체 이미지로 절대 교체되지 않습니다.

base64를 사용할 때 해상도가 작기 때문에 LCP 후보가 아니므로 Lighthouse는로드 될 때마다 전체 해상도 이미지를 사용합니다.

따라서 추적 된 SVG의 모양이 마음에 들지 않는다면 (개인적으로 선호 함) 시도해 볼 수 있습니다.

v5가 v6보다 더 나은 결과를 얻는 이유는 무엇입니까? NextJS를 사용하고 있으며 결과는 항상 60에서 85로 변경되었습니다.

+1

나는 개츠비 이미지 후속 작업을 해왔다. 아직 100 %는 아니지만 구성 가능한 버전을 작성해야 자신 만의 개츠비 이미지 풍미를 만들 수 있지만 대부분의 나쁜 등대 점수를 수정할 수 있습니다.

이미 사용할 수 있지만 아직 전투 테스트를 거치지 않았습니다.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

npm install --save @wardpeet/gatsby-image-nextgen 설치할 수 있습니다. 현재 gatsby-image 사용자를위한 compat 레이어 가 있습니다.

아직 지원되지 않는 항목 :

• 개체 맞춤은 구성 요소 외부의 CSS에 의해 수행되어야합니다.
• 예술 방향

현재 개츠비 이미지 데모 :
사이트 : https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights : https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
webpagetest : https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

새로운 gatsby-image-nextgen 데모 :
사이트 : https://gatsby-image-nextgen.netlify.app/
pagespeed-insights : https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
webpagetest : https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet 현재 데모에 대한 pagespeed-insights 링크는 nextgen으로 이동하여 동일한 점수를 표시합니다.
멋진 일, btw. 진행 상황을 보는 것이 정말 흥미 롭습니다.

고쳐 주셔서 감사합니다!

이 업데이트는 이전에 연결하지 않은 것을 지적했습니다. 저는 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 (gzipped가 아님) 만로드합니다.
3. 자리 표시자가 처음로드 될 때만 호출되고 캐시 된 이미지가 즉시로드되는지 확인합니다.
4. 비동기 디코딩으로 블러 업 애니메이션 수정

자신 만의 래퍼를 만들 수있는 컴포저 블 이미지 구성 요소가 얼마나 필요한지, 그리고 실제로 아트 디렉션을 사용하고 있으며 기본적으로 개츠비 이미지 내부를 원하십니까? 내 첫 번째 아이디어는 기능을 비활성화하는 것이었지만 구성 가능한 개츠비 이미지로 활성화하여이를 지원하기 위해 고유 한 이미지 구성 요소를 만들어야합니다.

최신 데모 : https://gatsby-image-nextgen.netlify.app/

@wardpeet 대단합니다! 나는 개츠비 이미지의 아트 디렉션에 크게 의존합니다. 하지만 예 / 부드러운 업그레이드 경로도 괜찮을 것 같아요!

저는 항상 모바일에서 99 점을 받았습니다. 지금은 76 점입니다. 저의 LCP는 7.0이고 저의 영웅 이미지를 제외하고는 모든 것이 훌륭합니다. 말이 안 돼. 휴대 전화에서 내 사이트를 열면 엄청나게 빠릅니다. 사람들은 당신이 알고있는 것에 놀라지 않습니까? 또한 내 이미지를 webp 또는 기타에 넣으라는 메시지가 표시되지만 이미 childImageSharp_withWebp를 사용하고 있으므로 이해하지 못합니다. Gastby Image와 background-image가 lighthouse와 pagespeedinsight에서이 새 버전에서 작동하지 않는 것을 시작하고 있습니다. 내 마음이 흔들렸다. 나는 가서 애니메이션을 죽이고 모든 이미지의 크기를 절반으로 조정했지만 한 지점까지 움직이지 않았습니다. 나는 이것을 읽고 있는데 나를 도울 것이 아무것도 보이지 않는다 .... 아, 방금 올려다 보았다 ... 나는 @wardpeet 내 생각에 뭔가 👍🏻

@davidpaulsson 마음에 당신이 이것을하는 방법에 대한 예를 공유합니까? 새로운 개츠비 이미지로 아트 디렉션이 여전히 가능하기 때문에 몇 가지 수동 단계를 수행해야합니다.

@davidpaulsson 마음에 당신이 이것을하는 방법에 대한 예를 공유합니까? 새로운 개츠비 이미지로 아트 디렉션이 여전히 가능하기 때문에 몇 가지 수동 단계를 수행해야합니다.

확실한! 지금 이렇게 사용합니다

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

return <Img fluid={artDirection} />

@wardpeet 안녕하세요 워드. blurha.sh 가 gatsby 이미지 nextgen에 유용 할 수 있습니까?

@wardpeet 나는 gatsby-image-nextgen 플러그인을 사용했고 실제로 내 LCP 시간을 향상 시켰습니다 (~ 5 초에서 ~ 1.5 초로 줄였습니다). 감사합니다!

그러나 우리는 또한 @davidpaulsson 이 사용하는 것과 유사한 아트

nextgen 플러그인으로이를 가능하게하는 데 필요한 수동 단계에 대해 자세히 설명해 주시겠습니까? 다시 한 번 감사드립니다!

@Jimmydalecleveland 감사합니다 지미! GatsbyImageSharpFluid_withWebp 를 GatsbyImageSharpFluid_withWebp_tracedSVG 로 대체하면 새 Gatsby Webiste의 성능 점수가 크게 향상되었습니다. 나는 54 % 이하를 얻었고 이제 tracedSVG로 80 % 이상을 얻고 있습니다. 그것은 엄청난 개선입니다 💯

최근 테스트에서 tracedSVG 실제로 가장 큰 콘텐츠가 포함 된 페인트의 성능 점수가 크게 향상된다는 사실을 발견했습니다. Lighthouse에서이 문제가 해결 될 것이라고 생각하지만, 지금은 SVG가 전체 해상도 이미지와 동일한 크기로 간주되기 때문에 이런 일이 발생하므로 SVG가 LCP 대상인 SVG에서 전체 이미지로 절대 교체되지 않습니다.

base64를 사용할 때 해상도가 작기 때문에 LCP 후보가 아니므로 Lighthouse는로드 될 때마다 전체 해상도 이미지를 사용합니다.

따라서 추적 된 SVG의 모양이 마음에 들지 않는다면 (개인적으로 선호 함) 시도해 볼 수 있습니다.

@abdullahe 이전에 확인한 적이 있으며 캔버스에 대한 종속성이 있으며 노드 캔버스는 매우 안정적이지 않습니다. 아니면 적어도 과거는 아니 었습니다. 다시 고려하면 알려 드리겠습니다. :)

@guydumais 는 loading="eager" 를 넣어야 점수도 변경됩니다.

@BenjaminSnoha & @davidpaulsson 나는 약간의 예를 공유 할 것이다. 이미지 간의 종횡비가 가로에서 세로로 변경되는 경우 아트 디렉션의 가장 큰 문제입니다.

@wardpeet @wardpeet/gatsby-image-nextgen 와 함께 gatsby-remark-images @wardpeet/gatsby-image-nextgen 를 어떻게 사용합니까? gatsby-config.js 에서 플러그인으로 단순히 가리키는 경우입니까, 아니면 gatsby monorepo에 병합 될 때까지 불가능합니까?

이것이 lighthouse와 관련이 없을 수도 있지만 왜 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 @wardpeet/gatsby-image-nextgen 를 어떻게 사용합니까? gatsby-config.js 에서 플러그인으로 단순히 가리키는 경우입니까, 아니면 gatsby monorepo에 병합 될 때까지 불가능합니까?

이 플러그인에도 remark를 이동하겠습니다. :)

@MelleNi 그렇지 않습니다, 나는 그것이 필요하다고 생각하지 않지만 우리는 그것을 고려하게되어 기쁩니다.

# 27950에서 우리가 배송하는 제품을 볼 수 있습니다.

@wardpeet @wardpeet/gatsby-image-nextgen 와 함께 gatsby-remark-images @wardpeet/gatsby-image-nextgen 를 어떻게 사용합니까? gatsby-config.js 에서 플러그인으로 단순히 가리키는 경우입니까, 아니면 gatsby monorepo에 병합 될 때까지 불가능합니까?

이 플러그인에도 remark를 이동하겠습니다. :)

속도가 많이 향상되는 것을 보았습니다.

그러나 Gatsby의 자바 스크립트를 비활성화하지 않고 (그리고 특정 기능을 수동으로 다시 통합하지 않으면) 99-100을 얻을 수 없다는 것을 알았습니다. fadeIn={false} 를 사용하지만 image-nextgen을 사용하여 이전 Gatsby 이미지가 자바 스크립트없이 작동하도록 할 수 있습니다. (어쩌면 내가 뭔가를 놓치고 있고, 절대적으로 가능합니까?) 이제 자바 스크립트 없이는 nextgen 없이는 99 아래로 떨어지지 않습니다.

나는 자바 스크립트를 비활성화하는 것이 Gatsby의 아이디어를 무너 뜨린다는 것을 이해합니다.

흥미롭게도 자체 호스팅 글꼴 (fontsource) 사용을 중단하고 "시스템"글꼴로 전환했을 때 모바일 성능 점수 (~ 70 ~ 90)가 향상되었습니다.

@wardpeet 아트 디렉션으로 구성 가능한 이미지 구성 요소를 만드는 방법의 예를 공유 할 수 있습니까? 나는 @BenjaminSnoha & @davidpaulsson 과 같은 배를 타고 있으며 내 프로젝트에서 구성 가능한 구성 요소를 만드는 데 신경 쓰지 않습니다.

내가 보는 가장 큰 문제는 미디어 쿼리와 SSR을 다루는 것입니다. 프레 넬 과 같은 라이브러리는 작동하지만 모든 구성 요소를로드하기 때문에 성능이 저하되고 window 구성 요소가 사용 가능 해지면 DOM을 정리합니다.

내 웹 사이트에서 createPage로 만든 모든 페이지에는 pagespeed 무거운 자바 스크립트 (사용하지 않는 JavaScript 제거)에 소스 코드 (마크 다운 및 마크 다운 반응 구성 요소)가 있습니다.

순수한 CSS 블러 된 자리 표시자를 만드는 데 사용할 수있는 Plaiceholder 를 방금 출시했습니다. 아마도 이것이 흥미로울까요? 옵션 포워딩에 대해 핵심 팀과 대화하는 것을 기쁘게 생각합니다.

최신 Lighthouse 6.4.0에서 좋은 점수를 얻은 Jamify Blog Starter 의 Next.js 버전을 만들었습니다.

next.jamify.org 에서 데모 사이트를 검사 할 수 있습니다.

난 당신이 Next.js.로 전환 할 것을 제안하지, 여기를 게시하고 오히려 Gatsby를 사용하여 동일한 결과를 얻을 수있는 방법을 배우십시오 . 핵심 성공 요인은 다음과 같습니다.

• 고도로 최적화 된 이미지 (Next는 람다 옵티 마이저로이를 달성하지만 gatsby-plugin-sharp로도 수행 할 수 있습니다).
• 간단한 자리 표시 자 svg (흐림 효과와 같은 멋진 효과로 인해 페이지 속도가 느려짐).
• 교차 관찰자를 사용하여보기에있을 때만 이미지를 표시합니다 (다음 / 이미지 참조).
• 이미지의 지연로드를 보장합니다.
• 작은 번들 크기.

이에 대해 더 논의하고 싶다면 twitter에서 저에게 연락 할 수

@styxlab web.dev/measure 에서 약간 더 낮은 결과를 얻습니다.

그러나 포스트 결과에서 더 좋으며 어떤 경우에도 확실히 매우 좋은 값이며 개츠비 버전 https://demo.jamify.org/와 현저하게 다릅니다.

또한 한 사이트에서 gatsby 대해 11ty gatsby 를 변경했으며 성능이 향상되었지만 크게 향상되지는 않았다고 게시 할 것입니다.

(개츠비)

(다른 디자인, 본질적으로 동일한 내용, 11ty)

또는 비슷한 페이지에서 이번에는 이미지와 함께

(개츠비)

(다른 디자인, 본질적으로 동일한 내용, 11ty)

11ty 개발자 경험은 매우 훌륭하다고 말할 것입니다 (실험적으로 jsx 및 styled-components ).하지만 클라이언트 측의 모든 js 는 손실됩니다 ( 그것을 삽입하고 웹팩과 싸울 수 있습니다. 그 순간은 개츠비를 그리워합니다)

11ty를 사용하는 동안, 개츠비가 일종의 11ty 렌더링 전략을 활성화하여 하나의 프레임 워크에서 혼합 반응 및 반응없는 정적 페이지를 배포 할 수 있다는 것이 얼마나 좋을지 생각하고있었습니다.

이것에 대한 업데이트가 있습니까? 나는 이미지가 없으며 총 차단 시간 때문에 성능이 76입니다.