이 글은 Google web.dev의 아티클 'Our top Core Web Vitals recommendations for 2023'을 한국어로 옮긴 것입니다. 원본 콘텐츠에는 Creative Commons Attribution 4.0 (CC-BY-4.0) 라이선스가 부여되어 있습니다.
지난 몇 년 동안, Google에서는 웹 개발자들에게 성능 향상을 위한 다양한 권장사항들을 제시해 왔습니다.
이러한 사항들 각각은 많은 사이트에서 성능 향상에 도움이 될 수 있는 것들이기는 하지만, 현실적으로 어떤 특정한 사람이나 사이트가 이러한 권장사항들 전체를 모두 따르는 것은 불가능한 일입니다.
성능을 향상시키는 것이 당신의 일상적인 업무가 아니라면, 어떠한 권장사항이 사이트에 가장 긍정적인 영향을 미치는 것인지 명확하지 않을 수도 있습니다. 예를 들어, 중요한(critical) CSS를 구현하면 로드 성능이 향상될 수 있다는 것을 알지만, 이미지를 최적화하는 것 또한 중요하다는 사실을 들어보았을 수 있습니다. 그러면 이 둘 중에 어떤 것을 선택해야 할지 결정하기가 어려울 것입니다.
Chrome 팀에서는 작년부터 이러한 질문에 대한 답을 찾고자 노력해 왔습니다. 사용자 성능을 개선하기 위해 개발자들이 따라야 할 가장 중요한 권장 사항은 무엇일까요?
이 질문에 적절하게 대답하려면, 단순히 기술적인 측면을 고려하는 것뿐만 아니라 개발자가 실제로 이러한 권장사항을 채택할 수 있는 가능성에 영향을 미칠 인적 및 조직적인 요인도 함께 고려해야 합니다. 즉, 이론적으로는 막대한 영향을 미칠 수 있는 권장사항이라도 실제로는 시간이나 리소스가 부족하여 구현하기 어려운 사이트가 대부분일 수 있습니다. 마찬가지로, 어떤 권장사항은 중요하긴 하지만 이미 대부분의 사이트가 관행적으로 따르고 있는 것일 수 있습니다.
요컨대, 저희는 성능을 개선할 수 있는 권장사항으로 다음과 같은 사항에 초점을 맞추고자 했습니다 :
- 실무(real-world)에서 가장 큰 영향력을 미칠 것으로 기대되는 권장사항
- 대부분의 사이트와 관련되고 적용 가능성이 높을 권장사항
- 대부분의 개발자들이 구현하기에 현실적인 권장사항
작년 한 해 동안 저희가 제시했던 성능 권장사항 전반에 대해 감사(auditing)하고, 위 세 가지 기준에 따라 각 사항들을 평가(정성적, 정량적 모두)하는 데에 많은 시간을 보냈습니다.
이 글에서는 Core Web Vitals 메트릭의 성능을 개선하기 위한 주요 권장사항들을 소개하고자 합니다. 웹 성능에 대해 처음 접하는 경우, 또는 가장 효과적인 방법을 찾고자 하는 경우 이러한 권장사항들이 가장 적절한 시작점이 될 것이라고 생각합니다.
Largest Contentful Paint (LCP)
첫 번째 권장사항으로는 페이지 로드 성능의 척도가 되는 LCP(Largest Contentful Paint)에 대한 것입니다. 세 가지 Core Web Vitals 메트릭 중, LCP는 가장 많은 사이트에서 어려움을 겪고 있는 부분입니다. 오늘날 웹의 모든 사이트들 중 약 절반만이 권장 스코어를 충족하고 있습니다. 그럼 여기부터 시작해 보겠습니다.
HTML 소스에서 LCP 리소스를 찾을 수 있는지 확인하기
HTTP Archive의 Web Almanac(2022)에 따르면, 모바일 페이지의 72%가 LCP 요소로 이미지를 사용하고 있습니다. 이는 대부분의 사이트가 LCP를 최적화하기 위해서는 이미지를 빠르게 로드해야 한다는 사실을 의미합니다.
많은 개발자들에게 있어 모호하게 여겨질 만한 사실은, 이미지를 로드하는 데 소요되는 시간은 전체 문제의 일부분에 불과하다는 것입니다. 또 다른 중요한 부분은 이미지가 로드되기 시작하기 전의 시간이라고 할 수 있으며, HTTP Archive의 데이터는 실제로 많은 사이트들에서 이 문제가 발생하고 있음을 시사하고 있습니다.
실제로 LCP 요소가 이미지인 페이지 중 39%는 HTML 소스에서 URL을 찾을 수 없는 경우였습니다. 이러한 이미지는 브라우저가 빠르게 발견하고 즉시 로드할 수 없는데, 표준 HTML 속성(예: <img src="..."> 또는 <link rel="preload" href="...">)에서 소스 URL을 찾을 수 없었기 때문입니다.
이미지 로드를 시작하기 전에 CSS 또는 JavaScript 파일이 완전히 다운로드되고 파싱될 때까지 기다려야 한다면, 그 때는 이미 너무 늦었을 수 있습니다.
일반적으로 LCP 요소가 이미지인 경우, 이미지의 URL은 항상 HTML 소스 상에서 찾을 수 있어야 합니다. 이를 가능케 하는 몇 가지 팁은 다음과 같습니다 :
src또는srcset속성을 가진<img>요소를 사용하여 이미지를 로드합니다. 렌더링하기 위해 JavaScript가 필요한data-src와 같은 비표준 속성은 항상 더 느리므로 사용하지 않아야 합니다. 약 9%의 페이지가data-src속성으로 LCP 이미지를 로드하고 있습니다.- 클라이언트 렌더링(CSR)보다는 서버 렌더링(SSR)을 지향합니다. SSR은 전체 페이지 마크업(이미지 포함)이 HTML 문서에 포함되어 있음을 의미합니다. CSR 솔루션은 이미지를 찾기 전에 JavaScript를 실행해야 합니다.
- 외부 CSS 또는 JS 파일에서 이미지를 참조해야 하는 경우,
<link rel="preload">태그를 사용하여 HTML 소스에 포함합니다. 인라인 스타일이 참조하는 이미지는 브라우저의 사전 로드 스캐너(preload scanner)에서 찾을 수 없으므로, HTML 소스에서 발견되더라도 다른 리소스를 로드할 때까지 이미지 로드가 차단될 수 있습니다. 이런 경우에는 사전 로드가 도움이 될 수 있습니다.
LCP 이미지에 이러한 문제가 있는지 확인하는 데에 도움이 될 수 있도록, Lighthouse 10.0 버전에서 새로운 측정 항목을 추가할 예정입니다. (2023년 1월 예정)
HTML 소스에서 LCP 리소스를 찾을 수 있는지 확인하면 측정 가능한 개선으로 이어질 수 있으며, 다음 권장사항인 리소스 우선 순위를 지정할 수 있는 추가적인 기회도 얻을 수 있게 됩니다.
LCP 리소스의 우선 순위를 지정했는지 확인하기
HTML 소스에서 LCP 리소스를 찾을 수 있는지 확인하는 것은 LCP 리소스가 조기에 로드될 수 있도록 하는 중요한 첫 번째 단계이지만, 또 다른 중요한 단계는 해당 리소스가 로드되는 우선 순위를 지정하여 다른 덜 중요한 리소스들로 인해 대기하지 않게끔 하는 것입니다.
예를 들어, HTML 소스에서 기본적인 <img> 태그를 사용한 LCP 이미지가 존재한다 하더라도, 페이지가 그 <img> 태그보다 더 많은 <head>의 <script> 태그를 포함한다면, 이미지 리소스가 로드되기 전까지 다소 시간이 걸릴 수 있습니다.
이 문제를 해결하는 가장 쉬운 방법은, LCP 이미지를 로드하는 <img> 또는 <link> 태그에 fetchpriority="high" 속성을 설정하여 어떤 리소스가 최우선 순위인지에 대한 힌트를 브라우저에 제공하는 것입니다. 이렇게 하면 리소스를 더 빨리 로드할 수 있게 하고, 스크립트가 완료될 때까지 기다리지 않을 수 있습니다.
Web Almanac에 따르면, 이 새로운 API를 활용하는 페이지는 적격한 페이지의 0.03%에 불과했습니다. 이는 대부분의 사이트에서 약간의 작업으로도 LCP를 개선할 충분한 기회가 있음을 의미합니다. fetchpriority 속성은 현재 Chromium 기반 브라우저에서만 지원되지만, 다른 브라우저에서는 그냥 무시되는 점진적인 개선사항이므로 지금 바로 사용할 것을 권장합니다.
Chromium 기반 브라우저가 아닌 경우라면, 문서의 앞부분에서 LCP 리소스를 먼저 참조하는 것이 유일한 방법입니다. <head>에 많은 <script>가 포함된 사이트인 경우의 예를 다시 들자면, LCP 리소스가 그 스크립트 리소스들보다 먼저 로드될 수 있도록 <link rel="preload"> 태그를 스크립트보다 앞에 추가하거나, 해당 스크립트를 <img> 태그 이후의 <body> 안으로 옮길 수 있습니다. 이 방법은 유효하긴 하지만, fetchpriority 속성을 사용하는 것보다는 불편하므로 다른 브라우저에서도 곧 지원될 수 있기를 바라고 있습니다.
LCP 리소스의 우선 순위를 지정하는 또 다른 중요한 측면은, loading="lazy" 속성을 추가하는 식으로 리소스의 우선 순위를 낮추지 않는 것입니다. 오늘날 10%의 페이지에서는 LCP 이미지에 lazy 속성을 설정하고 있습니다. 모든 이미지에 무차별적으로 지연 로딩(lazy loading)을 적용하는 이미지 최적화 솔루션에 유의해야 합니다. 해당 동작을 재정의하는 방법을 제공하고자 한다면, LCP 이미지에 적용해야 합니다. 어떤 이미지가 LCP인지 불확실하다면, 합리적인 후보를 택하기 위해 휴리스틱을 사용해 보시길 바랍니다.
중요하지 않은 리소스를 지연시키는 것은 LCP 리소스의 상대적인 우선순위를 효과적으로 높일 수 있는 또 다른 방법입니다. 예를 들어, UI와 관련되지 않는 스크립트(분석 스크립트나 소셜 위젯 등)는 로드 이벤트가 발생한 이후로 안전하게 지연할 수 있으므로, 네트워크 대역폭을 두고 다른 중요한 리소스(예: LCP 리소스)와 경쟁하지 않도록 할 수 있습니다.
요약하면, LCP 리소스가 조기에 높은 우선순위로 로드되도록 보장하기 위해 다음과 같은 모범 사례를 따르는 것이 좋습니다.
- LCP 이미지의
<img>태그에fetchpriority="high"속성을 추가하세요. 만약 LCP 리소스가<link rel="preload">태그로 로드되어도 이 속성을 사용할 수 있으므로 걱정하지 않아도 됩니다.- LCP 이미지의
<img>태그에loading="lazy"속성을 설정하지 마세요. 이럴 경우 이미지의 우선순위가 낮아지고 로드 시작이 지연됩니다.- 가능한 필수적이지 않은 리소스를 지연시키세요. 이미지 또는 iframe에 기본 지연 로딩을 적용하여 문서의 끝으로 이동시키거나, JavaScript를 통해 비동기식으로 로드합니다.
CDN을 사용하여 문서 및 리소스 TTFB 최적화하기
앞의 두 가지 권장사항은 LCP 리소스를 조기에 발견하고 우선 순위를 지정하여 즉시 로드될 수 있도록 하는 데 중점을 두었습니다. 이 퍼즐의 마지막 조각은, 초기 문서의 응답도 가능한 빨리 도착하도록 하는 것입니다.
브라우저는 초기 HTML 문서 응답에 대한 첫 번째 바이트를 수신할 때까지는 하위 리소스(subresources)도 로드할 수 없기에, 이것이 빠르게 발생할수록 다른 모든 작업들도 더 빨리 시작될 수 있습니다.
이러한 시간을 Time to First Byte (TTFB)라고 하며, TTFB를 줄이는 가장 좋은 방법은 다음과 같습니다:
- 가능한 사용자와 지리적으로 인접한 콘텐츠 제공
- 최근에 요청한 콘텐츠를 빠르게 다시 제공할 수 있도록 캐시
이 두 가지 모두를 수행하는 가장 좋은 방법은 바로 CDN을 사용하는 것입니다. CDN은 전 세계적으로 분산되어 있는 엣지 서버에 리소스를 배포하므로, 리소스가 사용자에게 도달하는 거리를 줄일 수 있습니다. 또한 대부분의 CDN에는 일반적으로 사이트의 요구사항에 맞게 재정의하고 최적화 할 수 있는 세분화된 캐싱 컨트롤 기능을 제공합니다.
많은 개발자가 CDN을 사용하여 정적 에셋을 호스팅하는 데에 익숙하지만, 사실 CDN은 동적으로 생성되는 HTML 문서 역시 서비스하고 캐시할 수 있습니다.
Web Almanac에 따르면, HTML 문서 요청 중 29%만이 CDN에서 제공되었으며 이는 많은 사이트에서 추가적인 비용 절감을 달성할 수 있는 기회가 있음을 의미합니다.
CDN 구성에 대한 몇 가지 팁은 다음과 같습니다.
- 콘텐츠가 얼마나 오래 캐시될 수 있는지 고려하세요. (예를 들어, 정말로 콘텐츠가 항상 최신이어야만 하는지, 아니면 몇 분이나 오래될 수 있는지)
- 콘텐츠를 무기한 캐싱하고, 다음 업데이트 때 제거하는 것을 고려하세요.
- 현재 오리진 서버에서 실행 중인 로직을 엣지 서버로 옮길 수 있는지 알아보세요.
일반적으로, 엣지에서 직접 콘텐츠를 제공할 수 있는 경우 성능 향상에 도움이 됩니다. 그리고 오리진 서버로 다시 돌아가야 하는 경우라 하더라도, CDN은 일반적으로 훨씬 더 빠르게 처리할 수 있도록 최적화되어 있으므로 어떤 경우에도 유리합니다.
Cumulative Layout Shift (CLS)
다음 권장사항은 웹 페이지의 시각적 안정성(visual stability)을 측정하는 Cumulative Layout Shift (CLS)에 대한 것입니다. CLS는 2020년 이후 많이 개선되었지만, 여전히 권장되는 스코어를 충족하지 못하는 웹 사이트가 약 4분의 1 정도 존재하므로, 많은 사이트에서 사용자 경험을 개선할 기회가 여전히 존재하고 있습니다.
페이지에서 로드되는 모든 콘텐츠에 명시적인 크기를 설정하기
레이아웃 이동(Layout shifts)이란 일반적으로 다른 콘텐츠가 로드된 후 기존 콘텐츠가 이동할 때 발생합니다. 따라서 필요한 공간을 가능한 미리 예약해 두는 것이 기본적인 방법이라고 할 수 있습니다.
크기가 지정되지 않은 이미지에 의해 발생하는 레이아웃 이동을 해결하는 가장 직관적인 방법은 width 및 height 속성(또는 이와 동등한 CSS 속성)을 명시적으로 설정하는 것입니다. 하지만 HTTP Archive에 따르면, 페이지 중 72%가 크기가 지정되지 않은 이미지를 하나 이상 포함하고 있습니다. 명시적인 크기가 지정되어 있지 않으면, 브라우저는 초기 높이를 0px로 설정하기 때문에 이미지가 최종적으로 로드된 이후 크기를 파악하는 단계에서 레이아웃 이동이 발생할 수 있습니다. 이는 이 글에서 제안하는 다른 권장사항들보다도 훨씬 적은 노력으로도 많은 개선을 제공할 수 있는 기회입니다.
이미지만이 CLS에 관여하는 것이 아니라는 점을 염두에 두는 것도 중요합니다. 제 3자(third-party) 광고나 임베드된 동영상 등 다른 콘텐츠로 인해 레이아웃 이동이 발생할 수 있습니다. 이때는 aspect-ratio 속성이 도움이 될 수 있습니다. 이는 비교적 새로운 CSS 기능으로, 개발자가 이미지뿐만 아니라 이미지가 아닌 요소에 대해서도 명시적으로 종횡비를 지정할 수 있게 합니다. 이를 통해 동적으로 width를 설정(예: 화면 크기에 따라)하고, 브라우저가 마치 이미지와 같은 방식으로 적절한 높이를 자동으로 계산하게끔 할 수 있습니다.
동적 콘텐츠는 본질적으로 동적이기 때문에 정확한 크기를 알 수 없습니다. 하지만 정확한 크기를 모르더라도, 레이아웃 이동으로 인한 문제를 줄이기 위한 조치는 취할 수 있습니다. 빈 요소에 대해 적절한 min-height를 설정하는 것이 기본 높이인 0px을 허용하는 것보다 거의 항상 더 좋습니다. min-height를 사용하는 것은 필요한 경우 컨테이너가 최종 콘텐츠 높이까지 확장될 수 있도록 하면서, 전체 크기 대비 적정한 수준으로만 확장의 폭을 줄인 것이므로 일반적으로 간단한 해결책이라고 할 수 있습니다.
페이지가 bfcache에 적합한지 확인하기
브라우저는 back/forward cache(줄여서 bfcache)라는 내비게이션 메커니즘을 사용하여 메모리 스냅샷에서 직접 브라우저 히스토리의 이전 또는 이후 페이지를 즉시 로드합니다.
bfcache는 브라우저 수준의 중요한 성능 최적화이며, 많은 사이트에서 대부분의 CLS가 발생하는 지점인 페이지 로드 과정에서 레이아웃 이동을 완전히 제거할 수 있습니다. bfcache의 도입은 2022년에 가장 큰 폭의 CLS 개선을 가져온 일이었습니다.
하지만 그럼에도 많은 웹 사이트들이 bfcache에 부적격하여, 상당수가 이 대가 없는 성능 개선의 기회를 놓치고 있습니다. 페이지에서 메모리에서 복원되기를 원하지 않는 민감한 정보가 로드되는 경우가 아닌 한, 페이지가 bfcache의 조건을 충족하는지를 확인해야 합니다.
사이트 소유자는 페이지가 bfcache에 적격한지 확인하고 그렇지 않은 이유에 대해 조사해 보아야 합니다. Chrome은 이미 DevTools에서 bfcache 테스트 도구를 갖추고 있으며, 올해에는 이와 유사한 테스트를 수행하는 새로운 Lighthouse 측정 항목과 이를 필드에서 측정할 수 있는 API를 추가할 계획입니다.
가장 큰 이득을 얻었다는 점에서 CLS 섹션에서 bfcache를 다루기는 했지만, 일반적으로 bfcache는 다른 Core Web Vitals도 개선시켜 줍니다. bfcache는 페이지 탐색을 극적으로 개선할 수 있는 여러 지침들 중 하나일 뿐입니다.
레이아웃을 유발하는 CSS 속성을 사용하는 애니메이션/트랜지션 피하기
레이아웃 이동의 또 다른 일반적인 원인은 요소에 애니메이션이 적용될 때입니다. 예를 들어, 쿠키 배너나 상/하단에서 슬라이드되는 알림 배너 등은 종종 CLS의 요인이 될 수 있습니다. 이러한 배너가 다른 콘텐츠를 밀어내는 경우 특히 문제가 되지만, 그렇지 않은 경우에도 애니메이션이 CLS에 영향을 미칠 수 있습니다.
HTTP Archive 데이터는 애니메이션과 레이아웃 이동을 명확하게 연결시키지는 못하지만, 레이아웃에 영향을 미칠 가능성이 있는 CSS 속성에 애니메이션을 적용하는 페이지가 '좋은' CLS를 가질 가능성이 15% 가량 더 낮다는 사실을 보여줍니다. 특정 속성은 다른 속성보다 나쁜 CLS와 연관되어 있습니다. 예로 margin이나, border의 width를 애니메이트하는 페이지는 일반적으로 거의 두 배의 비율로 나쁜 CLS 평가를 받습니다.
레이아웃을 유발하는 CSS 속성을 전환하거나 애니메이션을 적용할 때마다 항상 레이아웃 이동이 발생하게 되고, 이러한 레이아웃 이동은 사용자의 상호작용 이후 500ms 이내에 발생하지 않은 경우 CLS에 영향을 미치게 된다는 사실 때문일 것입니다.
일부 개발자들에게 있어 놀라울 만한 사실은, 요소가 일반적인 문서의 흐름에서 벗어난 외부에서 발생한 경우라도 레이아웃 이동으로 간주될 수 있다는 것입니다. 예를 들면, 다른 콘텐츠를 밀어내지 않더라도 절대 위치(absolute position)로 배치된 요소를 top 또는 left로 애니메이트하면 레이아웃을 야기하게 될 수 있습니다. 하지만 대신 transform: translateX() 또는 transform: translateY()를 사용한다면 브라우저가 페이지 레이아웃을 업데이트하지 않으므로, 레이아웃 이동이 발생하지 않을 수 있습니다.
브라우저의 Compositor thread에서 업데이트할 수 있는 CSS 속성의 애니메이션을 선호하는 것은 오랫동안 성능 개선의 모범적인 사례였습니다. 이는 작업을 GPU로 이동하여 메인 스레드에서 제거되도록 하기 때문입니다. 이는 일반적인 성능 개선의 가장 좋은 방법일 뿐만 아니라, CLS를 개선하는 데에도 도움이 될 수 있습니다.
일반적으로 사용자의 탭 또는 키 입력(hover는 아님)에 대한 응답으로 하는 경우를 제외하고는 페이지의 레이아웃을 업데이트해야 하는 CSS 속성에 애니메이션 또는 트랜지션을 적용하지 않아야 합니다. 가능한 CSS transform 속성을 사용한 트랜지션 및 애니메이션을 지향하세요.
Lighthouse 측정 항목 중 '합성되지 않은 애니메이션 회피(Avoid non-composited animations)'는 페이지가 느릴 가능성이 있는 CSS 속성을 애니메이트하려고 할 때 경고합니다.
First Input Delay (FID)
저희가 마지막으로 추천하는 것은 사용자 상호작용에 대한 페이지 응답성을 측정하는 FID(First Input Delay)에 대한 것입니다. 대부분의 웹 사이트가 현재 FID에서 매우 높은 스코어를 달성하고 있지만, 저희는 과거에 FID 메트릭의 결점을 문서화했으며, 여전히 사이트에서 전반적으로 사용자 상호작용에 대한 응답성을 개선할 수 있는 많은 기회가 있다고 생각합니다.
저희의 새로운 Interaction to Next Paint(INP) 메트릭은 FID의 후속이며, 아래의 모든 권장 사항들은 FID와 INP에 모두 동일하게 적용될 수 있습니다. 특히 모바일을 비롯한 다양한 플랫폼에서 FID보다 INP가 더 나쁘게 측정되고 있으므로, '좋은' FID를 갖고 있더라도 개발자들은 이러한 응답성 권장사항들을 중요하게 고려해 볼 것을 권합니다.
긴 작업을 피하거나 분산하기
작업(task)은 브라우저가 수행하는 모든 개별적인 작업(work)들을 의미합니다. 렌더링, 레이아웃, 파싱, 스크립트의 컴파일 및 실행을 포함됩니다. 작업이 '긴 작업(long tasks)'이 되면(즉, 50ms 이상), 메인 스레드가 사용자 입력에 빠르게 응답하지 못하게 하는 블로킹이 발생합니다.
Web Almanac에 따르면, 개발자들이 이러한 긴 작업을 피하거나 분산하는 데 더 많은 작업을 수행할 수 있음을 시사하는 많은 증거가 있습니다. 긴 작업을 나누는 것은 이 글에서 다루는 다른 권장사항들만큼 노력이 적게 들지는 않지만, 이 글에서 제공하지 않는 다른 기술들보다는 덜 듭니다.
항상 JavaScript에서 가능한 한 적은 작업을 수행하려고 노력해야 하지만, 긴 작업을 더 작은 작업으로 분할하는 것으로 메인 스레드를 도울 수 있습니다. 이렇게 하면 렌더링 업데이트 및 기타 사용자 상호작용들이 더 빠르게 발생할 수 있도록 메인 스레드에 작업을 자주 양보할 수 있습니다.
다른 방법으로는 isInputPending 및 Scheduler API와 같은 API를 사용하는 것을 고려해볼 수 있습니다. isInputPending은 보류 중(pending)인 사용자 입력이 있는지 여부를 나타내는 boolean 값을 반환하는 함수입니다. true를 반환하면 보류 중이었던 사용자 입력을 처리할 수 있도록 메인 스레드에 작업을 양보할 수 있습니다.
Scheduler API는 더 고도화된 접근 방식으로, 수행 중인 작업이 사용자가 볼 수 있는 작업인지 또는 백그라운드 작업인지를 고려하는 우선 순위 시스템을 기반으로 작업을 예약할 수 있도록 해 줍니다.
긴 작업을 분산하면 상호작용 및 그와 관련된 렌더링 업데이트와 같이 사용자가 볼 수 있는 작업을 수행할 수 있는 기회를 브라우저에게 더 많이 제공할 수 있습니다.
불필요한 자바스크립트 피하기
의심의 여지가 없습니다. 웹 사이트는 그 어느 때보다 더 많은 JavaScript를 제공하고 있으며, 이러한 추세는 금방 바뀌지 않을 것으로 보입니다. JavaScript가 너무 많이 로드되면, 작업들이 메인 스레드의 주의를 끌기 위해 경합하는 환경이 조성됩니다. 이는 특히 초기 시점에서 웹 사이트의 반응성에 있어 확실한 영향을 미칠 수 있습니다.
그러나 이러한 문제는 해결될 수 있습니다. 몇 가지 방법이 있습니다.
- Chrome DevTools의 커버리지 도구를 사용하여 웹 사이트 리소스에서 사용되지 않는 코드를 찾아낼 수 있습니다. 초기 단계에서 필요한 리소스의 크기를 줄이면 코드를 구문 분석하고 컴파일하는 데 필요한 시간이 줄어들어 초기 사용자 경험을 더 원활하게 만들 수 있습니다.
- 커버리지 도구를 사용하여 찾은 사용되지 않는 코드 중에서는 초기에 실행되지 않았지만, 이후에는 필요한 기능이 있는 코드가 포함되어 있을 수 있습니다. 이러한 코드는 코드 분할을 통해 별도의 번들로 이동시킬 수 있습니다.
- 태그 매니저를 사용하는 경우, 정기적으로 태그가 최적화되어 있는지 또는 여전히 사용되고 있는지를 확인하세요. 사용하지 않는 코드가 포함된 이전 버전의 태그는 제거하여 태그 매니저의 JavaScript를 더 작고 효율적으로 만들 수 있습니다.
대규모 렌더링 업데이트 방지하기
웹 사이트의 응답성에 영향을 미칠 수 있는 것은 JavaScript 뿐만이 아닙니다. 렌더링은 그 자체로 비용이 많이 드는 작업일 수 있고, 대규모 렌더링 업데이트가 발생하면 사용자 입력에 응답하는 웹 사이트의 기능에 방해가 될 수 있습니다.
렌더링 작업을 최적화하는 것은 간단한 프로세스가 아니며, 때때로 달성하려는 목표에 따라 달라지는 경우가 많습니다. 다만 그렇더라도 렌더링 업데이트가 긴 작업으로 확장되지 않도록 다음과 같은 몇 가지 작업을 수행해볼 수 있습니다:
requestAnimationFrame()을 시각적인 요소와 관련되지 않은 작업에 사용하지 마세요.requestAnimationFrame()호출은 이벤트 루프의 렌더링 단계에서 처리되며, 여기서 너무 많은 작업이 수행되면 렌더링 업데이트가 지연될 수 있기 때문입니다. 수행 중인 모든 작업은requestAnimationFrame()렌더링 업데이트와 관련된 작업을 위해 엄격하게 예약되어 있어야 합니다.- DOM 크기를 가능한 작게 유지하세요. DOM 크기와 레이아웃 작업의 강도는 상관관계가 존재합니다. 렌더러가 매우 큰 DOM의 레이아웃을 업데이트해야 하는 경우, 해당 레이아웃을 다시 계산하는 데 필요한 작업 규모가 크게 증가할 수 있습니다.
CSS Containment를 사용하세요. 이것은 CSS의contain속성에 의존하며, 이 속성이 설정된 컨테이너에 대한 레이아웃 작업을 수행하는 지침을 브라우저에 제공합니다. 여기에는 레이아웃 범위를 격리하고, DOM의 특정 루트로 렌더링하는 것까지 포함됩니다. 항상 쉬운 프로세스는 아니지만, 복잡한 레이아웃이 포함된 영역을 격리함으로써 불필요한 레이아웃 및 렌더링 작업을 수행하지 않을 수 있습니다.
결론
웹 페이지의 성능을 개선하는 일은 막대한 양의 가이드가 존재하기 때문에 어려운 일처럼 느껴질 수 있습니다. 하지만 이러한 권장사항에 집중한다면 보다 문제를 명확하게 파악하고, 목적을 가지고 접근할 수 있으며 웹 사이트의 Core Web Vitals를 개선할 수 있을 것입니다.
이 글에서 나열한 권장사항들이 모든 것을 아우르지는 못하지만, 웹의 상황을 신중하게 분석한 결과에 기반하는 만큼, 이러한 지침들이 2023년에 웹 사이트의 Core Web Vitals 성능을 가장 효과적으로 개선할 수 있는 방법들이라고 믿습니다.
만약 이 글에서 제시한 권장사항 이상의 정보를 원한다면, 아래의 최적화 가이드에서 자세한 내용을 참고해 보세요.
새해가 시작되었으니, 모두에게도 더욱 빨라진 웹이 기대되기를 바랍니다! 가장 중요한 부분에서 사용자들에게 더 빠른 사이트를 제공할 수 있기를 희망합니다.
