최근 웹를 쉽게 구성할 수 있게 돕는 라이브러리 React, Vue, Svelte, Lit, Solid
웹 프레임워크 이면서 SSR을 제공하는 Nextjs, Nuxtjs, Remix, SvelteKit ... 등
Nextjs에서는 서버 사이드 렌더링과는 별도의 개념인 Server Component, Client Component를 구분하는 등 다양한 변화와 새로운 방향을 제시하고 있습니다.
이러한 빠르고, 수 많은 변화들을 보면서
당장 웹을 더 효율적으로 만드는 방법은 무엇일까 고민하게 되었습니다.
웹을 방문했을 때 더 빠르게 렌더링하여 사용자들에게 보여지고 싶고
코드를 더 간결하게 작성하여 사용자의 상호작용에 효율적으로 반응하고 싶었습니다.
웹 프레임워크를 도입하거나 라이브러리를 변경하기엔 작업 공수가 크니 우선적으로 할 수 있는 것을 알아보는 도중
'CWV'이라는 개념을 알게 되었습니다.
CWV
코어 웹 바이탈은 웹 사이트가 검색 엔진 결과에 표시되는 위치
검색 시 첫번째로 나타날지 두번째로 나타날지 또는 그 아래 몇번째에 표시되는지에 영향을 미치는 세 가지 웹 성능 측정값을 뜻합니다.
SEO 순위를 높이기 위한 전략의 일환으로 Google이 2020년 11월에 발표 했습니다. https://developers.google.com/search/blog/2020/11/timing-for-page-experience?hl=ko
Google 검색에 페이지 환경을 도입할 시간 | Google 검색 센터 블로그 | Google for Developers
developers.google.com
2021년 중반부터 순위 알고리즘의 일부가 될 것이라고 발표했고, 현재는 SEO 순위를 결정하는 중요한 요소로 자리잡았습니다. CWV외에도 HTTPS 적용여부, 모바일 친화성, 방해가 되는 광고 유무 등의 지표로 추가적으로 고려하여 순위를 산정하고 있다고 밝혀졌습니다.
CWV의 세가지 측정값으로는
1. 최대 콘텐츠 렌더링 시간 (LCP): 웹 페이지의 가장 큰 부분을 로드하는 데 걸리는 시간을 측정한 것으로 이미지 또는 텍스트 블록 및 JS,CSS 등을 로드하면서 걸린 시간입니다. 구글 가이드라인에서는 2.5초 미만인 경우를 LCP 측정값 '양호'로 분류합니다. 첫 페이지 로드가 3초를 지날 때 사용자의 이탈률이 급속도로 올라간다는 연구도 있고, 스켈레톤 UI가 생겨난 이유를 이를 통해 이해하게 됐습니다.
2. 최초 입력 반응 시간 (FID): 사용자가 웹 페이지와 처음으로 상호작용을 했을 때 웹 페이지가 응답할 때 까지의 시간을 측정한 값입니다. 즉, 사용자가 화면을 처음 클릭하고 무언가 실행할 수 있는 속도를 정량화 합니다. 구글 가이드라인에 따르면 100밀리초 이하를 '양호'로 분류합니다. 웹 크롤러 봇이 FID를 측정한다는 사실에 놀랐습니다.
3. 레이아웃 변경 횟수 (CLS): 시각적 안정성을 측정합니다. 즉, 웹 페이지가 로드될 때 레이아웃에서 변화를 측정합니다. 텍스트 위에 버튼이나 이미지가 갑자기 나타나면서 텍스트가 밀리는 것과 같은 상황을 뜻합니다. 이동 링크가 보여 클릭하려는 순간 이미지가 로드되면서 링크는 밀리고 이미지가 클릭되는 상황을 꽤 경험했습니다. 단순히 인터넷 문제 일 수 있지만 이는 SEO를 측정하는 중요한 지표입니다. 구글 가이드라인에서는 0.1 이하를 '양호'로 분류합니다. CLS 측정 방법 또한 제공합니다.
CLS 측정 방법은
영향 비율 * 거리 비율 = CLS
- 영향 비율은 레이아웃 이동이 발생할 때 변경되는 화면의 백분율이며, 거리 비율은 요소가 화면에서 얼마나 멀리 이동하는지 측정하며, 화면의 백분율로도 표시됩니다.
400픽셀 높이의 화면이라고 가정했을 때
새 요소가 로드될 때 200픽셀이 이동하는 경우 영향 비율은 200/400, 즉 50%입니다. 새 요소가 다른 요소를 50픽셀 아래로 이동한 경우 거리 비율은 50/400, 즉 12.5%입니다.
CLS는 0.5 * 0.125 = 0.0625 입니다.
웹 바이탈 측정 방법
개인적으로 CWV를 계산하기엔 쉽지 않기에 구글에서는 여러가지 도구를 제공합니다.
- Google Search Console : 웹 사이트의 검색 트래픽과 실적을 측정합니다. 사이트의 소유권을 확인한 사이트만 사용 가능합니다.
- Google Lighthouse : 페이지 성능을 개선할 수 있는 구체적인 기회를 제공하는 실험실 도구입니다. 개발자는 페이지 로드 이후의 성능 테스트를 위한 상호작용 흐름을 스크립팅 할 수 있습니다.
- Google UX 보고서(CrUX) : 웹을 탐색할 때 CWV 측정항목을 표시하는 진단 도구입니다. CWV 성능 문제를 식별하는 데 도움이 되는 디버깅 정보를 제공합니다.
- Google PageSpeed Insights : CrUX와 Lighthouse의 기능을 결합하여 CWV 및 기타 성능에 대한 현장 및 실험실 데이터를 모두 제공합니다. 페이지 소유 여부와 관계없이 웹 사이트의 성능을 확인할 수 있습니다.
CWV 개선하는 방법
LCP를 개선하는 방법
1. 리소스 로드 지연 제거
- 실제로 브라우저가 리소스 로드를 시작하기 전에 항상 어느 정도의 지연이 발생합니다. LCP 측정시간을 단축시키기 위해 LCP 리소스가 가능한 빨리 로드할 수 있도록 해야 합니다.
LCP 리소스가 첫 번째 리소스보다 늦게 로드되기 시작하면 개선할 수 있습니다.
LCP 리소스 로드 속도에 영향을 주는 요인에는 두가지가 있습니다.
- 리소스가 검색되는 시점
HTML 문서를 스캔해야 알맞는 LCP 리소스를 검색할 수 있습니다.
'<link rel="preload"> 또는 Link 헤더를 통해 LCP 리소스를 미리 로드 할 수 있습니다.
그러나 자바스크립트를 통해 페이지에 동적으로 추가되는 경우 LCP 리소스를 찾을 수 없습니다.
SPA 구조로 이루어진 웹사이트의 경우 자바스크립트를 통해 화면을 구성하게 되므로 이 경우 낮은 LCP를 가질 수 밖에 없습니다.
SSR 또는 서버 컴포넌트를 구성하는 방법으로 최적화를 진행 할 수 있습니다.
- 리소스에 지정된 우선순위
LCP 리소스를 HTML에서 스캔하더라도 첫 번째 리소스부터 로드가 시작되지 않을 수 있습니다.
예를 들어 <img> 태그에 loading="lazy"를 설정하면 LCP 이미지를 지연시킬 수 있습니다.
2. 요소 렌더링 지연 제거
- LCP 리소스 로드 후 즉시 렌더링 될 수 있도록 해야 합니다.
- 아직 로드중인 <head>의 스타일시트 또는 동기 스크립트로 인해 전체 페이지의 렌더링이 차단됩니다.
- 또는, 자바스크립트 코드에 의해 DOM에 추가되기 전까지 렌더링이 지연될 수 있습니다.
사용하지 않는 CSS는 삭제 또는 연기하거나 CSS 자체를 축소 및 압축하면 시간을 단축시킬 수 있습니다.
3. 리소스 로드 시간 단축
- Imagemin등을 사용해 이미지를 압축하여 크기를 줄이거나 픽셀에 비해 과도하게 큰 이미지를 사용하지 않고 적절한 픽셀을 통해 이미지 크기를 줄이고
- 웹 글꼴 크기를 줄이는 것으로 리소스 크기를 줄일 수 있습니다.
- 또한, CDN을 통해 콘텐츠를 캐싱하여 더욱 빠르고 더욱 가까운 곳에서 리소스를 전송할 수 있어 사용자에게 더 빨리 도달하게 합니다.
4. 첫 번째 바이트까지의 시간 단축
- HTML을 가능한 빨리 제공해야 합니다.
- 여러 리다이렉션을 거치면 최종 URL에 도달하기까지 더욱 많은 시간이 걸립니다.
- 사람들이 많이 찾지 않는 웹 사이트는 근처 네트워크 대역에 캐싱된 페이지가 존재하지 않으면 더욱 많은 시간이 걸립니다.
FID를 개선하는 방법
1. 자바스크립트 크기 줄이기
- 코드가 많은 웹 페이지는 브라우저에서 코드를 실행할 때 입력 지연이 발생 할 수 있습니다. SWC와 같은 번들러에서 함수명 및 변수명을 최소화하고 화이트 스페이스를 제거하여 파일 크기를 줄이는데 도움을 줍니다. 좋은 번들러를 찾고 활용해보세요.
2. 상호작용에 맞게 페이지 최적화하기
- 정적인 웹 페이지는 자바스크립트를 실행하는 동적 웹 페이지보다 빠릅니다. 초기 화면만 정적으로 구성하는 방법도 존재하지만 현실적으로 알맞지 않다고 생각을 합니다. SSR을 활용해 메인페이지를 최적화하는것이 현명하다 생각됩니다.
- 초기에 모든 스크립트를 불러오지 않는 것도 좋은 방법입니다. 서드파티 스크립트를 사용하는 경우 메인페이지에서 모든 스크립트를 실행하는 것이 아닌 동작 실행 직전에 불러오는 것이 좋습니다.
CLS를 개선하는 방법
1. 임베디드 콘텐츠를 위한 공간을 확보
- 광고와 같이 웹 사이트의 존속을 위해 어쩔 수 없는 요소들이 몇 있을 수 있습니다. 이 경우 해당 요소를 고려하여 사전에 크기를 잡아두는 등 최적화를 진행해야합니다.
2. 이미지 또는 비디오 크기를 미리 확보하기
- CDN을 통해 콘텐츠를 불러오는 경우, 동적으로 상호작용에 의해 콘텐츠를 가져오는 경우 콘텐츠 다운로드를 통해 레이아웃이 변경 될 수 있습니다. 레이아웃 변경으로 사용자가 의도하지 않은 상호작용을 방지하기 위해 특정 위험이 있는 구간에서는 콘텐츠를 위한 자리를 미리 잡거나 스켈레톤 UI를 활용해야 합니다.
단순히 HTML 태그를 만들고 CSS를 이쁘게 만들고 JS코드를 통해 동적으로 만드는 것 외에도
메인화면을 위해 lazy-load를 스크롤 아래에서부터 사용하여 LCD 리소스 로드에 최적화를 진행하고
서드파티 스크립트, 메인 스크립트, CSS, 이미지 및 비디오, 폰트와 같은 리소스를 불러올 때 async, defer와 같이 비동기로 불러와야하고
이미지를 압축하고 CDN을 사용해 캐싱 및 더 가까운 곳에서 다운을 할 수 있도록 하는 등
세부적으로 신경써야 하는 부분이 많고 이러한 디테일로 인해 이탈률이 적고 반응이 좋은 웹사이트를 만들고
SEO 순위가 높아짐으로 다른 사이트와 차별점을 만들 수 있다는 것을 염두하면서 서비스를 만들 수 있게 되었습니다.
참고
https://web.dev/articles/vitals?hl=ko
웹 바이탈 | Articles | web.dev
건전한 사이트를 위한 필수 측정항목
web.dev
https://www.cloudflare.com/ko-kr/learning/performance/what-are-core-web-vitals/
https://web.dev/articles/optimize-lcp?hl=ko
최대 콘텐츠 렌더링 시간 최적화 | Articles | web.dev
LCP 분석 및 개선이 필요한 주요 영역을 파악하는 방법에 관한 단계별 안내
web.dev
'FrontEnd > 브라우저' 카테고리의 다른 글
| 브라우저 렌더링 과정 (0) | 2023.01.31 |
|---|
댓글