Page Speed Insights(Lighthouse)는 2021년 6월 1일에 업그레이드를 진행했습니다. 어떻게 변경되었습니까?

Page Speed Insights가 Lighthouse 8.0을 실행하고 있습니다. 점수에 대한 변경이 정말로 당신의 점수를 망칠 수 있다는 것을 알려 드리겠습니다!
그럼에도 불구하고 브라우저에서 자바스크립트를 사용하지 않고 사이트를 구축하면 이득을 볼 수 있습니다!
요컨대, 그 무거운 전단 틀을 버리고, 네가 상위권에 오르고 싶은 사이트에 서비스를 제공할 때가 되었다.

이 댓글 누구 거예요?

사람들이 만든 사이트는 구글에서 상위권에 랭크되어야 한다.
곧 다가올 Web Vitals update to Google Search Algorithm starting to be rolled out이 8월 말에 전면적으로 출시될 예정이며, SEO에 의존해 데이터를 얻으면 지금부터 이 문제들을 해결하는 것이 중요하다.
이 주제에 관한 다른 글과 달리 PageSpeed Insights나 비슷한 속도 검사 서비스를 적어도 들어보고 사용한 적이 있다고 가정해 보겠습니다.
그럼에도 불구하고 저는'등대'라는 단어 아래 모든 서비스를 언급할 것입니다. 그래서 저는 당신에게 매우 빠른 정보를 드리는 것이 좋습니다.

등대 20초 후

모르는 사람에게 Lighthouse은 page speed insights, web.dev/measure, GT Metrix 등에 동력을 제공하는 엔진이다.
그것은 아마도 가장 광범위하게 사용되는 웹 사이트의 로드 속도 테스트 도구일 것이다.

좋아, 그럼 이번에 그들은 무엇을 바꿨지?

점수 가중치가 다시 업데이트됩니다.

V6/V7 평점

First Contentful Paint        15%
Speed Index                   15%
Largest Contentful Paint      25%
Time to Interactive           15%
Total Blocking Time           25%
Cumulative Layout Shift        5%

V8 별점(새 별점)

First Contentful Paint        10% -
Speed Index                   10% -
Largest Contentful Paint      25% 
Time to Interactive           10% -
Total Blocking Time           30% +
Cumulative Layout Shift       15% +

비교

미터제의
무게
무게
개변
첫 번째 만족 도료(FCP)
15
10
-5
속도 지수(SI)
15
10
-5
최대 함유 도료(LCP)
25
25
0
상호작용 시간(TTI)
15
10
-5
총 차단 시간(미정)
25
30
5
누적 레이아웃 횟수(CLS)
5
15
10

영어로 말해 주세요. 이 지표들은 저에게 아무런 의미가 없습니다.

요컨대 초점은 사물이 처음 등장하는 시간이 아니라 페이지가 실제로 사용할 준비가 된 시간으로 옮겨졌다.
이것은 실제적으로 이것보다 좀 복잡하다. 본문의 범위를 넘어섰다. 그러나 이것은 네가 알아야 할 총결이다.

JavaScript를 많이 사용하는 웹 사이트는 충격을 받을 것입니다.

만약 100kb의 JS를 다운로드한 것은 위에 접힌 내용을 보여주기 위해서일 뿐이다. (스크롤하지 않은 상태에서 볼 수 있는 초기 내용을 보여주기 위해서) 그러면 점수가 떨어질 가능성이 높다. (다시! 힌트를 받을 때가 되었다. React for 홍보책 사이트를 사용하지 마라. 나무와 코드를 어떻게 나누는지 알지 않으면.)
이는 총 차단 시간(TBT) 지표와 관련이 있다.그것은 JS에서 얼마나 많은 임무가 50밀리초를 초과해야 하는지를 측정한 다음에 더 오래 걸리는 모든 임무를 합쳐서 최초의 50밀리초 여분을 줄인다.
이 점을 더욱 명확하게 설명하기 위해

작업 A:30ms(50ms 미만, 0ms TBT에 추가)

작업 B: 55ms(55ms-50ms, 5ms 증가)

Task C: 10ms(50ms 미만, TBT 5ms)

작업 D: 95ms(95ms-50ms, 총 TBT 50ms)

따라서 이 경우 TBT는 50ms가 됩니다.
중요한 힌트: 쉽게 통과될 것 같지만'이동 우선'이 구글의 정책임을 고려해 보자.따라서 PageSpeed Insights, Chrome의 Lighthouse 옵션 카드 등에서 보고서를 실행할 때 휴대전화 점수를 확인하세요.
모바일 기기의 경우 중급 이동전화(CPU 속도 4배 감소)와 느린 4G 연결을 시뮬레이션하는 절전 기능을 적용할 수 있다.
너는 more info about throttling in Lighthouse here을 찾을 수 있다
이것이 바로 내가 핑덤을 보는 것을 건의하지 않는 이유다.좋은 데스크톱 컴퓨터와 좋은 모니터링 소프트웨어를 가지고 있지 않으면

인라인 키 CSS가 더 중요

critical CSS은 위의 축소된 컨텐트를 렌더링하는 데 필요한 모든 CSS입니다.
문서의 <style> 태그에 연결하면 두 번째 네트워크 요청 없이 페이지를 로드하고 표시할 수 있습니다.
이는 도료의 최대 함량을 높이고 배치 변화를 최대한 줄이는 데 도움이 된다.

레이아웃 변환이 중지되었는지 확인합니다.

사람들은 왕왕 이것에 대해 곤혹스러움을 느낀다.기본적으로, 페이지에서 불러오는 내용을 보면, 단추를 누르는 직접적인 결과가 아니라면, 이동하거나 커지거나 작아져서는 안 된다.
이 때문에 그림이 레이아웃 변화를 일으키는 것을 어떻게 막는지에 관한 이 댓글을 읽어 보시기를 권장합니다.

빠른 팁: PageSpeed Insights/Lighthouse에서 "이미지 요소에 명확한 너비와 높이가 없음"을 수정하는 방법

비공식적・ 21년6월6일・ 6 분 읽기

#webdev #html #css #beginners

JS를 사용하여 데이터를 가져오는 경우 올바른 크기의 자리 표시자가 있는지 확인합니다..단, 만약 당신이 이렇게 위의 접는 내용을 사용한다면, 당신은 이미 골치 아프게 될 것입니다. 가장 빠른 렌더링은 모든 이상의 접는 내용을 최초의 HTML에서 제공해야 합니다.
사실 위의 접는 내용은 14kb의 미친 속도, 42kb의 초속도 또는 98kb의 좋은 속도(어느 정도)에 적합해야 한다.이 모든 것은 TCP의 작업 방식과 TCP slow start과 관련이 있다...하지만 이것은 또 다른 문장이다.

너는 여전히 네가 가장 만족하는 페인트가 좋다는 것을 확보해야 한다

가장 큰 만족감 도료(LCP)는 사실상 매우 간단하다.
만약 당신이 페이지를 가지고 있다면, 위에 네 개의 요소가 있다.만약 한 원소가 40%의 공간(원소A)을 차지하고 다른 세 원소가 각각 20%(원소B, C, D)를 차지한다면 원소A는 가장 큰 페인트 원소가 될 것이다.
점수는 요소가 페이지에 나타나는 속도에 따라 달라집니다.이 원소가 빨리 나타날수록 너의 점수는 더욱 좋다.
현재 HTML에 핵심을 연결하는 CSS를 소개했기 때문에 추가 네트워크 요청을 기다리지 않아도 페이지를 보여줄 수 있습니다. 그러나 이 요소가 그림이라면?
한 가지 방법은 Low Quality Image Placeholder (LQIP)을 사용하는 것이다.마찬가지로, 이 점을 어떻게 하는지에 대한 세부 사항도 다른 글에 적용되지만, 본질적으로, 당신은 매우 낮은 품질의 작은 이미지 (예를 들어 16:9의 종횡비에 대해 32px×18px) 를 사용하고, 데이터 URI를 사용하여 그것을 내연시킨다.

<img src= "data:image/jpg;base64,[data encoded with base64]" alt="your alt" width="1600" height="900">

핵심 페이지 내용을 로드한 후 JS를 사용하여 실제 이미지를 교환합니다.
여러 가지 방법으로 이 점을 실현할 수 있기 때문에, 그것은 자신의 댓글에 가치가 있다. 내가 말한 바와 같이, 이 댓글의 생각은 당신에게 자신과 건의를 연구하는 것을 주는 것이다.

성적에 영향을 주지 않지만 주의해야 할 일.

지난 몇 달 동안 발표된 거의 모든 주요 업데이트는 Content Security Policies (CSP)과 관련이 있다.
이번 업데이트도 예외는 아니다.
이들은'모범 사례'아래'csp xss'라는 감사(Speed Insights 페이지에는 없지만 Lighthouse의 개발자 도구 등에 제공)를 도입했다.
이것은 여전히 이와 관련된 득점권이 없지만, 그들이 그것을 위해 점점 더 많은 노력을 기울이고 있기 때문에, 너는 지금 고려해야 한다.
만약 당신의 사이트 안전 제목의 상태를 보고 싶다면, 나는 당신이 https://observatory.mozilla.org/을 사용하여 당신의 사이트를 테스트하고, 당신의 고객을 악의적인 행위로부터 보호하는 제목을 배우는 것을 권장합니다.

결론

이 글의 목적은 모든 것을 복구하는 방법을 알려주는 것이 아니라, 어떤 변화가 생겼는지, 그리고 그것이 당신에게 무엇을 의미하는지 알려주는 것이다. 설령 페이지 속도에 대한 모든 것을 알지 못하더라도.
Lighthouse는 팸플릿 사이트, 심지어 전자상거래 사이트에서 복잡한 JS 프레임워크를 사용하는 것을 멀리하도록 유도하고 있다. 왜냐하면 이런 사이트에서는 페이지 속도가 매우 중요하고 검색 순위도 매우 중요하기 때문이다.
만약 당신이 사이트의 특정한 문제에 도움을 필요로 한다면, 평론에서 저에게 알려 주십시오.