예전 NextJS 를 처음 공부 할 때 만들었던 기술 블로그인 abonglog ver1 을 뒤로 하고 React 19, NextJS 15, supabase 와 함께 이 블로그 를 개발해봤습니다.
이전에 사용하던 블로그는 DB 없이 마크다운 파일을 NextJS 내부 public 폴더에 만들어두고 그 안에서 정적으로 만들어진 마크다운 파일을 파싱하여 html 문서들을 만들어두는 방식이라 실제 웹 개발과는 거리가 멀어 마음에 들지 않았습니다.
그래서 뚝딱뚝딱 삼주간 이 블로그를 만들어봤는데 성능은 신경쓰지 않고 개발만 한터라 무진장 느려 이제는 성능 개선을 위한 작업을 들어가고자 합니다 🔥
웹 성능이란 ?
MDN 에선 웹 성능을 웹 사이트 또는 애플리케이션의 객관적인 지표이고 인지된 사용자 경험 이라고 정의합니다.
이 안에선 객관적 성능, 인지된 성능 두 가지 카테고리로 나눠집니다. (사실 나뉘어진다고 보기보단 객관적 성능이 인지된 성능의 하위 집합이라 저는 생각했습니다.)
1. 객관적 성능 (Objective Performance)
웹사이트 성능 측정은 실제 측정 가능한 지표를 기반으로 웹사이트의 성능을 평가하는 것을 의미합니다.
이는 로딩 시간, 서버 응답 속도, 리소스 크기 등과 같은 기술적인 측면을 포함합니다.
주요 측정 지표로는 페이지 로드 시간, 첫 번째 콘텐츠 표시 시간(FCP), 최대 콘텐츠 표시 시간(LCP), 상호 작용 시간(TTI), 서버 응답 시간 등이 있습니다.
객관적인 성능 지표는 웹사이트의 기술적인 문제를 파악하고 개선하는 데 필수적이며, 검색 엔진 최적화(SEO)에도 영향을 미치고 사용자 경험의 기반이 됩니다. 웹사이트 성능 측정 도구로는 Google Lighthouse, PageSpeed Insights, WebPageTest 등이 널리 사용됩니다.
웹 페이지의 객관적 성능은 사용자가 문서를 요청하여 사용자가 문서를 이용하기 까지의 일련의 과정들 속에서 평가 가능한 객관적 지표 입니다.
평가 가능한 객관적 지표들은 추후 다음 챕터에서 자세히 기술 합니다.
2. 인지된 성능 (Perceived Performance)
인지된 성능은 사용자가 웹사이트의 성능을 어떻게 느끼는지를 의미합니다. 이는 실제 로딩 시간뿐만 아니라, 사용자 인터페이스(UI)의 반응성, 애니메이션, 시각적 안정성 등과 같은 요소에 의해 결정됩니다.
주요 측정 지표로는 사용자의 주관적인 만족도, 시각적 안정성(CLS), 부드러운 애니메이션 및 전환 효과, 빠른 피드백 제공 등이 있습니다. 인지된 성능은 사용자 만족도와 직결되며, 웹사이트의 성공에 중요한 영향을 미칩니다.
사용자가 웹사이트를 빠르고 쾌적하게 느낄 수 있도록 만드는 것이 목표이며, 이를 위한 개선 방법으로는 프로그레시브 로딩, 스켈레톤 UI, 애니메이션 및 전환 효과 최적화, 사용자 인터랙션에 대한 즉각적인 피드백 제공 등이 있습니다.
예를 들어 페이지가 매우 느리게 나타나는 페이지더라도 애니메이션을 제공한다는 등의 방식을 통해 인지된 성능을 향상 시킬 수 있습니다.
시간은 어떤 일이 일어나기를 수동적으로 기다리는 사람보다 능동적으로 흥미를 느끼고 주의에 끌리거나 즐거워 하는 사용자에게 더 빠르게 지나갑니다. [1]
성능 예산
성능 예산은 위에서 기술한 웹 성능들을 이용해 만든 지표를 의미 합니다. 이 지표들은 대략적으로 3가지로 나눠 세울 수 있는데 정량적 목표, 시간 기반 목표, 규칙 기반 목표로 정의 할 수 있습니다.[2]
성능 예산을 지표에 따라 목표화 한 예시는 다음과 같습니다.
- 각 페이지의 파일 크기는 10mb 이하여야 한다, 한 페이지를 구성하기 위한 네트워크 요청 횟수는 10회를 넘기지 않는다. (정량적 목표)
- 모든 페이지의 Time To Interactive 는 3초 를 넘기지 말아야 한다. (시간 기반 목표)
- 페이지를 평가하는
lighthouse점수는 90점 이상이여야 한다. (규칙 기반 목표)
3가지 평가 방식 모두 결국 웹 성능과 관련 있는 지표로 목적에 따라 지표를 선택하여 목표를 세울 수 있습니다.
예를 들어 목표가 사용자가 웹 사이트를 빠르고 쾌적하게 사용하는 것이 목표인 회사 A 가 있다고 가정해보겠습니다.
이 회사는 사용자 경험과 관련된 지표인 TTI (Time To Interactive) , FID (First Input Delay), LCP (Largest Contentful Paint) 이 목표 지표가 될 것입니다.
검색 엔진 최적화가 목표인 회사 B는 검색 엔진 결과에서 높은 순위를 얻기 위해 Lighthouse 성능 점수나 페이지 로딩 속도와 관련된 목표 지표를 잡을 것입니다.
사용자가 빠르게 컨텐츠를 소비하기를 원하는 뉴스 회사 C 는 컨텐츠가 가장 빠르게 표시 되기 의한 지표인 FCP (First Contentful Paint)를 목표 지표로 잡을 것입니다.
lightHouse로 살펴보는 성능 지표
저에게 필요한 성능 예산은 블로그다보니 높은 SEO와 FCP 등입니다. 웹 성능을 평가하는 다양한 도구들이 존재하지만 이번엔 lightHouse 를 기반으로 하여 성능을 평가하고 해당 점수들의 의미들을 알아보고자 합니다.
lightHouse 란
lighthouse 는 구글에서 제공하는 웹 페이지의 성능, 접근성, 프로그래시브 웹 앱, 검색엔진 최적화 등을 감사하는 오픈소스 자동화 도구입니다. [3]
lighthouse 는 검색 엔진에 유의미한 영향을 미치는 Core Web Vitals 뿐 아니라 다양한 측정 항목을 제공합니다.
Core Web Vitals는 이름에서 알 수 있듯 웹 사이트가 검색 엔진 평가 항목에서 영향을 미치는 세 가지 웹 성능 측정값입니다.가장 대표적인 예시로는 웹 페이지가 처음 클라이언트에게 도달하기 까지의 지표를 나타내는
LCP(Largest Contentful Paint), 웹 페이지가 도달하여 클라이언트가 사용하기 까지 걸리는FID (First Input Delay), 웹 페이지가 도달 후 레이아웃 변화 없이 얼마나 안정적인지를 나타내는CLS (Cumulative Layout Shift)가 있습니다. [4]
lightHouse Performance
lightHouse 의 성능 점수는 Core Web Vitals 3가지와 두 개의 추가 항목 Speed Index , Total Blocking Time 의 가중 평균치로 계산 됩니다.
FCP (First Contentful Paint, 10%)
FCP 는 사용자가 페이지로 처음 이동한 시점부터, 페이지 컨텐츠의 일부가 화면에 렌더링 되는 시점까지의 시간 을 측정합니다. [5]
컨텐츠는 텍스트, 이미지 (배경 이미지 포함), 흰색이 아닌 svg , canvas 요소를 의미 합니다.
빠르면 빠를 수록 좋고 1.8초 이상 부턴 개선이 필요한 점수로 평가 합니다.
Speed Index (10%)
스피드 인덱스는 컨텐츠가 시각적으로 표시되는 속도를 측정합니다.
브라우저에서 페이지가 로드되는 동안의 동영상을 캡쳐하고, 프레임간의 시각적 진행을 계산합니다. [6]
1초에 10프레임씩 나눠 영상을 촬영하고 각 프레임 별로 컨텐츠가 차있는 비율을 계산합니다.
이후 시간 별 컨텐츠가 차있는 동안을 계산하여 그래프로 만들고 페이지가 모두 차기 전까지 지난 기간동안 브라우저가 비어있는 비율을 계산하여 인덱스 값을 계산합니다. [7]
LCP (Largest Contentfull Paint , 25%)
LCP 는 브라우저가 처음 렌더링 될 때 표시 영역에 표시 되는 가장 큰 이미지, 텍스트 블록 또는 동영상의 렌더링까지 걸린 시간 을 의미합니다. [8]
FCP 가 어떠한 컨텐츠든 상관 없이 어떤 요소든 눈에 보이기 까지의 시간을 계산한 것과 대조적으로 LCP 는 다음과 같은 요소들을 meaningful content 로 고려 합니다.
img요소svg요소 내의image요소video요소css의url()함수를 사용하여 로드된 배경 이미지가 있는 요소- 텍스트 노드 또는 기타 인라인 수준 텍스츠 요소 하위 요소가 포함된 블록 수준 요소
각 요소들의 크기는 일반적으로 페이지를 처음 로드하여 사용자에게 보이는 화면 내에 존재하는 요소로 국한됩니다.
눈에 보이는 부분을 넘어서는 요소는 크기에 포함되지 않으며, 크기가 다른 이미지나 텍스트 요소가 있을 때 가장 작은 크기의 요소를 고려합니다. [8]
LCP 는 2.5초 이하일 때 좋은 LCP 점수로 평가합니다.
좋고 나쁨의 기준은 전체 브라우저를 100분위로 나눴을 때 25등까지를 좋은 점수로 취급합니다.
TBT (Total Blocking Time , 30%)
TBT 는 FCP 이후 인터렉션이 일어나기 전까지 기본 스레드가 차단 되었던 총 시간을 측정 합니다.
기본 스레드에서 50ms 이상 실행되는 긴 작업이 있다면 스레드는 차단 된 것으로 간주 됩니다.
만일 스레드가 250ms 이상 걸리는 작업을 시행하게 되면 TBT 는 250 - 50ms 인 200ms 동안 차단 되었다 이야기 합니다.
우수한 사용자 환경을 제공하기 위해선 평균 모바일 하드웨어에선 200ms 미만이 되도록 노력해야 한다고 합니다. [9]
CLS (Cumulative Layout Shift , 25%)
CLS는 페이지의 전체 수명 주기 동안 발생하는 예기치 않은 레이아웃 변경에 대한 점수로, 가장 큰 버스트를 측정 합니다.
레이아웃 쉬프트가 나쁜 이유에 대해선 레이아웃 변경 횟수(CLS) | Articles | web.dev 페이지에 들어가면 제공되는 동영상을 보면 알 수 있습니다.
사용자가 예기치 못한 레이아웃 쉬프트로 인해서 본래 의도와 다른 인터렉션을 시행하게 될 수 있기 때문입니다.
화난 마우스 연기가 일품입니다.
다만 모든 레이아웃 쉬프트가 나쁜 것은 아닙니다.
사용자가 시작한 레이아웃 변경은 일반적으로 괜찮습니다. 예를 들어 사용자가 버튼을 눌러 게시글을 더보기로 하는 것 처럼 말입니다.
이런 경우엔 레이아웃 쉬프트가 상호작용과 충분히 근접하여 , 사용자에게 관계가 명확하게 인식 되어야 한다고 합니다.
마치며
lightHouse 에선 Performance 뿐 아니라 다양한 내역들을 평가해줍니다만 이번 글에선 여기까지만 작성하도록 합니다.
이후 개선해야 할 끔찍한 제 블로그의 점수를 공개 합니다.
으아악 하나씩 차차 고쳐나가봐야겠습니다.
출처
- 인지된 성능 - Web 개발 학습하기 | MDN
- AddyOsmani.com - Start Performance Budgeting
- Lighthouse 소개 | Chrome for Developers
- 코어 웹 바이탈 (Core Web Vitals)이란? - TBWA 데이터랩
- First Contentful Paint (FCP) | Articles | web.dev
- 속도 색인 | Lighthouse | Chrome for Developers
- Speed Index | WebPageTest Documentation
- 최대 콘텐츠 렌더링 시간(LCP) | Articles | web.dev
- 총 차단 시간 (TBT) | Articles | web.dev
- 레이아웃 변경 횟수(CLS) | Articles | web.dev
