Chrome DevRel팀에서 2023년 코어 웹 바이탈 성능을 개선할 수 있는 가장 효과적인 방법이라고 생각하는 권장사항 모음입니다.
Google에서는 수년 동안 웹 개발자에게 성능 개선 방법에 관한 많은 권장사항을 제공해 왔습니다.
각 권장사항을 개별적으로 적용하면 많은 사이트의 실적이 개선될 수 있지만, 전체 권장사항을 따르는 것은 매우 어려우며, 현실적으로는 한 사람이나 사이트가 모든 권장사항을 따를 수는 없습니다.
웹 성능을 높이는 것이 주 업무가 아니라면 어떤 추천이 사이트에 가장 큰 긍정적인 영향을 미칠지 분명하지 않을 것입니다. 예를 들어 중요한 CSS를 구현하면 로드 성능을 개선할 수 있다는 이야기를 읽고 이미지를 최적화하는 것이 중요하다는 말을 들었을 수 있습니다. 하지만 두 가지 일을 모두 할 시간이 없다면 어떤 것을 선택해야 할까요?
Chrome팀에서는 작년 한 해 동안 사용자의 성능을 개선하기 위해 개발자에게 제공할 수 있는 가장 중요한 권장사항은라는 질문에 답하기 위해 노력해 왔습니다.
이 질문에 적절히 답변하기 위해서는 주어진 권장 사항의 기술적 이점뿐만 아니라 개발자가 실제로 이러한 권장 사항을 채택할 수 있는 가능성에 영향을 미치는 인적 및 조직적 요인도 고려해야 합니다. 다시 말해 어떤 권장사항은 이론상 큰 영향을 미칠 수 있지만 실제로 이를 구현할 시간이나 리소스가 있는 사이트는 거의 없습니다. 마찬가지로 일부 권장사항이 중요하지만 대부분의 웹사이트에서는 이미 이러한 권장사항을 따르고 있습니다.
간단히 말해, 웹 성능 개선을 위한 권장사항 목록에서 다음과 같은 사항에 초점을 맞추고자 했습니다.
- 실제로 가장 큰 영향을 미칠 것으로 예상되는 추천
- 대부분의 사이트와 관련성이 높고 적용 가능한 추천
- 대부분의 개발자가 현실적으로 구현할 수 있는 권장사항
지난 한 해 동안 Google은 많은 시간을 들여 실적 개선을 위한 추천사항을 점검하고 위의 세 가지 기준에 따라 각 추천을 정성적 및 정량적으로 평가했습니다.
이 게시물에서는 각 코어 웹 바이탈 측정항목의 성능을 개선하기 위한 주요 권장사항을 간략히 설명합니다. 웹 성능을 처음 접하거나 비용 대비 효과가 가장 큰 요소를 찾으려는 경우 이 추천이 가장 적합합니다.
최대 콘텐츠 렌더링 시간(LCP)
첫 번째 권장사항은 로드 성능을 측정한 최대 콘텐츠 렌더링 시간 (LCP)입니다. 세 가지 코어 웹 바이탈 측정항목 중 LCP는 오늘날 웹상의 모든 사이트 중 약 절반만 권장 기준점을 충족하는 가장 많은 사이트에서 문제가 되는 측정항목입니다. 지금부터 시작하겠습니다.
HTML 소스에서 LCP 리소스를 검색할 수 있는지 확인하세요.
HTTP Archive의 2022 Web Almanac에 따르면 모바일 페이지의 72%가 LCP 요소로 이미지를 사용합니다. 이는 대부분의 사이트에서 LCP를 최적화하려면 이미지를 빠르게 로드할 수 있어야 합니다.
이미지를 로드하는 데 걸리는 시간이 이러한 문제 중 하나일 뿐이라는 점은 많은 개발자들에게는 분명하지 않을 수 있습니다. 또 다른 중요한 부분은 이미지가 로드되기 전 시간입니다. HTTP 보관 파일은 실제로 많은 사이트가 중단되는 시점임을 시사합니다.
실제로 LCP 요소가 이미지인 페이지 중 39%에는 HTML 문서 소스에서 검색할 수 없는 소스 URL이 있었습니다. 즉, 표준 HTML 속성 (예: <img src="..."> 또는 <link rel="preload" href="...">)에서 이러한 URL을 찾을 수 없었습니다. 따라서 브라우저가 빠르게 URL을 찾아 즉시 로드할 수 있습니다.
이미지가 로드되기 전에 CSS 또는 JavaScript 파일이 완전히 다운로드, 파싱, 처리될 때까지 기다려야 한다면 이미 너무 늦었을 수 있습니다.
일반적으로 LCP 요소가 이미지인 경우 이미지의 URL을 항상 HTML 소스에서 검색할 수 있어야 합니다. 이를 위한 몇 가지 팁은 다음과 같습니다.
src또는srcset속성이 지정된<img>요소를 사용하여 이미지를 로드합니다. 렌더링하기 위해 JavaScript가 필요한data-src와 같은 비표준 속성은 항상 느릴 수 있으므로 사용하지 마세요. 페이지의 9%가data-src뒤의 LCP 이미지를 가립니다.SSR은 이미지를 포함한 전체 페이지 마크업이 HTML 소스에 있다고 암시하기 때문에 클라이언트 측 렌더링(CSR)보다 서버 측 렌더링(SSR)을 선호합니다. 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>에 <script> 태그가 12개 포함되어 있으면 이미지 리소스가 로드되기까지 다소 시간이 걸릴 수 있습니다.
이 문제를 해결하는 가장 쉬운 방법은 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 리소스가 조기에 높은 우선순위로 로드되도록 다음 권장사항을 따라야 합니다.
fetchpriority="high"를 LCP 이미지의<img>태그에 추가합니다. LCP 리소스가<link rel="preload">태그를 통해 로드되는 경우에도fetchpriority="high"를 설정할 수 있으므로 걱정하지 마세요.- LCP 이미지의
<img>태그에loading="lazy"를 설정하면 안 됩니다. 이렇게 하면 이미지의 우선순위가 낮아지고 로드가 지연될 수 있습니다. - 가능하면 중요하지 않은 리소스를 연기합니다. iframe을 문서의 끝으로 옮기거나 이미지 또는 iframe에 네이티브 지연 로드를 사용하거나 자바스크립트를 통해 비동기식으로 로드하는 방법을 사용할 수 있습니다.
CDN을 사용하여 문서 및 리소스 TTFB 최적화
이전의 두 권장사항은 LCP 리소스를 조기에 발견하고 우선순위를 지정하여 즉시 로드를 시작하는 데 중점을 두었습니다. 이 퍼즐의 마지막 조각은 초기 문서 응답도 가능한 한 빨리 도착하도록 하는 것입니다.
브라우저는 초기 HTML 문서 응답의 첫 번째 바이트를 수신할 때까지 하위 리소스의 로드를 시작할 수 없으며, 로드가 빠를수록 다른 모든 작업도 더 빨리 시작될 수 있습니다.
이 시간을 TTFB (Time to First Byte)라고 하며, 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에 영향을 주는 유일한 요소는 이미지가 아니라는 점도 기억해야 합니다. 제3자 광고 또는 삽입된 동영상 등 일반적으로 페이지가 처음 렌더링된 후 로드되는 기타 콘텐츠로 인해 레이아웃이 변경될 수 있습니다. 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는 일반적으로 다른 코어 웹 바이탈도 개선할 것입니다. 이는 페이지 탐색을 크게 개선하는 데 사용할 수 있는 여러 인스턴트 탐색 기능 중 하나입니다.
레이아웃을 유도하는 CSS 속성을 사용하는 애니메이션/전환 피하기
레이아웃 변경의 또 다른 일반적인 원인은 요소에 애니메이션이 적용되는 경우입니다. 예를 들어 상단 또는 하단에서 슬라이드되는 쿠키 배너 또는 기타 알림 배너가 종종 CLS의 원인입니다. 이러한 배너가 다른 콘텐츠를 방해할 때 특히 문제가 되지만, 그렇지 않은 경우에도 애니메이션을 적용하면 CLS에 영향을 미칠 수 있습니다.
HTTP 보관 파일 데이터가 애니메이션을 레이아웃 변경과 확실하게 연결할 수는 없지만, 데이터에 따르면 레이아웃에 영향을 미칠 수 있는 CSS 속성에 애니메이션을 적용하는 페이지가 전체 페이지보다 CLS가 '양호'할 가능성이 15% 낮습니다. 일부 속성은 다른 속성보다 나쁜 CLS와 연결됩니다. 예를 들어 margin 또는 border 너비에 애니메이션을 적용하는 페이지의 CLS는 전반적으로 페이지가 저조한 것으로 평가되는 비율의 거의 두 배에 달합니다.
이는 당연한 결과일 수 있습니다. 레이아웃을 유도하는 모든 CSS 속성을 전환하거나 애니메이션 처리할 때마다 레이아웃 변경이 발생하고, 이러한 레이아웃 변경이 사용자 상호작용의 500밀리초 이내에 발생하지 않으면 CLS에 영향을 주기 때문입니다.
일부 개발자는 놀라운 점은 요소가 일반적인 문서 흐름을 벗어나더라도 이러한 내용이 사실이라는 것입니다. 예를 들어 top 또는 left에 애니메이션을 적용하는 절대 위치로 배치된 요소는 다른 콘텐츠를 밀어내지 않더라도 레이아웃이 변경됩니다. 그러나 top 또는 left에 애니메이션을 적용하는 대신 transform:translateX() 또는 transform:translateY()에 애니메이션을 적용하면 브라우저가 페이지 레이아웃을 업데이트하지 않으므로 레이아웃 변경이 발생하지 않습니다.
브라우저의 컴포지터 스레드에서 업데이트할 수 있는 CSS 속성의 애니메이션을 선호하는 것은 작업을 GPU로 그리고 기본 스레드 외부로 이동하기 때문에 오랫동안 성능 권장사항이었습니다. 이는 일반적인 성능 권장사항일 뿐만 아니라 CLS를 개선하는 데도 도움이 됩니다.
일반적으로 사용자가 탭하거나 키를 누를 때 (hover 아님)하는 경우 외에는 브라우저에서 페이지 레이아웃을 업데이트해야 하는 CSS 속성에 애니메이션을 적용하거나 전환하지 마세요. 또한 가능한 경우 CSS transform 속성을 사용하여 전환과 애니메이션을 선호합니다.
Lighthouse 감사에서 합성되지 않은 애니메이션 피하기는 속도가 느려질 수 있는 CSS 속성에 애니메이션을 적용할 때 경고를 표시합니다.
최초 입력 반응 시간(FID)
마지막 권장사항은 사용자 상호작용에 대한 페이지의 응답성을 측정한 최초 입력 반응 시간 (FID)입니다. 현재 대부분의 웹 사이트가 FID에서 매우 높은 점수를 보이고 있지만, 과거에 FID 측정항목의 단점이 문서화되어 있었으며, 사용자 상호작용에 대한 사이트의 전반적인 응답성을 개선할 수 있는 기회는 여전히 많습니다.
새로운 INP (다음 페인트에 대한 상호작용) 측정항목은 FID의 후속 측정항목이며, 아래의 모든 권장사항은 FID와 INP 모두에 동일하게 적용됩니다. 특히 모바일에서 FID보다 INP의 실적이 더 나쁘다는 점을 감안하여, 개발자는 FID가 '양호'하더라도 이러한 응답성 권장사항을 신중하게 고려하는 것이 좋습니다.
장기 작업 방지 또는 중단
할 일 목록은 브라우저가 수행하는 모든 개별적인 작업입니다. 스크립트 렌더링, 레이아웃, 파싱, 컴파일, 실행이 포함됩니다. 작업이 장기 작업(50밀리초 이상)이 되면 기본 스레드가 사용자 입력에 빠르게 응답할 수 없게 됩니다.
웹 연감에 따르면 개발자가 장기 작업을 피하거나 중단하기 위해 더 많은 조치를 취할 수 있음을 시사하는 충분한 증거가 있습니다. 장기 작업을 분할하는 것은 이 도움말의 다른 권장사항만큼 적은 노력은 아니지만 이 도움말에서 제공하지 않는 다른 기법보다는 덜 수월합니다.
항상 JavaScript에서 가능한 한 적은 작업을 하도록 노력해야 하지만, 긴 작업을 더 작은 작업으로 나누면 기본 스레드에 상당한 도움을 줄 수 있습니다. 자주 기본 스레드에 생성하여 렌더링 업데이트와 다른 사용자 상호작용이 더 빠르게 발생할 수 있도록 하면 됩니다.
또 다른 옵션은 isInputPending 및 Scheduler API와 같은 API를 사용하는 것입니다. isInputPending는 사용자 입력이 대기 중인지 여부를 나타내는 불리언 값을 반환하는 함수입니다. true가 반환되면 대기 중인 사용자 입력을 처리할 수 있도록 기본 스레드에 양보할 수 있습니다.
Scheduler API는 진행 중인 작업이 사용자에게 보이는지 아니면 백그라운드에 있는지 여부를 고려하는 우선순위 시스템을 기반으로 작업을 예약할 수 있는 고급 접근 방식입니다.
장기 작업을 나누면 브라우저가 상호작용 및 이에 따른 렌더링 업데이트 처리와 같이 사용자가 볼 수 있는 중요한 작업에 더 많은 기회를 제공할 수 있습니다.
불필요한 자바스크립트 피하기
웹사이트는 그 어느 때보다 많은 JavaScript를 제공하고 있으며 이러한 추세는 머지않아 변하지 않을 것이라는 점에는 의심의 여지가 없습니다. 너무 많은 JavaScript를 제공하면 작업이 기본 스레드의 주의를 끌기 위해 경쟁하는 환경이 만들어집니다. 이는 특히 중요한 시작 기간에 웹사이트의 응답성에 영향을 미칠 수 있습니다.
하지만 해결할 수 없는 문제는 아닙니다. 다음과 같은 몇 가지 옵션이 있습니다.
- Chrome DevTools의 커버리지 도구를 사용하여 웹사이트 리소스에서 사용되지 않는 코드를 찾습니다. 시작 시 필요한 리소스의 크기를 줄이면 웹사이트에서 코드를 파싱하고 컴파일하는 데 들이는 시간을 줄여 초기 사용자 환경이 더 원활해집니다.
- 적용 범위 도구를 사용하여 찾은 미사용 코드가 시작 중에 실행되지 않았지만 향후 일부 기능에 여전히 필요하기 때문에 '사용되지 않음'으로 표시되는 경우가 있습니다. 이 코드는 코드 분할을 통해 별도의 번들로 이동할 수 있습니다.
- 태그 관리자를 사용하는 경우 아직 사용 중이거나 태그가 최적화되어 있는지 정기적으로 확인해야 합니다. 사용하지 않는 코드가 있는 이전 태그를 삭제하면 태그 관리자의 JavaScript를 더 작고 효율적으로 만들 수 있습니다.
대규모 렌더링 업데이트 피하기
웹사이트의 응답성에 영향을 줄 수 있는 것이 JavaScript만 있는 것은 아닙니다. 렌더링은 그 자체로 비용이 많이 드는 작업 중 하나이며, 대규모 렌더링 업데이트가 발생하면 웹사이트의 사용자 입력에 응답하는 데 방해가 될 수 있습니다.
렌더링 작업을 최적화하는 것은 간단한 프로세스가 아니며, 달성하려는 목표에 따라 달라질 수 있습니다. 그렇더라도 렌더링 업데이트가 합리적이고 장기 작업으로 분산되지 않도록 할 수 있는 몇 가지 방법이 있습니다.
- 비시각적 작업에는
requestAnimationFrame()를 사용하지 않습니다.requestAnimationFrame()호출은 이벤트 루프의 렌더링 단계에서 처리되며, 이 단계에서 너무 많은 작업이 실행되면 렌더링 업데이트가 지연될 수 있습니다.requestAnimationFrame()를 사용하여 실행하는 모든 작업은 렌더링 업데이트와 관련된 작업에만 예약되어야 합니다. - DOM 크기를 작게 유지합니다. DOM 크기와 레이아웃 작업의 강도는 상관관계가 있습니다. 렌더러가 매우 큰 DOM의 레이아웃을 업데이트해야 하는 경우 레이아웃을 다시 계산하는 데 필요한 작업이 크게 증가할 수 있습니다.
- CSS 포함을 사용합니다. CSS 포함은 CSS
contain속성을 사용합니다. 이 속성은contain속성이 설정된 컨테이너에서 레이아웃 작업을 실행하는 방법에 관한 안내를 브라우저에 제공합니다. 여기에는 레이아웃 범위를 격리하고 DOM의 특정 루트로 렌더링하는 작업도 포함됩니다. 프로세스가 항상 쉬운 것은 아니지만 복잡한 레이아웃이 포함된 영역을 격리하면 필요하지 않은 영역에서 레이아웃 및 렌더링 작업을 실행하지 않을 수 있습니다.
결론
특히 웹 전반에 걸쳐 고려해야 할 가이드라인이 산재해 있다는 점을 감안할 때, 페이지 성능을 개선하는 것은 버겁게 느껴질 수 있습니다. 그러나 이러한 권장사항에 집중하면 초점과 목적을 고려하여 문제에 접근하여 웹사이트의 코어 웹 바이탈을 발전시킬 수 있습니다.
여기에 나와 있는 권장사항이 완전하지는 않지만, Google은 웹 상태에 대한 신중한 분석을 바탕으로 이러한 권장사항이 사이트의 코어 웹 바이탈 성능을 2023년에 개선하는 데 가장 효과적인 방법이라고 생각합니다.
여기에 나와 있는 권장사항 외에 더 많은 정보를 얻으려면 다음 최적화 가이드를 확인하세요.
새해를 맞이하여 웹이 더욱 빨라지는 새해가 밝았습니다. 사용자에게 가장 중요한 모든 방식으로 사용자의 사이트 속도를 개선해 보세요.
사진: 데빈 에이버리