웹페이지 성능 최적화(Feat. FCP/LCP)

지금의 프론트엔드 개발자들은 페이지 로딩시간의 중요성을 SEO 때문에라도 많이 알고 있을 것이다. 그러나 이 페이지 로딩시간을 강조하게 된 지는 그리 오래 되지 않았다. 페이지 로딩시간 단축을 최초로 주장한 주요 기업 중 하나는 바로 월마트였다.

2012년 2월, 월마트에서는 페이지 로딩 속도와 사용자의 구매 전환율(방문에서 실제 구매로 이어지는 비율)을 연구했다. 그러자 놀라운 결과가 나왔다.

출처: https://fabric.inc/blog/commerce/ecommerce-site-speed

로딩 속도가 1초 감소할 때마다 전환률이 2%, 100ms당 수익이 최대 1%씩 증가했다. 즉 페이지 속도 = 매출로 직결된다는 결정적인 증거가 되는 셈이다.

또한 구글에서 인간의 뇌와 신경망 모델을 학습시킨 시스템으로 분석해 본 결과, 페이지 로딩 시간이 1초만 늘어나도 사용자 이탈률이 크게 증가하는 것을 알 수 있다. 특히 3초까지는 어느정도 봐주는 사람들이 있으나… 5초부턴 가차없이 떠나버리는 경향이 강하다.

출처: https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

즉 프론트엔드 개발자에게 있어 최적화로 로딩속도를 줄이는건 최우선 과제라고 해도 과언이 아닐 것이다.

그러나 인터넷이 점점 발달함에 따라, 웹페이지에서 수많은 양의 정보와 이미지를 담고 있는 일도 흔해졌다. 근데 이 수많은 양의 정보를 어떻게 빨리 불러오죠…?

온라인 쇼핑몰을 예를 들면 거의 300장이 넘는 이미지를 갖고 있을텐데, 현실적으로 이를 3초만에 안정적으로 불러오는건 불가능할 것이다(아마도..?)

그치만 꼼수는 써볼 수 있다.

손님이 주문하고 음식이 20분 후에 나온다고 쳐보자. 20분 동안 물과 밑반찬 등 이것저것 꾸준히 나오다가 마지막에 음식이 나오면, 아무것도 없이 무작정 20분 기다린 손님보다 오래 기다렸다는 생각을 상대적으로 덜 하게 될 것이다.

그래서 Google에서는 사용자 경험에 기반하여 웹 성능 최적화의 여러가지 지표를 만들었다. 종류가 정말 많지만, 그 중 대표적으로 5가지를 꼽아볼 수 있다(사실 대표로 꼽는것도 사람마다 다 말이 달라서 그냥 참고용으로 보면 된다)

• LCP(Largest Contentful Paint)
• FID(First Input Delay)
• CLS(Cumulative Layout Shift)
• FCP(First Contentful Paint)
• TTFB(Time To First Byte)

그 중 가장 널리 알려진 지표인 FCP, LCP에 대해 중점적으로 다뤄보고자 한다.

FCP(First Contentful Paint)

FCP는 페이지에 접속한 순간부터 ‘뭐라도' 뜨기 시작한 순간까지의 시간을 의미한다. 글, 이미지, 아이콘 등 상관없고, 첫 컨텐츠가 뜨기만 하면 되는 것이다.

FCP는 주로 1.8초 이내를 권장한다고 되어있다. FCP, LCP와 같은 Paint 지표는 결국 렌더링 속도이기 때문에, 이에 영향을 주는 요소는 렌더링 속도에 영향을 주는 요소와 일맥상통한다.

영향을 주는 요소와 각 개선점을 정리해보자면 다음과 같다.

서버 응답 느림 (TTFB↑)

어쩌면 가장 당연한 것이지만, 서버 응답속도가 느리면 렌더링 속도가 느릴 수 밖에 없다. CDN이나 캐싱 등을 활용하여 응답속도를 개선하는 방안을 구색해보면 좋을 것이다. 또한 리소스의 크기도 응답시간에 영향을 주기 때문에, 이미지나 폰트 등 용량이 큰 것들은 깨지지 않는 선에서 적당히 압축해주는 것이 좋다.

렌더링 차단 리소스(CSS, JS)가 많음

즉 CSS와 JS에서의 파싱하느라 렌더링이 느려지므로, 최소화한의 css와 js만 인라인으로 적용하고 나머지는 비동기적으로 로드하는 것이 좋다.

예시)

<!-- 필수 css inline 적용 -->
<style>/* above-the-fold css */</style>

<!-- 중요하지 않은 css는 비동기 호출-->
<link rel="stylesheet" href="/styles.css" media="print" onload="this.media='all'">

HTML/CSS/JS 초기 로딩 지연

Html 내부에 DOM이 복잡하고 크다면 이를 파싱해서 DOM Tree를 만드는 데에도 오랜 시간이 걸린다. 이를 방지하기 위해서는 DOM이 필요 이상으로 많고 복잡한 곳은 정리하는 것이 좋다.

또한 CSR인 경우에도 클라이언트가 JS를 실행해야 렌더링 되기 때문에 상대적으로 FCP가 높게 측정된다.

LCP(Largest Contentful Paint)

LCP는 말 그대로 가장 큰 요소를 그리기까지의 시간을 의미한다. 정확히 말하자면 페이지가 처음 렌더링한 시점으로부터 뷰포트(현재 노출되는 화면) 내부에서 가장 큰 이미지나 텍스트를 렌더링하는데 걸리는 시간이다.

그리고 큰 이미지와 텍스트는 다음과 같이 정의되어 있다.

• <img>
• <svg> 내부의 <image>
• poster 속성을 사용하는 <video>
• url()을 통해 불러온 배경 이미지가 있는 요소
• 인라인 텍스트를 담고 있는 블록 레벨 요소(<h1>, <p>, <div>등)

이게..최적화랑..뭔상관이죠..?

예시를 들자면 아무리 밑반찬이 많이 나와도 메인메뉴가 나오지 않으면 손님은 다 나왔다는 기분이 들지 않을 것이다. 마찬가지로 뷰포트에서 가장 큰 요소가 렌더링되어야만 사용자는 비로소 페이지 로딩이 다 완료되었다고 느낄 것이다. 따라서 페이지가 사용자에게 정보를 전달하는 속도를 정확하게 판별하기 위한 요소중 하나가 바로 LCP라고 할 수 있다.

Web.dev에 따르면 LCP는 2.5초 이하인 것이 좋다고 권장하고 있다.

말로만 들으면 감이 잘 오지 않으니, 예시를 위해 아래 사진을 보자. 페이지가 렌더링됨에 따라 처음 헤더만 떴을때에는 헤더가 LCP, 그 다음 카테고리가, 그 뒤로는 스켈레톤, 그뒤로는 이미지가 LCP가 된다. 즉 LCP는 고정된 값이 아닌, 페이지 렌더링에 따라 변화하는 값이다.

출처: 모던 리액트 Deep Dive

LCP에 영향을 주는 요소와 개선법을 마찬가지로 정리해 보자면 다음과 같다.

큰 / 비압축된 이미지

뷰포트 내에서 가장 큰 이미지의 용량이 지나치게 크면 당연히 LCP가 느려질 수 밖에 없다. 따라서 적절한 품질의 크기로 압축하거나, 중요한 이미지의 경우 preload로 미리 다운받으면 좋다.

background-imge

img 태그 대신 background-image로 이미지를 삽입하게 되면 브라우저가 이를 필요로 하게 되기 전까지는 리소스 요청을 뒤로 미룬다. 즉 당연히 img태그보다는 LCP 성능이 떨어질 수 밖에 없다. 그래서 가장 크거나 중요한 이미지 요소는 웬만하면 background로 넣어주는걸 지양해야한다.

렌더링 차단 리소스(CSS, JS)가 많음

앞선 FCP와 동일하게 CSS는 경량화, JS는 코드 스플리팅, 트리쉐이킹 등으로 렌더링 블로킹을 최소화 해주면 좋다.

FadeIn과 같은 애니메이션

애니메이션으로 요소가 늦게 나타난다면 당연하게도 LCP가 늦게 측정된다. 근데 웬만한 깐지나는 사이트는 이미지가 다 스크롤하면서 FadeIn으로 올라오기 때문에,… 이건 좀 유하게 넘어갈만한 부분인 것 같다. 물론 SEO에 집착하는 사람이라면 당연히 넣으면 안될 것이다.

API 응답 지연

예를 들어 신문기사 같은 경우 기사 제목을 서버에서 불러와야 한다. 만약 CSR로 웹페이지가 제작된 경우, html을 파싱한 다음 api요청을 보내야 렌더링되기 때문에, LCP 속도가 현저히 늦어질 수밖에 없다. 따라서 이런 경우에는 SSR을 사용하는 것이 훨씬 효율적이다.

웹페이지 성능을 측정하는 데에는 다음과 같은 방법들이 있다. 자세하게 설명을 하고 싶으나, 그러자니 글이 너무 길어질 것 같아 우선은 관련 링크만 하단에 첨부하고 기회가 되면 더 자세히 다뤄보고자 한다.

• Google Lighthouse

https://developer.chrome.com/docs/lighthouse/overview?hl=ko

• react 내장함수 reportWebVitals

https://create-react-app.dev/docs/measuring-performance/

• webpagetest

https://www.webpagetest.org/

기존에는 개발자도구의 Performance Insights로도 성능 측정이 가능했으나, 25년 하반기부터 이 기능이 삭제되고 lighthouse로 대체된다고 한다(참고: https://developer.chrome.com/blog/perf-tooling-2024?hl=ko#the_experimental_performance_insights_panel_will_be_deprecated).

지금까지 웹 페이지 로딩 속도와 사용자 전환률의 상관관계, 성능 측정 지표와 도구에 대해 알아보았다. 아직까지는 겉핥기로만 살펴본 느낌이라, 기회가 되면 어떤 식으로 측정하는지, CSR과 SSR에서 각각의 지표들은 어느 정도 차이가 나는지 등등 더 자세히 포스팅 해보고자 한다.

긴 글 읽어주셔서 감사합니다.

References

[embed]사용자 인식과 웹 성능 측정의 변화 웹 성능 주요 지표인 Lighthouse 측정 지표에 대해 알아보고, 디지털 기술 발전과 최신 웹 개발 트렌드에 따른 Speed Index의 중요도 논란에 대해서도 함께 정리해 보았습니다.blog.imqa.io

[embed]What Speed Must E-Commerce Sites Hit to Maximize Sales? - fabric Inc. Pages on an e-commerce site should load in one second or faster.fabric.inc

[embed]Think with Google - Marketing Research, Insights, and Trends Stay ahead with the latest marketing research, expert insights, and digital trends with Think with Google's data…www.thinkwithgoogle.com

김용찬, [모던리액트 Deep Dive] , 위키북스( 2014)