Economic Times 웹사이트에서 코어 웹 바이탈을 최적화하자 사용자 환경이 크게 개선되었고 전체 웹사이트의 이탈률이 크게 감소했습니다.
인터넷 속도가 나날이 개선됨에 따라 사용자는 웹사이트에서 그 어느 때보다 빠르게 응답하고 작동하기를 기대합니다. Economic Times는 월간 활성 사용자 수가 4,500만 명이 넘습니다. 도메인, AMP 및 비 AMP 페이지에서 코어 웹 바이탈에 맞게 최적화하여 이탈률을 크게 줄이고 독서 환경을 개선할 수 있었습니다.
영향 측정
Google은 최대 콘텐츠 페인트 (LCP) 및 누적 레이아웃 변경 (CLS)에 중점을 두었습니다. 사용자에게 뛰어난 읽기 환경을 제공하는 데 가장 중요한 요소이기 때문입니다. The Economic Times는 아래 설명과 같이 다양한 성능 수정사항을 구현한 후 몇 개월 내에 Chrome 사용자 실험 (CrUX) 보고서 측정항목을 크게 개선할 수 있었습니다.
전체적으로 CLS가 0.25에서 0.09로 250% 개선되었습니다. 전반적으로 LCP가 4.5초에서 2.5초로 80% 개선되었습니다.
또한 2020년 10월부터 2021년 7월까지 '나쁨' 범위의 LCP 값이 33% 감소했습니다.
또한 같은 기간에 '나쁨' 범위의 CLS 값은 65% 감소했으며 '좋음' 범위의 CLS 값은 20% 증가했습니다.
그 결과 이전에는 Core Web Vitals 기준을 충족하지 못했던 The Economic Times에서 이제 전체 출처에서 Core Web Vitals 기준을 통과했으며 전체 이탈률이 43% 감소했습니다.
LCP란 무엇이며 어떻게 개선되었나요?
가장 큰 요소는 사용자 환경을 개선하고 로드 속도를 인식하는 데 가장 관련성이 높은 요소입니다. 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 성능 측정항목은 페이지 로드의 초기 환경만 포착합니다. 반면에 LCP는 사용자에게 표시되는 가장 큰 이미지, 텍스트, 동영상 섹션의 렌더링 시간을 보고합니다.
더 빠른 DNS 제공업체로 전환하고 이미지를 최적화하는 것 외에 LCP 개선을 위해 적용한 몇 가지 기법을 소개합니다.
중요한 요청 우선
모든 최신 브라우저는 동시 요청 수를 제한하므로 개발자는 중요한 콘텐츠를 먼저 로드하는 것에 우선순위를 두어야 합니다. 복잡한 웹페이지를 로드하려면 헤더 요소, CSS, 자바스크립트 리소스, 히어로 이미지, 기사 본문, 댓글, 기타 관련 뉴스, 바닥글, 광고와 같은 애셋을 다운로드해야 합니다. LCP에 필요한 요소를 평가한 후 LCP 개선을 위해 해당 항목을 먼저 로드하도록 환경을 설정했습니다. 또한 초기 페이지 렌더링에 포함되지 않았던 호출도 지연시켰습니다.
텍스트 모양
LCP와 CLS 모두에 영향을 미치는 font-display 속성을 실험했습니다. font-display: auto;를 시도한 후 font-display: swap;로 전환했습니다. 이렇게 하면 처음에는 가장 일치하고 사용 가능한 글꼴로 텍스트를 렌더링한 다음 다운로드가 완료되면 글꼴로 전환됩니다. 그 결과 네트워크 속도와 무관하게 텍스트가 빠르게 렌더링될 수 있었습니다.
압축 개선
Brotli는 Google에서 개발한 Gzip 및 Deflate의 대체 압축 알고리즘입니다. 글꼴과 애셋을 교체하고 서버 압축을 Gzip에서 Brotli로 변경하여 공간을 더 작게 만들었습니다.
- 자바스크립트 파일은 Gzip보다 15% 더 작습니다.
- HTML 파일은 Gzip을 사용할 때보다 18% 더 작습니다.
- CSS 및 글꼴 파일은 Gzip을 사용할 때보다 17% 더 작습니다.
서드 파티 도메인에 사전 연결하기
preconnect는 여전히 소중한 CPU 시간을 차지하고 특히 보안 연결의 경우 다른 중요한 리소스를 지연시킬 수 있으므로 주의해서 사용해야 합니다.
하지만 서드 파티 도메인의 리소스 가져오기가 발생한다고 알려진 경우에는 preconnect을 사용하는 것이 좋습니다. 트래픽이 많은 웹사이트에서 가끔 발생하는 경우 preconnect에서 불필요한 TCP 및 TLS 작업을 트리거할 수 있습니다. 따라서 소셜 미디어, 분석 등의 타사 리소스에 DNS 조회를 미리 수행하는 데 dns-prefetch가 더 적합했습니다.
코드를 청크로 분할
사이트 헤드에서는 비즈니스 로직의 필수적인 부분을 포함하거나 스크롤 없이 볼 수 있는 부분의 페이지 렌더링에 중요한 리소스만 로드했습니다. 또한 코드 분할을 사용하여 코드를 청크로 분할했습니다. 이를 통해 페이지 LCP를 더욱 개선할 수 있었습니다.
캐싱 개선
모든 프런트엔드 경로에 캐시에서 템플릿을 제공하는 Redis 레이어를 추가했습니다. 이렇게 하면 서버에서 계산 시간이 단축되고 각 요청에서 전체 UI가 빌드되므로 후속 요청에서 LCP가 감소합니다.
LCP 목표 및 성과 요약
최적화 프로젝트를 시작하기 전에 팀은 4.5초 (CrUX 보고서 필드 데이터 기준, 사용자의 75번째 백분위수에 대한 LCP 점수)를 벤치마킹했습니다. 최적화 프로젝트 후 소요 시간이 2.5초로 줄었습니다.
CLS란 무엇이며 어떻게 개선되었나요?
웹사이트를 탐색하는 동안 페이지 콘텐츠가 예기치 않게 이동하는 것을 본 적이 있나요? 이 문제의 원인 중 하나는 페이지에서 크기를 알 수 없는 미디어 (이미지, 동영상, 광고 등)가 비동기적으로 로드되기 때문입니다. 미디어 리소스가 로드되는 즉시 페이지의 레이아웃이 변경됩니다.
Economic Times 웹사이트에서 CLS를 개선하기 위해 취한 조치를 살펴보겠습니다.
자리표시자 사용
광고 라이브러리가 페이지 광고를 로드하고 렌더링할 때 레이아웃이 바뀌지 않도록 알려진 크기의 광고 단위 및 미디어 요소에 스타일이 지정된 자리표시자를 사용했습니다. 이렇게 하면 광고 공간을 확보하여 레이아웃 변경을 방지할 수 있습니다.
정의된 컨테이너 측정기준
DOM 요소를 사용할 수 있게 되면 브라우저 엔진이 DOM 요소의 너비와 높이를 계산할 필요가 없도록 모든 이미지와 컨테이너에 대해 명시적인 크기를 지정했습니다. 이를 통해 불필요한 레이아웃 변경과 추가 페인팅 작업을 피할 수 있었습니다.
CLS 목표 및 성과 요약
최적화 프로젝트를 시작하기 전에 팀은 CLS 점수를 0.25로 벤치마킹했습니다. 그 결과 테스트를 90%에서 0.09까지 줄일 수 있었습니다.
최초 입력 반응 시간 (FID)이란 무엇이며 어떻게 개선되었나요?
최초 입력 반응 시간은 사용자 입력에 대한 웹사이트의 응답성을 추적하는 측정항목입니다. 낮은 FID 점수의 주요 원인은 브라우저의 기본 스레드를 계속 사용하는 과도한 자바스크립트 작업으로 인해 사용자 상호작용이 지연될 수 있기 때문입니다. 여러 가지 방법으로 FID를 개선했습니다.
긴 JavaScript 작업 분할
장기 태스크는 50밀리초 이상의 태스크입니다. 장기 작업은 브라우저의 기본 스레드를 차지하여 사용자 입력에 응답하지 못하게 합니다. 사용자 요청에 따라 가능한 경우 장기 실행 작업을 더 작은 작업으로 나누어 JavaScript 팽창을 줄이는 데 도움이 되었습니다.
사용하지 않는 JavaScript 연기
Google에서는 페이지의 응답성을 높이기 위해 분석과 같은 서드 파티 스크립트보다 페이지 콘텐츠의 우선순위를 지정했습니다. 그러나 일부 라이브러리에는 사용자 여정을 정확하게 추적하기 위해 <head> 문서에 로드해야 하므로 특정한 제한사항이 있습니다.
폴리필 줄이기
브라우저가 최신 API를 지원하고 Internet Explorer와 같은 기존 브라우저를 사용하는 사용자가 줄었기 때문에 특정 폴리필 및 라이브러리에 대한 의존도를 줄였습니다.
광고 지연 로드
스크롤해야 볼 수 있는 부분의 광고를 지연 로드하여 기본 스레드 차단 시간을 줄이고 FID를 개선했습니다.
FID 목표 및 성과 요약
일상적인 실험을 통해 오늘 FID를 200ms에서 50ms 미만으로 줄일 수 있었습니다.
회귀 방지
Economics Times는 페이지 성능 저하를 방지하기 위해 프로덕션 환경에 자동화된 성능 검사를 도입할 계획입니다. Lighthouse-CI를 평가하여 프로덕션 브랜치에서 회귀를 방지할 수 있는 실험실 테스트를 자동화할 계획입니다.