Chrome DevRel팀에서 2023년 Core Web Vitals 성능을 개선하는 가장 효과적인 방법이라고 판단한 권장사항 모음입니다.
여러 해 동안 Google에서는 웹 개발자에게 성능 개선 방법에 관해 수많은 권장사항을 제공해 왔습니다.
각 권장사항을 개별적으로 적용할 경우 많은 사이트의 실적이 개선될 수 있지만, 추천사항을 모두 적용하기에는 어려움이 있으며, 현실적으로 한 사람이나 사이트에서 모든 권장사항을 따를 수는 없습니다.
웹 성능이 중요한 작업 외에는 어떤 추천이 사이트에 가장 큰 긍정적인 영향을 줄지 알 수 없습니다. 예를 들어, 중요한 CSS를 구현하면 로드 성능을 개선할 수 있다는 사실을 읽고 이미지를 최적화하는 것이 중요하다는 이야기도 들어보셨을 것입니다. 하지만 이 두 가지 작업을 모두 할 시간이 없다면 어떤 방법을 선택해야 할까요?
Chrome팀은 작년 한 해 동안 사용자 성능을 개선하기 위해 개발자에게 제공할 수 있는 가장 중요한 권장사항은 무엇인가?라는 질문에 답하기 위해 많은 노력을 기울였습니다.
이 질문에 적절히 답하기 위해서는 특정 권장사항의 기술적 이점뿐 아니라 개발자가 이러한 권장사항을 실제로 적용할 수 있을 가능성에 영향을 미치는 인적 및 조직적 요인도 고려해야 합니다. 즉, 일부 권장사항은 이론상으로는 막대한 영향을 미칠 수 있지만 실제로 이러한 권장사항을 구현할 시간이나 리소스를 갖춘 사이트는 거의 없습니다. 마찬가지로 일부 권장사항이 필수적이지만 대부분의 웹사이트는 이미 이러한 관행을 따르고 있습니다.
요약하자면, 주요 웹 성능 개선을 위한 추천 목록은 다음과 같습니다.
- 실제로 가장 큰 영향을 미칠 것으로 판단되는 추천
- 대부분의 사이트에 관련성 있고 적용 가능한 추천
- 대부분의 개발자가 구현하는 현실적인 권장사항
지난 한 해 동안 Google은 모든 실적 개선을 위한 추천사항을 감사하고 위의 세 가지 기준에 따라 각 추천을 정성적 및 정량적으로 평가했습니다.
이 게시물에서는 각 Core Web Vitals 측정항목의 성능을 개선하기 위한 주요 권장사항을 간략히 설명합니다. 웹 성능이 처음이거나 수익에 가장 큰 효과를 얻을 수 있는 방법을 고민 중이시라면 이 권장사항이 가장 좋은 출발점이라고 생각합니다.
최대 콘텐츠 렌더링 시간(LCP)
첫 번째 권장사항은 로드 성능을 측정하는 최대 콘텐츠 페인트 (LCP)입니다. 코어 웹 바이탈 측정항목 3가지 중 LCP는 가장 많은 사이트에서 어려움을 겪고 있는 측정항목입니다. 오늘날 웹에서 모든 사이트의 약 절반만이 권장 기준을 충족합니다. 그렇기 때문에 이 측정항목부터 시작해 보겠습니다.
LCP 리소스가 HTML 소스에서 검색 가능한지 확인하세요.
HTTP Archive의 2022 Web Almanac에 따르면 모바일 페이지의 72%가 LCP 요소로 이미지를 사용합니다. 즉, 대부분의 사이트에서 LCP를 최적화하려면 이미지가 빠르게 로드될 수 있도록 해야 합니다.
이미지를 로드하는 데 걸리는 시간은 문제의 일부일 뿐이라는 사실은 많은 개발자가 명확하게 이해하지 못할 수 있습니다. 또 다른 중요한 부분은 이미지 로드가 시작되기 전 시간입니다. HTTP Archive 데이터는 실제로 이 시점에 많은 사이트가 멈춘 것으로 나타납니다.
실제로 LCP 요소가 이미지인 페이지 중 39%에는 HTML 문서 소스에서 검색할 수 없는 소스 URL이 포함되어 있었습니다. 다시 말해 <img src="..."> 또는 <link rel="preload" href="...">과 같은 표준 HTML 속성에서 이러한 URL을 찾을 수 없으므로 브라우저에서 빠르게 검색하여 즉시 로드를 시작할 수 있습니다.
이미지가 로드를 시작하기도 전에 CSS 또는 JavaScript 파일이 완전히 다운로드, 파싱 및 처리될 때까지 기다려야 하는 경우 이미 너무 늦을 수 있습니다.
일반적으로 LCP 요소가 이미지인 경우 이미지의 URL을 항상 HTML 소스에서 검색할 수 있어야 합니다. 이를 위한 몇 가지 팁은 다음과 같습니다.
src또는srcset속성이 있는<img>요소를 사용하여 이미지를 로드합니다.data-src와 같이 렌더링하기 위해 JavaScript가 필요한 비표준 속성은 사용하지 마세요. 사용 속도가 느려집니다. 페이지 중 9%가data-src뒤에 있는 LCP 이미지를 가립니다.클라이언트 측 렌더링(CSR)보다 서버 측 렌더링(SSR)을 선호합니다. SSR은 이미지를 포함한 전체 페이지 마크업이 HTML 소스에 존재한다는 것을 의미합니다. CSR 솔루션을 사용하려면 JavaScript가 실행되어야 이미지를 찾을 수 있습니다.
이미지를 외부 CSS 또는 JS 파일에서 참조해야 하는 경우
<link rel="preload">태그를 통해 HTML 소스에 포함할 수 있습니다. 인라인 스타일에서 참조한 이미지는 브라우저의 미리 로드 스캐너에서 검색할 수 없으므로 HTML 소스에 있더라도 다른 리소스를 로드할 때는 이미지를 찾지 못할 수 있으므로 이러한 경우 미리 로드가 도움이 될 수 있습니다.
LCP 이미지에 검색 가능성 문제가 있는지 파악할 수 있도록 Lighthouse는 버전 10.0 (2023년 1월 예상)의 새로운 감사를 출시할 예정입니다.
LCP 리소스를 HTML 소스에서 검색할 수 있게 하면 상당한 개선 효과를 얻을 수 있으며 리소스의 우선순위를 지정할 수 있는 추가 기회도 얻을 수 있습니다. 이는 다음 권장사항입니다.
LCP 리소스에 우선순위가 부여되었는지 확인
LCP 리소스가 HTML 소스에서 검색될 수 있도록 하는 것은 LCP 리소스가 조기에 로드를 시작할 수 있도록 하는 중요한 첫 번째 단계이지만, 또 다른 중요한 단계는 해당 리소스의 로드가 우선순위를 지정하고 덜 중요한 다른 여러 리소스 뒤에서 큐에 추가되지 않도록 하는 것입니다.
예를 들어 LCP 이미지가 표준 <img> 태그를 사용하여 HTML 소스에 있는 경우에도 페이지의 <img> 태그 앞에 있는 문서의 <head>에서 12개의 <script> 태그가 포함되어 있으면 이미지 리소스 로드가 시작되기까지 다소 시간이 걸릴 수 있습니다.
이 문제를 해결하는 가장 쉬운 방법은 LCP 이미지를 로드하는 <img> 또는 <link> 태그에 새 fetchpriority="high" 속성을 설정하여 가장 우선순위가 높은 리소스에 관한 힌트를 브라우저에 제공하는 것입니다. 이렇게 하면 스크립트가 완료될 때까지 기다리지 않고 먼저 로드하도록 브라우저에 지시합니다.
Web Almanac에 따르면 자격 요건을 충족하는 페이지 중 0.03%만 이 새로운 API를 활용하고 있습니다. 즉, 대부분의 웹 사이트는 거의 작업 없이 LCP를 개선할 수 있는 기회가 많습니다. fetchpriority 속성은 현재 Chromium 기반 브라우저에서만 지원되지만 이 API는 점진적인 개선 사항으로 다른 브라우저에서는 무시되고 있으므로 개발자는 지금 이 API를 사용하는 것이 좋습니다.
Chromium이 아닌 브라우저에서 LCP 리소스의 우선순위가 다른 리소스보다 우선하도록 하는 유일한 방법은 이 문서의 앞부분에서 LCP 리소스를 참조하는 것입니다. 문서의 <head>에 <script> 태그가 많은 사이트의 예를 다시 사용하여 LCP 리소스의 우선순위가 스크립트 리소스보다 먼저 지정되도록 하려면 이러한 스크립트 앞에 <link rel="preload"> 태그를 추가하거나 나중에 <body>에서 스크립트를 <img> 아래로 이동할 수 있습니다. 이 방법은 fetchpriority를 사용하는 것보다 인체 공학적이지만, 다른 브라우저에서도 빠른 시일 내에 지원할 수 있기를 바랍니다.
LCP 리소스의 우선순위를 지정할 때 또 다른 중요한 측면은 loading="lazy" 속성 추가와 같이 리소스 우선순위를 낮추는 작업을 수행하지 않는 것입니다. 현재 페이지 중 10%가 실제로 LCP 이미지에 loading="lazy"를 설정합니다. 모든 이미지에 지연 로드 동작을 무차별적으로 적용하는 이미지 최적화 솔루션에 유의하세요. 이러한 동작을 재정의하는 방법을 제공하는 경우 LCP 이미지에 사용해야 합니다. 어떤 이미지가 LCP가 될지 확실하지 않은 경우 휴리스틱을 사용하여 적절한 후보를 선택하시기 바랍니다.
중요하지 않은 리소스를 지연하는 것은 LCP 리소스의 상대적 우선순위를 효과적으로 높일 수 있는 또 다른 방법입니다. 예를 들어 분석 스크립트 또는 소셜 위젯과 같이 사용자 인터페이스를 구동하지 않는 스크립트는 load 이벤트가 실행될 때까지 안전하게 연기할 수 있습니다. 이렇게 하면 네트워크 대역폭을 두고 다른 중요 리소스(예: LCP 리소스)와 경쟁하지 않습니다.
요약하면 다음 권장사항에 따라 LCP 리소스가 조기에 높은 우선순위로 로드되도록 해야 합니다.
- LCP 이미지의
<img>태그에fetchpriority="high"를 추가합니다. LCP 리소스가<link rel="preload">태그를 통해 로드되는 경우 여기에fetchpriority="high"를 설정할 수도 있으므로 걱정하지 마세요. - LCP 이미지의
<img>태그에loading="lazy"를 설정하지 마세요. 이렇게 하면 이미지의 우선순위가 낮아지고 로드가 시작될 때 지연이 발생합니다. - 가능하면 중요하지 않은 리소스는 연기하세요. 이 방법은 문서의 끝으로 이동하거나, 이미지 또는 iframe에 네이티브 지연 로드를 사용하거나, 자바스크립트를 통해 비동기식으로 로드하는 것입니다.
CDN을 사용하여 문서 및 리소스 TTFB 최적화
앞의 두 가지 권장사항은 LCP 리소스를 조기에 발견하고 우선순위를 지정하여 즉시 로드를 시작할 수 있도록 하는 데 중점을 두었습니다. 이 퍼즐의 마지막 조각은 초기 문서 응답도 가능한 한 빨리 도착하는지 확인하는 것입니다.
브라우저는 초기 HTML 문서 응답의 첫 번째 바이트를 수신할 때까지 하위 리소스의 로드를 시작할 수 없으며, 첫 번째 바이트가 더 빨리 발생할수록 다른 모든 것이 더 빨리 시작될 수 있습니다.
이 시간을 첫 바이트까지의 시간 (TTFB)이라고 하며, TTFB를 줄이는 가장 좋은 방법은 다음과 같습니다.
- 콘텐츠를 사용자와 지리적으로 최대한 가깝게 제공
- 최근에 요청한 콘텐츠를 빠르게 다시 제공할 수 있도록 해당 콘텐츠를 캐시합니다.
이 두 작업을 수행하는 가장 좋은 방법은 CDN을 사용하는 것입니다. CDN은 전 세계에 분산된 에지 서버에 리소스를 분산하므로 이러한 리소스가 유선을 통해 사용자에게 이동해야 하는 거리가 제한됩니다. 또한 CDN에는 일반적으로 사이트의 요구 사항에 따라 맞춤설정 및 최적화할 수 있는 세분화된 캐싱 제어가 포함되어 있습니다.
많은 개발자가 CDN을 사용하여 정적 자산을 호스팅하는 데 익숙하지만 CDN은 동적으로 생성된 문서도 HTML 문서를 제공하고 캐시할 수 있습니다.
Web Almanac에 따르면 HTML 문서 요청의 29%만 CDN을 통해 처리되었습니다. 이는 사이트에서 추가적인 절감 효과를 누릴 수 있는 상당한 기회가 있음을 의미합니다.
다음은 CDN을 구성하기 위한 몇 가지 팁입니다.
- 콘텐츠가 캐시되는 기간을 늘려보세요 (예: 콘텐츠를 항상 최신 상태로 유지하는 것이 실제로 중요한가요? 아니면 몇 분 정도 비활성 상태일 수 있나요?).
- 콘텐츠를 무기한 캐시한 다음 업데이트할 때 캐시를 삭제하는 것도 고려해 보세요.
- 현재 원본 서버에서 실행 중인 동적 로직을 에지 (대부분의 최신 CDN의 기능)로 이동할 수 있는지 살펴봅니다.
일반적으로 에지에서 직접 콘텐츠를 제공할 수 있으면 (원본 서버로 이동하지 않음) 성능이 향상됩니다. 원본 서버로 되돌아가는 경로를 반드시 거쳐야 하는 경우에도 CDN은 일반적으로 훨씬 더 빠르게 이를 수행하도록 최적화되어 있으므로 어느 쪽이든 좋습니다.
레이아웃 변경 횟수(CLS)
다음 권장사항 모음은 웹페이지의 시각적 안정성의 척도인 레이아웃 변경 횟수 (CLS)에 관한 것입니다. CLS가 2020년 이후 웹에서 많은 개선을 이루었지만 웹사이트 중 약 4분의 1이 여전히 권장 기준을 충족하지 못하므로 많은 사이트에서 사용자 환경을 개선할 수 있는 큰 기회가 여전히 남아 있습니다.
페이지에서 로드된 모든 콘텐츠에 명시적인 크기 설정
레이아웃 변경은 일반적으로 다른 콘텐츠의 로드가 완료된 후 기존 콘텐츠가 이동하면 발생합니다. 따라서 이 문제를 완화하는 기본적인 방법은 필요한 공간을 미리 최대한 많이 예약하는 것입니다.
크기가 지정되지 않은 이미지로 인한 레이아웃 변경을 수정하는 가장 간단한 방법은 width 및 height 속성 (또는 상응하는 CSS 속성)을 명시적으로 설정하는 것입니다. 그러나 HTTP Archive에 따르면 페이지의 72%에 크기가 지정되지 않은 이미지가 하나 이상 포함되어 있습니다. 명시적인 크기가 없으면 브라우저에서 처음에 0px의 기본 높이를 설정하므로 이미지가 최종적으로 로드되고 크기가 확인될 때 눈에 띄는 레이아웃 변경이 발생할 수 있습니다. 이는 집합적인 웹에 엄청난 기회가 있음을 의미하며, 이 글에서 제안하는 다른 권고사항에 비해 훨씬 적은 노력이 요구됩니다.
또한 이미지만이 CLS에 기여하는 것은 아니라는 점도 유의해야 합니다. 레이아웃 변경은 일반적으로 페이지가 처음 렌더링된 후 로드되는 다른 콘텐츠(예: 서드 파티 광고 또는 삽입된 동영상)로 인해 발생할 수 있습니다. aspect-ratio 속성이 이 문제를 해결하는 데 도움이 될 수 있습니다. 이는 개발자가 이미지가 아닌 요소뿐만 아니라 이미지에 가로세로 비율을 명시적으로 제공할 수 있는 비교적 새로운 CSS 기능입니다. 이렇게 하면 동적 width (예: 화면 크기 기반)를 설정할 수 있으며, 크기가 있는 이미지에서와 거의 동일한 방식으로 브라우저가 적절한 높이를 자동으로 계산하도록 할 수 있습니다.
동적 콘텐츠는 본질적으로 동적인 콘텐츠이기 때문에 정확한 크기를 알 수 없는 경우가 있습니다. 그러나 정확한 크기를 모르더라도 레이아웃 변경의 심각도를 줄이는 조치를 취할 수 있습니다. 적절한 min-height을 설정하는 것이 브라우저에서 빈 요소에 기본 높이(0px)를 사용하도록 허용하는 것보다 거의 항상 더 낫습니다. min-height를 사용하는 것도 일반적으로 쉽게 해결할 수 있습니다. 필요한 경우 컨테이너가 최종 콘텐츠 높이까지 증가할 수 있기 때문입니다. 전체 크기에서 더 견딜 수 있는 수준으로 성장하는 정도를 줄였습니다.
페이지가 bfcache를 사용할 수 있는지 확인
브라우저는 뒤로-앞으로 캐시(줄여서 bfcache)라는 탐색 메커니즘을 사용하여 브라우저 기록의 이전 또는 이후 페이지를 메모리 스냅샷에서 바로 로드합니다.
bfcache는 브라우저 수준의 중요한 성능 최적화이며, 많은 사이트에서 대부분의 CLS가 발생하는 페이지 로드 도중의 레이아웃 변경을 완전히 없애줍니다. bfcache의 도입으로 2022년에 관찰된 CLS가 가장 크게 개선되었습니다.
그럼에도 불구하고 많은 웹사이트가 bfcache를 사용할 수 없기 때문에 상당수의 탐색에 관한 무료 웹 성능 혜택을 놓치고 있습니다. 페이지가 메모리에서 복원하고 싶지 않은 민감한 정보를 로드하지 않는 한, 페이지가 적절한지 확인하는 것이 좋습니다.
사이트 소유자는 페이지가 bfcache를 사용할 수 있는지 확인해야 하며 그렇지 못한 이유를 해결해야 합니다. Chrome에는 이미 DevTools에 bfcache 테스터가 있으며 올해에는 유사한 테스트를 수행하는 새로운 Lighthouse 감사와 현장에서 이를 측정하는 API를 통해 도구를 개선할 계획입니다.
CLS 섹션에 bfcache를 포함했지만 지금까지 가장 큰 이득을 확인했으므로 bfcache는 일반적으로 다른 Core Web Vitals도 개선할 것입니다. 페이지 탐색을 크게 개선하는 데 사용할 수 있는 여러 인스턴트 탐색 중 하나입니다.
레이아웃을 유도하는 CSS 속성을 사용하는 애니메이션/전환 피하기
레이아웃 변경의 또 다른 일반적인 원인은 요소에 애니메이션이 적용되는 경우입니다. 예를 들어 상단 또는 하단에서 슬라이드되는 쿠키 배너 또는 기타 알림 배너는 종종 CLS에 기여합니다. 이는 배너가 다른 콘텐츠를 화면 밖으로 밀어내는 경우 특히 문제가 되지만, 콘텐츠가 표시되지 않는 경우에도 애니메이션은 CLS에 여전히 영향을 미칠 수 있습니다.
HTTP Archive 데이터가 애니메이션을 레이아웃 변경에 확실하게 연결할 수는 없지만, 데이터에 따르면 레이아웃에 영향을 미칠 수 있는 CSS 속성에 애니메이션을 적용하는 페이지가 '양호'할 가능성이 15% 낮습니다. CLS가 더 높습니다. 일부 속성은 다른 속성보다 더 나쁜 CLS와 관련이 있습니다. 예를 들어 margin 또는 border 너비를 애니메이션화하는 페이지는 '나쁨'을 보입니다. CLS는 전반적으로 페이지가 낮은 것으로 평가되는 비율의 거의 두 배에 달합니다.
이는 놀라운 일이 아닙니다. 레이아웃을 유도하는 모든 CSS 속성을 전환하거나 애니메이션화할 때마다 레이아웃 변경이 발생하고 이러한 레이아웃 변경이 사용자 상호작용 후 500밀리초 이내에 발생하지 않으면 CLS에 영향을 미치기 때문입니다.
일부 개발자에게 놀라운 점은 요소가 일반적인 문서 흐름에서 벗어나는 경우에도 이러한 사실이 사실이라는 것입니다. 예를 들어 top 또는 left에 애니메이션을 적용하는 절대 위치로 배치된 요소는 다른 콘텐츠를 밀어내지 않더라도 레이아웃 변경을 야기합니다. 그러나 top 또는 left에 애니메이션을 적용하는 대신 transform:translateX() 또는 transform:translateY()에 애니메이션을 적용하는 경우 브라우저가 페이지 레이아웃을 업데이트하지 않으므로 레이아웃이 변경되지 않습니다.
브라우저의 컴포지터 스레드에서 업데이트할 수 있는 CSS 속성 애니메이션을 사용하는 것이 오랫동안 성능 권장사항이었습니다. GPU로 그리고 기본 스레드 외부로 작업을 이동하기 때문입니다. 이는 일반적인 성능 권장사항일 뿐만 아니라 CLS 개선에도 도움이 될 수 있습니다.
일반적으로 브라우저에서 페이지 레이아웃을 업데이트해야 하는 CSS 속성에 애니메이션을 적용하거나 전환하지 마세요. 단, 사용자 탭이나 키 누름에 대한 응답으로 이 작업을 수행하는 경우는 hover가 아닙니다. 그리고 가능하면 CSS transform 속성을 사용하는 전환과 애니메이션을 사용하세요.
Lighthouse 감사 비합성 애니메이션 피하기는 페이지에서 속도가 느릴 수 있는 CSS 속성에 애니메이션을 적용하면 경고를 표시합니다.
최초 입력 반응 시간(FID)
<ph type="x-smartling-placeholder">마지막 권장사항은 사용자 상호작용에 대한 페이지 반응성을 측정하는 최초 입력 반응 시간 (FID)입니다. 현재 대부분의 웹 사이트는 FID에 매우 높은 점수를 얻고 있지만, Google은 과거에 FID 측정항목의 단점을 기록했으며, 사이트에서 사용자 상호작용에 대한 전반적인 응답성을 개선할 기회가 여전히 많이 있다고 생각합니다.
새로운 Interaction to Next Paint (INP) 측정항목은 FID의 후속 조치일 수 있으며, 아래의 모든 권장사항은 FID와 INP 모두에 동일하게 적용됩니다. 사이트가 FID보다 INP에서, 특히 모바일에서 실적이 낮다는 점을 감안하면 개발자는 FID를 지정합니다.
장기 작업 방지 또는 분할
할 일 목록은 브라우저가 수행하는 모든 개별 작업입니다. 작업에는 스크립트 렌더링, 레이아웃, 파싱, 컴파일, 실행이 포함됩니다. 작업이 장기 작업(50밀리초 이상)이 되면 기본 스레드가 사용자 입력에 빠르게 응답하지 못합니다.
Web Almanac에 따르면 개발자가 장기 작업을 피하거나 분해하기 위해 더 많은 노력을 기울일 수 있음을 시사하는 수많은 증거가 있습니다. 긴 작업을 분할하는 것은 이 도움말의 다른 권장사항만큼 적은 노력이 필요하지 않을 수 있지만 이 도움말에서 제공하지 않은 다른 기법에 비해 덜 쉬울 수 있습니다.
항상 JavaScript에서 가능한 한 적은 작업을 하도록 노력해야 하지만 장기 작업을 더 작은 작업으로 분할하여 기본 스레드를 상당히 도울 수 있습니다. 자주 기본 스레드를 제공하여 렌더링 업데이트 및 다른 사용자 상호작용이 더 빠르게 발생할 수 있도록 하면 됩니다.
또 다른 옵션은 isInputPending 및 Scheduler API와 같은 API를 사용하는 것입니다. isInputPending는 사용자 입력이 대기 중인지 나타내는 불리언 값을 반환하는 함수입니다. true를 반환하면 대기 중인 사용자 입력을 처리할 수 있도록 기본 스레드에 양보할 수 있습니다.
Scheduler API는 보다 발전된 접근 방식으로, 수행 중인 작업이 사용자에게 표시되는지 아니면 백그라운드로 실행되는지 고려하는 우선순위 시스템을 기반으로 작업을 예약할 수 있습니다.
장기 작업을 분할하면 브라우저가 상호작용 및 이에 따른 렌더링 업데이트 처리와 같이 사용자가 볼 수 있는 중요한 작업에 더 많은 기회를 제공할 수 있습니다.
불필요한 자바스크립트 피하기
웹사이트가 그 어느 때보다 많은 JavaScript를 제공하고 있으며 이러한 트렌드는 당연히 변화할 것 같지 않다는 점은 의심의 여지가 없습니다. 너무 많은 JavaScript를 제공하면 기본 스레드의 주의를 끌기 위해 작업이 경쟁하는 환경이 만들어집니다. 이는 특히 중요한 시작 기간에 웹사이트의 반응성에 확실히 영향을 미칠 수 있습니다.
그러나 이 문제는 해결할 수 없는 문제가 아닙니다. 다음과 같은 옵션이 있습니다.
- Chrome DevTools의 적용 범위 도구를 사용하여 웹사이트 리소스에서 사용되지 않는 코드를 찾습니다. 시작 시 필요한 리소스의 크기를 줄이면 웹사이트에서 코드를 파싱하고 컴파일하는 시간을 줄여 초기 사용자 환경을 더 원활하게 만들 수 있습니다.
- 적용 범위 도구를 사용하여 찾은 미사용 코드가 '사용되지 않음'으로 표시되는 경우가 있습니다. 시작 시 실행되지 않았지만 향후 일부 기능에는 여전히 필요하기 때문입니다. 이 코드는 코드 분할을 통해 별도의 번들로 이동할 수 있는 코드입니다.
- 태그 관리자를 사용하는 경우 태그가 최적화되어 있는지 정기적으로 확인하거나 태그가 아직 사용 중인지도 확인해야 합니다. 사용하지 않는 코드가 있는 이전 태그를 삭제하여 태그 관리자의 JavaScript를 더 작고 효율적으로 만들 수 있습니다.
대규모 렌더링 업데이트 피하기
자바스크립트 외에도 웹사이트의 응답성에 영향을 줄 수 있습니다. 렌더링은 그 자체로 비용이 많이 드는 일종의 작업일 수 있습니다. 대규모 렌더링 업데이트가 발생하면 웹사이트의 사용자 입력 응답 기능에 지장을 줄 수 있습니다.
렌더링 작업 최적화는 간단한 프로세스가 아니며 달성하려는 목표에 따라 달라질 수 있습니다. 그럼에도 불구하고 렌더링 업데이트가 합리적인지 확인하고 장기 작업으로 확장되지 않도록 할 수 있는 몇 가지 방법이 있습니다.
- 비시각적 작업에는
requestAnimationFrame()를 사용하지 마세요.requestAnimationFrame()호출은 이벤트 루프의 렌더링 단계에서 처리되며, 이 단계에서 너무 많은 작업이 실행되면 렌더링 업데이트가 지연될 수 있습니다.requestAnimationFrame()로 실행하는 모든 작업은 렌더링 업데이트와 관련된 작업용으로만 예약되어야 합니다. - DOM 크기를 작게 유지합니다. DOM 크기와 레이아웃 작업의 강도는 상관관계가 있습니다. 렌더러가 매우 큰 DOM의 레이아웃을 업데이트해야 하는 경우 레이아웃을 다시 계산하는 데 필요한 작업이 상당히 증가할 수 있습니다.
- CSS 포함을 사용합니다. CSS 포함은 CSS
contain속성을 사용합니다. 이 속성은contain속성이 설정된 컨테이너에서 레이아웃 작업을 하는 방법을 브라우저에 알려줍니다. 여기에는 레이아웃 범위 격리와 DOM의 특정 루트 렌더링도 포함됩니다. 항상 쉬운 프로세스는 아니지만 복잡한 레이아웃이 포함된 영역을 분리하면 필요하지 않은 영역에서 레이아웃 및 렌더링 작업을 실행하지 않을 수 있습니다.
결론
특히 고려해야 할 안내가 웹 전반에 많다는 점을 고려할 때, 페이지 성능을 개선하는 것은 어려운 작업처럼 보일 수 있습니다. 그러나 이러한 권장사항에 집중하면 중점과 목적을 가지고 문제에 접근하고 웹사이트의 Core Web Vitals를 개선할 수 있습니다.
여기에 나열된 권장사항이 완전한 것은 아니지만 웹 상태를 신중하게 분석한 결과에 따르면 이러한 권장사항이 사이트에서 2023년에 Core Web Vitals 성능을 개선할 수 있는 가장 효과적인 방법이라고 생각합니다.
여기에 나와 있는 권장사항 외에 더 자세히 알아보려면 다음 최적화 가이드를 참조하세요.
새해에는 모두가 더 빠른 인터넷으로 인터넷을 사용할 수 있기를 바랍니다. 사용자에게 가장 중요한 모든 방식으로 사이트 속도가 빨라지기를 바랍니다.
사진 제공: Devin Avery