Core Web Vitals를 개선하는 가장 효과적인 방법

오랜 세월 동안 웹 커뮤니티는 웹 성능 최적화에 관한 풍부한 지식을 축적해 왔습니다. 하나의 최적화로 여러 사이트의 성능을 개선할 수 있지만, 한 번에 모든 최적화를 적용하면 부담스러울 수 있으며 실제로는 일부 최적화만 특정 사이트에 적용할 수 있습니다.

웹 성능이 주 업무가 아니라면 사이트에 가장 큰 영향을 미치는 최적화가 무엇인지 파악하기 쉽지 않을 수 있습니다. 모든 작업을 할 시간은 없으므로 사용자의 실적을 개선하기 위해 선택할 수 있는 가장 효과적인 최적화는 무엇인가?라는 질문을 스스로에게 던져야 합니다.

성능 최적화에 대한 진실은 다음과 같습니다. 기술적 이점만으로는 판단하기 어렵습니다. 또한 특정 최적화를 구현할 가능성에 영향을 미치는 인적 요소와 조직적 요소도 고려해야 합니다. 일부 성능 개선은 이론적으로 큰 영향을 미칠 수 있지만 실제로는 이를 구현할 시간과 리소스가 있는 개발자가 거의 없습니다. 반면 거의 모든 사용자가 이미 따르고 있는 실적 향상에 큰 영향을 미치는 권장사항도 있을 수 있습니다. 이 가이드에서는 다음과 같은 웹 성능 최적화를 식별합니다.

• 실질적인 영향이 가장 큽니다.
• 대부분의 사이트에 관련성이 높고 적용 가능함
• 현실적으로 대부분의 개발자가

이러한 방법을 종합적으로 활용하면 Core Web Vitals 측정항목을 개선하는 가장 현실적이고 효과적인 방법이 될 수 있습니다. 웹 성능에 대해 잘 모르거나 가장 큰 투자수익을 얻을 수 있는 방법을 아직 결정하지 못한 경우 이 페이지에서 시작하는 것이 좋습니다.

다음 페인트에 대한 상호작용(INP)

최신 Core Web Vitals 측정항목인 다음 페인트에 대한 상호작용 (INP)에는 개선할 수 있는 가장 큰 기회가 있습니다. 하지만 지원 중단된 이전 버전에 비해 '좋은' 환경을 위한 기준점을 통과하는 사이트가 훨씬 적기 때문에 상호작용 응답성을 최적화하는 방법을 처음 배우는 개발자 중 한 명일 수 있습니다. INP를 개선하는 가장 효과적인 방법에 대해 알아야 하는 기법을 먼저 살펴보세요.

1. 긴 작업을 분할하기 위해 자주 생성

태스크는 브라우저가 수행하는 모든 개별 작업으로, 렌더링, 레이아웃, 파싱, 컴파일 또는 스크립트 실행을 포함합니다. 작업의 소요 시간이 50밀리초를 초과하면 장기 작업이 됩니다. 장기 작업은 기본 스레드가 사용자 상호작용에 빠르게 응답하지 못하도록 차단할 수 있으므로 문제가 됩니다.

항상 JavaScript에서 최대한 적은 작업을 실행하도록 노력해야 하지만 긴 작업을 분할하여 기본 스레드를 도울 수 있습니다. 렌더링 업데이트 및 기타 사용자 상호작용이 더 빨리 실행될 수 있도록 기본 스레드에 자주 양보하면 됩니다.

Scheduler API를 사용하면 우선순위 시스템을 사용하여 작업을 대기열에 추가할 수 있습니다. 특히 scheduler.yield() API는 장기 작업을 분할하는 동시에 작업 대기열에서 차지하는 위치를 포기하지 않고 상호작용을 처리할 수 있도록 합니다.

긴 작업을 분할하면 브라우저가 사용자 차단과 관련된 중요한 작업을 처리할 기회가 더 많아집니다.

2. 불필요한 자바스크립트 피하기

웹사이트에서 이전보다 더 많은 JavaScript를 제공하고 있으며 이 추세는 변하지 않을 것으로 보입니다. JavaScript를 너무 많이 전송하면 작업이 기본 스레드의 주의 집중을 놓고 경쟁하는 환경이 만들어집니다. 특히 중요한 시작 기간에 웹사이트의 응답 속도에 영향을 줄 수 있습니다.

하지만 해결할 수 없는 문제는 아니며 다음과 같은 옵션이 있습니다.

• 중복된 JavaScript 기반 구현 대신 기준 널리 사용되는 웹 플랫폼 기능을 사용하세요.
• Chrome DevTools의 범위 도구를 사용하여 스크립트에서 사용되지 않는 코드를 찾습니다. 시작 시 필요한 리소스의 크기를 줄이면 페이지에서 코드를 파싱하고 컴파일하는 데 드는 시간을 줄여 더 원활한 초기 사용자 환경을 제공할 수 있습니다.
• 코드 분할을 사용하여 초기 렌더링에는 필요하지 않지만 나중에도 사용할 코드를 위한 별도의 번들을 만들 수 있습니다.
• 태그 관리자를 사용 중이면 정기적으로 태그를 최적화하세요. 사용되지 않는 코드가 있는 이전 태그를 삭제하여 태그 관리자의 JavaScript 사용량을 줄일 수 있습니다.

3. 대규모 렌더링 업데이트 방지

JavaScript 실행은 웹사이트의 반응성에 영향을 미치는 요소 중 하나일 뿐입니다. 렌더링은 그 자체로 비용이 많이 드는 작업입니다. 대규모 렌더링 업데이트 중에 웹사이트가 사용자 상호작용에 더 느리게 반응할 수 있습니다.

렌더링 작업을 최적화하는 것은 간단한 프로세스가 아니며, 달성하려는 목표에 따라 달라집니다. 그렇더라도 렌더링 작업이 오래 걸리지 않도록 다음과 같은 조치를 취할 수 있습니다.

• 강제 레이아웃 및 레이아웃 트래싱을 방지하기 위해 JavaScript 코드에서 DOM 읽기 및 쓰기를 재구성합니다.
• DOM 크기를 작게 유지합니다. DOM 크기와 레이아웃 작업의 강도는 서로 연관이 있습니다. 렌더러가 매우 큰 DOM의 레이아웃을 업데이트해야 하는 경우 레이아웃을 다시 계산하는 데 필요한 작업이 상당히 증가할 수 있습니다.
• CSS 포함을 사용하여 화면 밖에 있는 DOM 콘텐츠를 지연 렌더링합니다. 항상 간단하지는 않지만, 복잡한 레이아웃을 포함하는 영역을 분리하면 불필요한 레이아웃 및 렌더링 작업을 피할 수 있습니다.

최대 콘텐츠 렌더링 시간(LCP)

최대 콘텐츠 페인트 (LCP)는 Core Web Vital로, Chrome UX 보고서에 포함된 사이트 중 40%가 우수한 사용자 경험을 위한 권장 LCP 기준점을 충족하지 못합니다. Chrome팀에서는 LCP를 개선하는 가장 효과적인 방법으로 다음 기법을 권장합니다.

1. LCP 리소스가 HTML 소스에서 검색 가능하고 우선순위가 지정되었는지 확인

Chrome팀은 웹의 LCP와 관련하여 다음과 같은 사항을 확인했습니다.

• HTTP Archive의 2022 웹 연감에 따르면 모바일 페이지의 72%가 이미지를 LCP 요소로 사용하고 있습니다.
• Chrome의 실제 사용자 데이터를 분석한 결과, LCP가 낮은 대다수의 출처는 p75 LCP 시간 중 10%미만이 LCP 이미지를 다운로드하는 것으로 나타났습니다.
• LCP가 좋지 않은 페이지 중 75번째 백분위에서 LCP 이미지 로드가 클라이언트에서 1,290밀리초 지연됩니다. 이는 빠른 환경을 위한 예산의 절반 이상입니다.
• LCP 요소가 이미지였던 페이지 중 이러한 이미지 중 39%에는 초기 HTML 응답에서 검색할 수 없는 소스 URL (예: <img src="..."> 또는 <link rel="preload" href="...">)이 있었기 때문에 브라우저의 미리 로드 스캐너가 가능한 한 빨리 이미지를 검색할 수 있었습니다.
• Web Almanac에 따르면 적격 페이지 중 0.03%만이 fetchpriority HTML 속성을 활용하여 상대적으로 적은 노력으로 페이지의 LCP를 개선할 수 있는 리소스를 포함하여 리소스에 더 높은 우선순위를 부여했습니다.

이 통계는 개발자가 LCP 이미지의 리소스 로드 지연과 리소스 로드 시간을 모두 줄일 수 있는 큰 기회가 있음을 보여줍니다.

리소스 로드 지연이 문제인 경우 이미지 로드를 시작하기 전에 CSS 또는 JavaScript가 완전히 로드될 때까지 페이지가 기다려야 한다면 LCP를 개선하기에 이미 너무 늦었을 수 있다는 점을 기억해야 합니다. 또한 LCP 이미지의 리소스 로드 시간은 더 많은 대역폭을 수신하도록 우선순위를 다시 지정하여 fetchpriority HTML 속성을 사용하여 더 빠르게 로드할 수 있습니다.

LCP 요소가 이미지인 경우 리소스 로드 지연을 줄이려면 HTML 응답에서 이미지의 URL을 검색할 수 있어야 합니다. 이를 위한 몇 가지 팁은 다음과 같습니다.

• src 또는 srcset 속성이 있는 <img> 요소를 사용하여 이미지를 로드합니다. 렌더링하는 데 JavaScript가 필요한 data-src와 같은 비표준 속성은 항상 속도가 느려지므로 사용하지 마세요. 9%의 페이지에서 LCP 이미지가 data-src 뒤에 가려져 있습니다.
• 클라이언트 측 렌더링(CSR)보다 서버 측 렌더링(SSR)을 선호합니다. SSR은 이미지를 포함한 전체 페이지 마크업이 HTML 소스에 존재한다는 것을 의미합니다. CSR 솔루션은 이미지를 검색하기 전에 JavaScript를 실행해야 합니다.
• 외부 CSS 또는 JS 파일에서 이미지를 참조해야 하는 경우에도 <link rel="preload"> 태그를 사용하여 HTML 소스에 이미지를 포함할 수 있습니다. 인라인 스타일에서 참조하는 이미지는 브라우저의 미리 로드 스캐너에서 검색할 수 없으므로 HTML 소스에서 발견되더라도 다른 리소스를 로드할 때 이미지 검색이 차단될 수 있습니다. 이 경우 미리 로드하면 도움이 될 수 있습니다.

또한 LCP 리소스가 일찍 그리고 높은 우선순위로 로드되도록 하면 리소스의 로드 시간을 단축할 수 있습니다.

• LCP 이미지의 <img> 또는 <link rel="preload"> 태그에 fetchpriority="high" 속성을 추가합니다. 이렇게 하면 이미지 리소스의 우선순위가 올라가므로 더 빨리 로드될 수 있습니다.
• LCP 이미지의 <img> 태그에서 loading="lazy" 속성을 삭제합니다. 이렇게 하면 이미지가 뷰포트 또는 그 근처에 표시되는지 확인하는 데 따른 로드 지연을 방지할 수 있습니다.
• 가능한 경우 중요하지 않은 리소스를 지연합니다. 이러한 리소스를 문서의 끝부분(이미지 지연 로드 또는 iframe)으로 이동하거나 자바스크립트를 사용하여 비동기식으로 로드하면 LCP 이미지와 같이 더 중요한 리소스를 더 빠르게 로드할 수 있습니다.

2. 즉각적인 탐색을 목표로 하세요.

페이지가 로드될 때까지 기다릴 필요가 없는 것이 이상적인 사용자 환경입니다. 리소스 검색 가능성 및 우선순위 지정과 같은 LCP 최적화는 사용자가 LCP 요소가 로드되고 렌더링될 때까지 기다리는 시간을 줄이는 데 효과적이지만, 이러한 바이트가 네트워크를 통해 로드되고 페이지에 렌더링되는 속도에는 물리적 한계가 있습니다. 이 한도에 도달하기 훨씬 전에 밀리초 단위로 시간을 단축하기 위해 엄청난 노력이 필요합니다. 따라서 즉각적인 탐색을 실현하려면 근본적으로 다른 접근 방식을 취해야 합니다.

즉시 탐색은 사용자가 탐색을 시작하기 전에 페이지를 로드하고 렌더링하려고 시도합니다. 이렇게 하면 사전 렌더링된 페이지가 거의 0인 LCP로 즉시 표시될 수 있습니다. 회복과 추측은 이를 수행하는 두 가지 방법입니다. 사용자가 이전에 방문한 페이지로 앞뒤로 탐색하면 메모리 내 캐시에서 빠르게 복원되어 사용자가 종료한 상태 그대로 표시됩니다. 또는 웹 애플리케이션에서 사용자가 다음으로 이동할 위치를 예측할 수 있습니다. 예측이 정확하면 사용자가 이동할 때 다음 페이지가 이미 로드되고 렌더링됩니다.

뒤로-앞으로 캐시(bfcache)를 사용하면 이전에 방문한 페이지를 복원할 수 있습니다. 이 기능을 사용하려면 페이지가 bfcache 자격 기준을 충족하는지 확인해야 합니다. 페이지가 bfcache를 사용할 수 없는 일반적인 이유는 페이지가 no-store 캐싱 지시어와 함께 제공되거나 unload 이벤트 리스너가 있기 때문입니다.

완전히 렌더링된 페이지를 복원하면 로드 성능뿐만 아니라 레이아웃 안정성도 개선됩니다. bfcache 및 CLS 개선에 얼마나 효과적인지에 대한 자세한 내용은 페이지가 bfcache를 사용할 수 있는지 확인하기 섹션을 참고하세요.

사용자가 방문할 다음 페이지를 미리 렌더링하는 것도 LCP 성능을 크게 개선하는 또 다른 효과적인 방법이며, 이는 Speculation Rules API를 통해 가능합니다. 이러한 이점을 실현하려면 올바른 페이지가 사전 렌더링되는지 확인해야 합니다. 잘못된 추측은 서버와 클라이언트 모두에서 리소스를 낭비하여 성능을 저하시킬 수 있습니다. 따라서 다음 페이지가 어떻게 표시될지 확신할 수 없을수록 미리 렌더링할 때는 더 보수적으로 접근해야 합니다. 확실하지 않은 경우 애널리틱스 데이터를 통해 다음에 방문할 가능성이 가장 높은 페이지를 더 적극적으로 미리 렌더링할 수 있습니다.

3. CDN을 사용하여 TTFB 최적화

이전 권장사항은 사용자에게 최상의 환경을 제공하는 즉시 탐색에 중점을 두었지만 bfcache 및 추측 로드 기법이 적용되지 않는 상황이 있을 수 있습니다. 사용자가 초기 HTML 문서 응답이 LCP를 효과적으로 차단하는 사이트의 교차 출처 링크를 따라가고 있다고 가정해 보겠습니다. 브라우저는 응답의 첫 번째 바이트를 수신할 때까지 하위 리소스 로드를 시작할 수 없습니다. 이 작업이 빨리 완료될수록 다른 모든 작업도 빨리 시작할 수 있습니다.

이 시간을 첫 바이트까지의 시간 (TTFB)이라고 합니다. TTFB를 줄이는 가장 좋은 방법은 다음과 같습니다.

• 사용자와 지리적으로 최대한 가까운 위치에서 콘텐츠를 제공합니다.
• 가까운 시일 내에 다시 요청될 경우 빠르게 제공할 수 있도록 콘텐츠를 캐시합니다.

이 두 작업을 모두 수행하는 가장 좋은 방법은 CDN을 사용하는 것입니다. CDN은 전 세계의 에지 서버에 리소스를 배포하므로 리소스가 전송되어 사용자에게 도달하는 거리가 제한됩니다. 또한 CDN에는 일반적으로 사이트의 요구사항에 맞게 조정할 수 있는 세분화된 캐싱 제어 기능이 있습니다.

CDN은 HTML 문서를 제공하고 캐시할 수도 있지만, Web Almanac에 따르면 HTML 문서 요청의 29% 만이 CDN에서 처리됩니다. 이는 사이트에서 추가 절감 효과를 실현할 수 있는 기회가 많다는 의미입니다.

CDN을 구성할 때 유용한 몇 가지 팁은 다음과 같습니다.

• 정적 HTML 문서를 잠시 캐시합니다. 예를 들어 콘텐츠가 항상 최신 상태여야 하나요? 아니면 몇 분 정도 오래되었을 수 있나요?
• 원본 서버에서 실행되는 동적 로직을 대부분의 최신 CDN 기능인 에지로 이동할 수 있는지 살펴보세요.

에지에서 콘텐츠를 직접 제공하고 원본 서버로 이동하지 않을 수 있다면 성능이 향상됩니다. 원본까지 여정을 이동해야 하는 경우에도 CDN은 일반적으로 더 빠르게 완료할 수 있도록 최적화되어 있으므로 어느 쪽이든 좋습니다.

레이아웃 변경 횟수(CLS)

누적 레이아웃 변경(CLS)은 웹페이지의 시각적 안정성을 측정하는 지표입니다. CLS는 대부분의 사이트에서 좋은 실적을 보이는 측정항목이지만 약 4분의 1은 여전히 권장 기준점을 충족하지 않으므로 많은 사이트에서 사용자 환경을 개선할 수 있는 여지가 남아 있습니다.

1. 페이지에서 로드된 모든 콘텐츠에 명시적인 크기 설정

레이아웃 전환은 일반적으로 다른 콘텐츠 로드가 완료된 후 기존 콘텐츠가 이동할 때 발생합니다. CLS를 개선하는 기본적인 방법은 필요한 공간을 최대한 사전에 예약하는 것입니다.

크기가 지정되지 않은 이미지로 인한 레이아웃 이동을 수정하는 가장 좋은 방법은 width 및 height 속성을 명시적으로 설정하거나 이에 상응하는 CSS 속성을 설정하는 것입니다. 페이지의 72%에 크기가 지정되지 않은 이미지가 하나 이상 포함되어 있습니다. 명시적인 크기가 없으면 이러한 이미지의 초기 높이는 0px이므로 이러한 이미지가 로드되고 브라우저에서 크기를 감지할 때 레이아웃이 전환될 수 있습니다. 이는 집단 웹에 큰 기회가 될 수 있으며, 이 기회를 활용하는 데는 이 가이드에서 제안하는 다른 권장사항보다 적은 노력이 필요합니다.

CLS에 기여하는 요소는 이미지만이 아닙니다. 레이아웃 변경은 일반적으로 페이지가 처음 렌더링된 후 로드되는 다른 콘텐츠(예: 서드 파티 광고 또는 삽입된 동영상)로 인해 발생할 수 있습니다. 이 경우 aspect-ratio 속성이 유용합니다. 개발자가 이미지뿐만 아니라 이미지가 아닌 요소에도 가로세로 비율을 명시적으로 설정할 수 있는 널리 사용 가능한 기준 CSS 기능입니다. 이렇게 하면 동적 width(예: 화면 크기 기반)를 설정하고 브라우저가 크기가 있는 이미지에서와 거의 동일한 방식으로 적절한 높이를 자동으로 계산하도록 할 수 있습니다.

하지만 동적 콘텐츠의 정확한 크기를 항상 알 수 있는 것은 아닙니다. 정확한 크기를 모르더라도 레이아웃 변경의 심각도를 줄일 수 있습니다. 브라우저가 빈 요소에 기본 높이 0px를 사용하는 것보다 적절한 min-height를 설정하는 것이 거의 항상 좋습니다. min-height를 사용하는 것도 일반적으로 간단한 해결 방법입니다. 필요한 경우 컨테이너가 최종 콘텐츠의 높이까지 확장되도록 허용하면서 확장 정도를 더 허용 가능한 수준으로 줄이기만 하면 됩니다.

2. 페이지가 bfcache를 사용할 수 있는지 확인

이 가이드 앞부분에서 설명한 대로 뒤로-앞으로 캐시(bfcache)는 메모리 스냅샷에서 브라우저 기록의 앞뒤 페이지를 즉시 로드합니다. bfcache는 LCP를 개선하는 중요한 브라우저 수준의 성능 최적화이지만 레이아웃 전환도 완전히 제거합니다. 실제로 2022년 bfcache 도입으로 인해 그해 CLS가 가장 크게 개선되었습니다.

하지만 많은 수의 웹사이트가 bfcache를 사용할 수 없어 이 무료 웹 성능 개선을 놓치고 있습니다. 페이지에서 메모리에서 복원하고 싶지 않은 민감한 정보를 로드하지 않는 한 페이지에서 bfcache를 사용할 수 있는지 확인합니다.

사이트 소유자는 페이지가 bfcache를 사용할 수 있는지 확인하고 사용 불가능한 이유를 수정해야 합니다. Chrome DevTools에 bfcache 테스터가 있음. Not Restored Reasons API를 사용하여 필드에서 자격 요건 미충족 사유를 감지할 수도 있습니다.

3. 레이아웃을 유도하는 CSS 속성을 사용하는 애니메이션 및 전환 피하기

레이아웃이 이동하는 또 다른 일반적인 원인은 요소에 애니메이션이 적용되는 경우입니다. 예를 들어 상단 또는 하단에서 슬라이드되는 쿠키 배너 또는 기타 알림 배너가 CLS에 포함되는 경우가 많습니다. 이는 배너가 다른 콘텐츠를 화면 밖으로 밀어내는 경우 특히 문제가 되지만, 콘텐츠가 표시되지 않는 경우에도 애니메이션은 CLS에 여전히 영향을 미칠 수 있습니다.

HTTP Archive 데이터가 애니메이션을 레이아웃 변경에 확실하게 연결할 수는 없지만, 레이아웃에 영향을 미칠 수 있는 CSS 속성에 애니메이션을 적용하는 페이지는 전체적으로 페이지보다 '양호한' CLS를 가질 가능성이 15% 낮습니다. 일부 속성은 다른 속성보다 CLS가 더 나쁩니다. 예를 들어 margin 또는 border 너비 애니메이션을 사용하는 페이지는 전체 페이지가 '나쁨'으로 평가되는 비율의 거의 두 배로 CLS가 '나쁨'입니다.

이는 놀라운 일이 아닙니다. 레이아웃을 유도하는 CSS 속성을 전환하거나 애니메이션 처리할 때마다 레이아웃 변경이 발생하기 때문입니다. 이러한 레이아웃 변경이 사용자 상호작용 후 500밀리초 이내에 발생하지 않으면 CLS에 영향을 미칩니다.

일부 개발자에게는 요소가 일반적인 문서 흐름 외부로 이동한 경우에도 이 규칙이 적용된다는 점이 놀라울 수 있습니다. 예를 들어 top 또는 left에 애니메이션을 적용하는 절대 위치로 배치된 요소는 다른 콘텐츠를 밀어내지 않더라도 레이아웃 변경을 야기합니다. 하지만 top 또는 left를 애니메이션 처리하는 대신 transform:translateX() 또는 transform:translateY()를 애니메이션 처리하면 브라우저에서 페이지 레이아웃을 업데이트하지 않으므로 레이아웃이 전환되지 않습니다.

브라우저의 컴포지터 스레드에서 업데이트할 수 있는 CSS 속성의 기본 애니메이션을 사용하는 것은 작업을 기본 스레드에서 GPU로 이동하기 때문에 오랫동안 성능 권장사항이었습니다. 이는 일반적인 실적 권장사항일 뿐만 아니라 CLS를 개선하는 데도 도움이 됩니다.

일반적으로 브라우저가 페이지 레이아웃을 업데이트해야 하는 CSS 속성은 애니메이션 또는 전환하지 마세요. 단, 사용자 탭 또는 키 누르기에 응답하여 실행하는 경우는 예외입니다(hover 아님). 가능하면 CSS transform 속성을 사용하는 전환 및 애니메이션을 사용하세요.

비합성 애니메이션 방지 Lighthouse 감사에서는 페이지가 느려질 수 있는 CSS 속성을 애니메이션 처리하는 경우 경고를 표시합니다.

결론

특히 고려해야 할 안내가 웹 전반에 많다는 점을 감안할 때 페이지 성능을 개선하기란 어렵게 느껴질 수 있습니다. 그러나 가장 효과적인 권장사항을 담은 이 간단한 목록에 집중함으로써 새로운 집중을 통해 문제에 접근하고 웹사이트의 Core Web Vitals를 발전시킬 수 있습니다.

여기에 나열된 최적화 외의 방법을 알아보려면 다음 가이드를 참고하세요.

• INP 최적화
• LCP 최적화
• CLS 최적화

부록: 변경 로그

이 문서의 주요 변경사항을 추적하여 상위 추천이 변경된 시점과 이유를 파악할 수 있습니다.

2024년 10월

2024년 업데이트:

• INP
  • INP가 Core Web Vitals 측정항목으로 출시됨에 따라 이 측정항목을 FID에서 INP로 전환하고 목록에서 상위 측정항목으로 선정했습니다.
  • 긴 작업을 분할하는 과정에서 isInputPending API를 사용하는 것이 좋지 않다는 권장사항이 번복되었습니다. 긴 작업 최적화 도움말에서 Google의 추론에 대해 자세히 알아보세요.
• LCP
  • 검색 가능성 및 우선순위 추천을 하나로 결합했습니다.
  • 즉각적인 탐색을 목표로 하는 새로운 추천을 추가했습니다.

2023년 1월

다음은 초기 추천 목록입니다.

• LCP
  • HTML 소스에서 LCP 리소스를 검색할 수 있는지 확인
  • LCP 리소스의 우선순위 지정
  • CDN을 사용하여 문서 및 리소스 TTFB 최적화
• CLS
  • 페이지에서 로드된 모든 콘텐츠에 명시적인 크기 설정
  • 페이지가 bfcache를 사용할 수 있는지 확인
  • 레이아웃을 유도하는 CSS 속성을 사용하는 애니메이션 및 전환 피하기
• FID
  • 긴 작업 피하기 또는 분할
  • 불필요한 JavaScript 피하기
  • 대규모 렌더링 업데이트 방지

2023 Google I/O 프레젠테이션을 시청하여 동영상 요약을 확인할 수도 있습니다.