이 글은 DEVOCEAN 세미나를 들었던 내용을 개인적으로 정리한 글이다.
영상의 길이가 길어 다시 보기에는 번거로운 분들이 보면 좋을꺼 같습니다 :)

목차

• 왜 웹 성능 최적화를 해야할까?
• 그럼 웹 성능을 측정하는 방법은 어떤게 있을까?
• CWV를 이용해 어떻게 최적화를 할 수 있을까?
• 세미나 회고

왜 웹 성능 최적화를 해야할까?

구글에서 조사한 통계에 의해서 조사한 통계자료이다. 페이지라 로딩되는 속도에 따른 사용자의 이탈율을 보여준다.
이를 통해 웹 페이지의 로딩 시간이 길어질수록 이탈율이 늘어나 서비스측면에서 악영향을 끼친다는걸 알 수 있다.

사용자 설문조사에서도 페이지의 로딩 속도가 가장 사용자 경험측면에서 중요하다고 답변을 했다.

추가적으로 빠른 로딩속도로 인해 사용자들의 서비스에 더 오래 머물고 커머스 서비스의 경우에도 많은 구매율을 보여준다.

그럼 웹 성능을 측정하는 방법은 어떤게 있을까?

CWV(Core Web Vitals)

구글에서 웹 사이트 성능 측정을 위한 지표이다.
사용자 측면에서 나온 지표로 3년전에 나와 많은 각광을 받고있다.

1. LCP (Largest Contentful Paint)

처음 화면이 떳을때 보여지는 가장 큰 부분이 얼마나 빨리 보여지는지를 측정하는 지표를 의미한다.
보통은 이미지를 얘기한다.

2. FID (First Input Delay)

사용자가 처음 상호작용을 했을때 얼마나 빠르게 상호작용을 해줄지에 대한 지표이다.

하지만 FID는 처음 상호작용만 측정을 하기 때문에 매번 사용자의 상호작용마다 측정할 수 있는 지표인 INP가 올해 나와 FID를 대체할꺼라고 한다.

3. CLS (Cumulative Layout Shift)

화면이 얼마나 안정적인지를 나타내는 지표이다.
예를들어 광고들이 content를 밀어버리는 등의 경우에 CLS에 악영향을 미친다.
화면이 덜 움직이는지를 보여주는 지표이다.

이와 같은 CWV 지표는 웹 사이트의 점수에 영향을 주고 이는 곧 서비스의 SEO에 하나의 지표로 판단되어진다.

CWV등의 사이트 지표를 측정할 수 있는 서비스

• PageSpeed Insights
• Chrome UX Report
• Search Console
• Chrome DevTools
• Lighthouse
• Web Vitals Extension
  등등...

발표자분은 web page test를 주로 쓴다고 한다.

RUM 데이터 측 실제 사용자의 사용을 모니터링 하는 서비스는 web-vitals JS를 주로 사용한다. 이 툴은 다른 브라우저라도 모두 측정이 가능한 서비스이다.

CWV를 이용해 어떻게 최적화를 할 수 있을까?

LCP 최적화

LCP는 앞에서도 얘기했던 거처럼 초기에 가장 큰 부분의 렌더링 속도를 측정한 지표이다.

결론부터 얘기하면 사용자에게 보여줄 수 있는 최적화 방법은 다운받아와야 할 리소스를 앞으로 땡겨와 다운받도록 하는 모든 방법이다.

1. 원하는 리소스를 HTML로 불러오기

우리가 정적 사이트를 받아올때 HTML을 먼저 받아와 파싱을 통해 DOM요소를 만들게 된다.
img 태그를 이용해 이미지를 지정하면 빠르게 이미지를 받아올 수 있기 때문에 LCP에 유리하다.

반대로 CSS 태그를 통해 이미지를 불러온다거나 JS를 통해 이미지를 불러온다거나하면 늦게 리소스를 다운받기 때문에 LCP에는 좋지 않다.

2. HTML 요소에 Preload 속성 부여

<link rel="preload"> // 외부 리소스 참조하는 경우

<img fetchpriority="high" /> // 내부 리소스 참조하는 경우

태그에 속성을 통해 우선되어서 다운받아야할 리소스를 지정해 빠르게 다운받게 할 수 있다.

3. CDN 서버를 사용한다.

물리적으로 사용자에게 가까운 CDN 서버를 이용해서 리소스를 빠르게 다운받도록 할 수 있다. 이를통해 TTFB를 줄일 수 있다.

4. SSR을 이용한다.

브라우저에서 렌더링을 최소화해서 클라이언트는 서버에서 응답을 받자마자 사용자에게 보여질 수 있도록 할 수 있는 방법도 있다.

5. loading="lazy" 기법을 이용한다.

사용자가 접근했을때 바로 보이지 않는 이미지에 lazing을 하면 초기에 다운받을 이미지를 줄일 수 있다.

6. 이미지 크기 최적화

PNG와 JPEG보다 WebP, AVIF가 압축률이 너 우수하다. 기존대비 이미지 크기를 크게 줄일 수 있다.

하지만 브라우저별로 WebP, AVIF 지원여부가 다르기 때문에 잘 판단해서 적용하는게 중요할꺼 같다.
위 버젼 기준으로 WebP는 IE를 제외하고 대부분의 브라우저에서 지원하는걸 확인할 수 있다.

서비스 기기별로 이미지를 최적화 하는방법도 있다. 예를들어 144x144 크기의 이미지만 보여주는 모바일 화면에서 1440x1440 이미지를 서버로 부터 받아와서 렌더링하는거면 리소스가 낭비가 된다.
이를 개선하기 위해서 디바이스별로 크기가 다른 이미지를 만들고

CLS 최적화

CLS는 얼마나 화면이 안정적인지를 나타내는 지표이다.
이를 해결하기 위해서는 content에 사이즈를 명시해주면 해결될 수 있다.

보통 동적으로 로딩되는 컨텐츠가 문제가 된다.

1. 컨텐츠 위치 고정하기

예를들어 위 사진 before 부분에 banner나 image에 사이즈가 고정되지 않으면 렌더링이 될때 밑에 글 컨텐츠가 밑으로 밀리는 이슈가 발생한다.

그래서 after처럼 미리 banenr나 이미지 자리를 미리 확보해서 다른 컨텐츠가 밀리지 않도록 세팅하는게 중요하다.

2. 애니메이션 지양하기

그리고 기존 layout을 이동시키거나 흔드는 애니메이션은 최대한 지양하는게 중요하다. 특히 처음뜰때 애니메이션은 좋지 않다.

3. bfcache 동작여부

사용자가 뒤로 앞으로 가기 누를 때 정보를 저장해놓고 다시 네트워크 요청을 하지 않도록 하게 하는게 좋은데 요즘에 왠만한 최신 브라우저는 이 기능을 기본적으로 제공해준다.

개발자 도구로 bfcache 내 서비스에서 제대로 동작중인지 확인할 수 있다.

4. aspect-ratio 설정

반응형으로 달라지는 이미지의 경우 고정값을 주기 어려운데 이를 너비값만 주고 높이값은 aspect-ratio 속성을 이용해서 고정적으로 너비대비 높이가 얼마나 차지할껀지 고정해줄 수 있다.

이를 통해 미리 어느정도 자리를 차지할껀지 설정을해 다른 컨텐츠가 밀리지 않도록 설정할 수 있다.

5. min-height 주기

텍스트 길이에따라서 컨텐츠의 크기가 변할때 최소한의 크기를 줘서 컨텐츠가 밀리는걸 방지할 수 있다.

FID 최적화

사용자의 요청에 서비스가 얼마나 빠르게 상호작용을 하는지에 대한 지표이다.

1. Long task를 지양하기

자바스크립트는 기본적으로 싱글 스레드이기 때문에 하나의 긴 task로 처리가 되면 다른 작업을 하지 못하기 때문에 사용자에게 안 좋은 경험을 줄 수 있다. (다운로드는 병렬적으로 받지만)
이를 위해서 잘게 쪼개서 필요한 부분만 다운로드해서 처리하는방법으로 작성하는게 중요하다.

2. 불필요한 JS코드 줄이기

지속적으로 개선이 필요한 작업이다.

크롬 개발자도구에서도 확인해볼 수 있다.

사용자의 tracking을 위한 코드들이 많아지는경우 필요하지 않은 정보의 코드는 없애주는 작업도 필요하다.

3. 큰 렌더링 업데이트 하지 말기

4. 코드 스플릿팅하기

SPA 라이브러리나 프레임워크에서 지원하기도 하고 Webpack에서도 지원한다.
큰 하나의 파일을 잘께 쪼개서 청크로 만들어 받을 수 있는 방법이 많이 있다.

5. requestAnimationFrame() 지양하기

6. Dom 사이즈를 작게 유지하기

Dom 갯수가 너무크면 HTML을 그리는데 많은 시간을 소모하기 때문에 필요한 태그만 사용하는게 중요하다.

세미나 회고

프론트엔드 개발자를 희망하고 공부하고 있고 이를 활용해 서비스 개발을 하고 싶지만 막상 서비스의 전달에 대한 관심은 없었다.

서비스 전달에 대해서 중요한 부분이 사용자 경험의 향상이라고 생각을 하고 사용자 경험의 향상은 웹 어플리케이션의 성능에 직접적으로 연관이 있다고 생각을 했다.

이번 DevOcean 세미나를 보면서 웹 성능 측정 지표는 어떤게 있고 어떻게 최적화를 할지 전체적인 그림이 그려진거 같다.