디자이너가 개발자에게 자랑스럽게 본인이 디자인한 이미지를 들고 와서 이 이미지를 HeroImage로 만들어 달라고 요구했습니다.
초보 개발자는 경험이 많지 않았기 때문에 괜찮다고 이야기 했습니다. 하지만 시간이 지나고 나서 초보 개발자는 본인이 괜찮다고 이야기한 것을 후회했습니다. 이유가 무엇이었을 까요? 이유는 이미지의 크기가 4267px * 1788px 나 되는 HeroImage로 설정하기에는 너무나도 큰 크기의 이미지였기 때문입니다.
개발자기 디자이너가 준 이미지를 그대로는 HeroImage로 사용할 수 없다는 것을 깨닫게 된 것은 이미 많은 작업을 수행해 보고 난 후였고 개발자는 LCP 를 최적화 해야 한다는 것을 깨달을 수 있었다…
LCP 란 무엇일까?
Largest Contentful Paint (LCP) 웹의 콘텐츠 내에서 가장 큰 요소가 렌더링 되는데 걸리는 시간을 측정하는 시간을 나타냅니다.
LCP 로드 시간은 현재 사용하는 웹의 로드 속도가 얼마나 빠른지를 측정할 수 있습니다. 웹에서 간편하게 LCP 점수를 확인할 수 있는 방법은 Chrome에서는 Lighthouse 를 이용하여 현재 페이지의 점수를 통해서 확인할 수 있습니다.
그렇다면 왜 LCP가 중요할까요?
LCP는 W3C 웹 성능 실무 그룹의 토론 및 Google에서 진행한 연구에 따르면 페이지의 주요 콘텐츠가 로드되는 시점을 더 정확하게 측정할 수 있는 방법으로 Chrome에서 만이 아니라 용어가 다를 뿐 다른 웹 브라우저에서도 측정이 가능한 수치입니다.
또한 페이지에서 주요 콘텐츠가 로드되는 시점을 더 정확하게 측정하는 방법은 페이지 내의 가장 큰 요소가 렌더링되는 시점을 확인하는 것이기 때문입니다.
이러한 이유는 무엇일까요?
일반적인 경우 페이지를 로드하는 과정에서 가장 큰 페인트를 차지하는 부분은 사용자의 관점에서 의미 있는 이벤트를 의미하고 의도적으로 노출시키고 싶어하는 의도가 담겨 있는 요소입니다. 그렇기 때문에 이 요소가 렌더가 될 경우 사용자는 페이지를 이용하는데 있어서 현재 페이지가 사용이 가능한 상태로 모두 로드가 되었다고 여깁니다. 그렇기 때문에 현재 페이지가 렌더 되었는지를 확인하는 요소로 LCP 가 사용되는 것입니다.
이유에 대해서는 알아봤으니 이제 측정 방법에 대해서도 알아볼 필요가 있습니다.
LCP 에 대해 보고되는 요소의 크기는 일반적으로 표시 영역 내에서 사용자가 볼 수 있는 요소들의 크기를 기준으로 가장 큰 요소가 결정이 됩니다.
LCP를 측정하는 경우 한 번의 로드가 아닌 여러번의 시뮬레이션을 통해서 얻은 LCP 요소를 로드하는 시간 중 평균치의 시간을 구하는 것이 아닌 높은 백분위 수를 차지하고 있는 LCP의 경우 75번째 백분위수를 측정하는 것이 해당 페이지의 로드 시간을 측정하는데 유의미하기 때문입니다. 75번째 백분위수를 이용하는 이유가 무엇일까요?
위의 그림을 참고하여 설명을 이어가겠습니다. 위의 그림에서의 평균치의 경우 얼마나 많은 사용자가 실제로 지연을 경험했는지 대표할 수 없습니다. 왜냐하면 평균치의 값은 99분위의 응답 시간을 갖고 있는 사용자에 의해서 왜곡이 가능하기 때문에 사용자의 경험을 대표 할 수 없습니다.
하지만 75분위의 응답시간의 경우 극단적인 이상치에 영향을 받지 않고 측정을 시도할 때마다 크게 변동하지 않습니다. 그렇기 때문에 75분위를 기준으로 성능 개선을 해나갈 경우 대부분의 사용자는 좋은 사용자 경험을 겪고 있을 것이라는 것을 보장할 수 있습니다.
이러한 이유로 LCP는 현재 페이지를 한 번의 로드만 가정하는 것이 아닌 여러번의 시뮬레이션된 로드로 인해 측정된 LCP 시간의 75번째 백분위수를 측정하여 해당 LCP 시간이 2.5초 이하가 되었을 경우 해당 페이지가 최적화가 잘 되어 있다고 판단할 수 있습니다.
LCP 최적화 하기
앞서 LCP를 왜 측정해야 하고 LCP 점수가 갖는 의미에 대해서 자세하게 다루어 보았습니다. 다음으로 LCP의 최적화를 다루기 이전에 LCP 를 최적화 하기 위해서는 어떤 부분의 개선이 필요한지에 대해서 먼저 알아야 합니다. LCP에 가장 많은 영향을 주는 요소들은 아래와 같습니다.
위의 요소들은 LCP에 영향을 주된 요소들일 뿐이지 위에서 설명하지 않은 다른 요소들이 LCP에 영향을 주지 않는 것은 아닙니다! 그렇기 때문에 LightHouse를 이용하여 검사를 진행하였을 경우 위의 요소들 이외의 요소들에서 문제가 발생할 수도 있습니다.
하지만 실제로 LCP 를 최적화 할 수 있는 방법은 간단하지 않습니다. 이러한 이유는 한 부분만 개선한다고 LCP 가 개선되는 것이 아니기 때문입니다.
LCP를 실제로 최적화를 이루어내기 위해서는 위와 같은 모든 부분의 최적화가 이루어져야만 진정으로 LCP를 최적화를 진행했다고 말할 수 있습니다.
이번 포스트에서는 첫 바이트까지의 시간 TTFB를 제외한 다른 부분에서 어떻게 최적화를 할 수 있는지에 대해서 다루어보겠습니다! (이 주제만으로도 할 수 있는 이야기가 너무 많기 때문에 제외하였습니다 ㅎㅎ)
1. 리소스 로드 지연 제거
위의 그림에서 확인해볼 수 있듯이 LCP를 최적화할 때 그림에서 색깔로 구분이 되어 있듯 크게 4가지로 Document , Stylesheet , Image , Script 를 개별적으로 최적화하는 것이 좋습니다. 왜냐하면 각각의 영역에서 사용할 수 있는 구체적인 최적화 기법들이 구분되어 있기 때문입니다. 하지만 경우에 따라 한 부분에 최적화를 적용해도 LCP가 개선되지 않고 절약된 시간이 다른 부분으로 옮겨지는 상황이 발생되기도 합니다.
일반적으로 LCP 리소스의 로드 속도에 영향을 주는 요소는 두 가지가 있습니다.
리소스가 검색될 때
리소스에 부여되는 우선순위
그렇다면 위 두 가지 요소를 최적화 하기 위해서는 어떻게 해야 할까요? 리소스가 검색 되는 시간을 빠르게 하면 되겠죠? 또 리소스의 우선순위를 높임으로써 빠르게 로드 되게 끔 하는 것으로 최적화를 진행할 수 있습니다.
말은 어려워 보이지만 실제로 우리가 최적화를 진행할 경우 그리 복잡하지 않습니다. 이유는 이미 많은 천재들이 우리를 위해서 많은 일을 대신 해주고 있기 때문이죠 ㅎㅎ
리소스가 검색되는 시간을 단축하기
위와 같이 preload를 이용하여 link 로 연결되어 있는 리소스는 중요하기 때문에 우선순위를 증가시킬 수 있게 끔 알려주고 브라우저가 HTML을 파싱하기 이전에 리소스를 로딩할 수 있게끔 하여 자원이 더 빠른 시간내에 검색되어 더 빠르게 로딩될 수 있게끔 할 수 있습니다.
위의 속성을 페이지 내에서 크기가 커서 미리 로드가 되어야하는 자원들 혹은 페이지 내에서 사용되어야 하는 폰트들을 HTML 파싱 이전에 로드함으로써 웹의 성능을 최적화 할 수 있습니다.
요소 렌더링 지연 제거하기
LCP 요소가 리소스 로드가 완료된 후 즉시 렌더링 할 수 없는 주된 이유는 다른 이유로 렌더링이 차단된 경우입니다. 렌더링을 차단할 수 있는 주요 원인들은 외부 스타일 시트 head 내부에서 동기 스크립트로 인해 전체 페이지의 렌더링이 이뤄져야 할 경우 등의 문제가 있습니다. 이를 위해서는 어떻게 해야 할까?
추가적인 네트워크 요청을 피하려면 스타일 시트를 HTML에 인라인으로 추가하거나 줄여야 한다.
자바스크립트 코드를 페이지 로드에서 최대한 빨리 실행해야 하는 경우 다른 네트워크 요청을 기다리는 동안 렌더링이 지연되지 않도록 코드를 인라인하는 것이 가장 좋습니다. 하지만 스타일시트와 마찬가지로, 스크립트의 크기가 매우 작은 경우에만 삽입해야 합니다.
또 다른 해결 방법은 SSR(서버 측 렌더링)을 사용하는 것입니다. SSR의 가장 큰 단점은 서버 처리 시간이 추가로 필요하여 TTFB가 느려질 수 있다는 점입니다. 하지만 서버 처리 시간은 개발자가 제어할 수 있는 반면 사용자의 네트워크 및 기기 기능은 제어할 수 없기 때문에 이러한 단점은 그만한 가치가 있습니다.
3. 리소스 로드 시간 줄이기
사실 이번 발표에서 가장 이야기하고 싶었던 핵심은 리소스 로드 시간을 줄이는 방법에 대해서 공유하고 싶었습니다. 이유는 앞서 설명했던 방법들 중 가장 드라마틱한 효과를 볼 수 있는 최적화 방법일 뿐만 아니라 리소스의 로드 시간을 줄일 경우 전체 페이지 로드 시간 또한 같이 개선되어 다른 성능 지표에도 긍정적인 영향을 줄 수 있기 때문입니다.
리소스의 로드 시간을 줄이기 위한 방법은 다음과 같습니다.
리소스 크기를 줄입니다.
리소스가 이동해야 하는 거리를 줄입니다.
네트워크 대역폭에 대한 경합을 줄입니다.
네트워크 시간을 완전히 없앱니다.
Unsplash
저는 위와 같은 요소들을 최적화 하기 위해서 이미지 하면 가장 먼저 떠올랐던 대표적인 기업인 unsplash가 떠올랐습니다. unsplash 는 여러가지 아름다운 무료 이미지를 고화질의 품질로 제공해주는 굉장히 유용한 사이트입니다.
unsplash는 굉장히 많은 이미지를 사이트내에 포함하고 있음에도 굉장히 좋은 성능과 LCP 타임을 갖고 있는 것을 확인할 수 있습니다. 그래서 저는 unsplash는 어떻게 이렇게 좋은 성능을 갖고 있는 것인지 의문이 생겼고 실제로 리소스 로드 시간을 어떻게 줄이고 있는 지에 대해서 분석해보고자 했습니다.
1. 리소스 크기를 줄이기
리소스 크기를 줄이는 방법은 간단합니다. 기존의 예시로 설명했던 4267px * 1788px 크기의 이미지를 절반의 크기인 2134px * 894px 로 줄이는 것입니다. 하지만 이럴 경우 피할 수 없는 문제가 발생합니다.
이미지를 축소할 때 원본의 픽셀 정보를 버리게 됨으로써 생기는 선명했던 경계들이 모호해지고 흐려지는 화질 저하 문제를 피할 수 없습니다. 이미지를 축소할 때 원본의 픽셀 정보 손실로 인한 선명도 저하는 불가피하지만, 적절한 기술을 사용하여 이를 최소화할 수 있습니다.
우리가 선택할 수 있는 기술들은
적절한 파일 형식을 선택한다
Photoshop등에서 제공하는 효과적인 리샘플링 알고리즘 사용한다.
이미지 특성에 맞는 압축 기법 적용한다
위와 같은 선택지 중 몇 가지를 선택하여 적용할 수 있습니다. 하지만 위의 방법들 중 가장 사용하기 좋고 사용해야 한다고 생각하는 것은 적절한 파일 형식을 선택하기와 이미지 특성이 맞는 압축 기법을 사용하기입니다.
적절한 파일 형식
적절한 파일 형식의 경우 최근 들어 사용하기를 권장되고 있는 이미지 타입은 webp 와 avif 입니다.
두 타입 중 재가 개인적으로 더 좋아하는 이미지 타입은 avif 입니다! 이유는 단순합니다. 압축률이 굉장히 뛰어나서 더 적은 크기의 이미지를 높은 화질로 사용할 수 있기 때문입니다. 뿐만 아니라 png와 같이 이미지의 알파 채널을 지원하기 때문에 다양한 곳에서 사용이 가능하기 때문에 유용하다고 할 수 있습니다.
AVIF 는 AV1 비디오 코덱을 이미지를 압축하는데 사용한 획기적인 이미지 포맷입니다. AVIF가 획기적인 이유는 비디오 코덱을 사용해서 이미지를 압축하려고 하였다는 점입니다. 이 과정에서 저는 왜 굳이 비디오 코덱을 이미지를 압축 하는데 사용했는지 의문이 생겼습니다.
이러한 이유는 비디오 압축 기술이 수년간 대용량 데이터를 효율적으로 압축하는 데 초점을 맞춰 발전해왔기 때문입니다. 비디오 기술 중 영상의 프레임 간에 생기는 중복을 제거하기 위해 개발된 인터 프레임 압축 기술은, 단일 이미지 내에서도 유사한 영역 간의 중복성을 효과적으로 제거하였습니다. 이외에더 많은 기술들을 활용하여 높은 압축률로 로딩 속도 향상과 대역폭 절약에 큰 도움을 줄 수 있었습니다.
AVIF 이미지는 다른 이미지에 비해서 더 넓은 영역의 색 표현이 가능합니다. AVIF는 비디오 코덱을 이용하기 위하여 RGB 방식이 아닌 YUV 색공간을 사용하여 이미지를 렌더하는 방식을 사용했습니다.
AVIF는 우리가 흔히 알고 있는 RGB 에서 YUV 색공간으로 변환이 이루어집니다. 여기서 Y는 휘도 U, V 는 색차 정보를 나타냅니다. 이러한 색공간의 변화로 인해서 얻을 수 있는 이점은 비디오 코덱과의 호환성이 좋아진다는 것입니다.
기존의 YUV 는 역사적으로 흑백 텔레비전 시대에서 컬러 텔레비전을 원했던 시기에서 발명 되었고 이 기술이 발전되어 왔기 때문에 AV1 비디오 코덱을 이용하기에 적합했기 때문에 RGB가 아닌 YUV 색공간을 사용한 것입니다.
이외에도 여러가지 변화 엔트로피 코딩, 이미지 분할 등의 여러 기술들이 적용됨으로써 AVIF는 기존의 다른 이미지 포맷들에 비해 높은 압축률과 높은 품질의 이미지를 웹에서 사용가능하게끔 하였습니다.
다른 이미지 포맷과의 차이점
동일한 고양이 사진을 동일한 품질의 이미지로 웹에서 압축한 결과는 JPEG는 249kB, WebP는 153kB, AVIF는 96kB입니다. 위의 영상을 참고하면 가장 큰 크기의 이미지 파일인 JPEG가 프로그레시브 이미지 렌더링 , 이미지 데이터를 여러 스캔으로 나누어 점진적으로 표시함으로 인해서 가장 빠른 것 처럼 보입니다. WebP의 경우 위에서부터 아래로 렌더링이 되어 다른 이미지들이 로드되는 방식에 비해서 느리게 렌더가 되는 것처럼 보입니다. AVIF의 경우 전체가 렌더되거나 그렇지 않은 상태로 구분되어 렌더가 되는 것을 확인할 수 있습니다.
위의 짧은 영상에서 확인할 수 있듯이 같은 품질의 이미지를 다른 이미지 포맷에 비해 훨씬 가벼운 크기로 압축되는 AVIF를 사용하지 않을 이유가 없습니다. 하지만 현재 위의 영상처럼 로드하기 보다는 이미지 전체가 로드되지 않았을 경우에는 더 낮은 품질의 이미지를 미리 로드되어 전체 이미지가 표시되기 전까지 blurr 이미지로 대체할 경우 더욱 개선할 수 있습니다.
위와 같은 방법을 실제로 unsplash에서도 사용하고 있습니다.
위의 이미지 URI는 실제 이미지를 BMP 형식의 작은 이미지로 실제 이미지의 전체가 로드되기 전에 이미지가 로드되지 않은 공간을 채워서 사용자 경험을 개선하기 위한 용도로 사용하고 있습니다.
그리고 이미지 로드가 모두 끝났을 경우 본 이미지를 로드하는데 여기서 눈여겨 볼 수 있는 부분은 sizes 속성과 srcset 속성을 눈여겨 볼 수 있습니다. 가장 먼저 sizes 속성을 살펴보겠습니다.
위의 sizes 속성이 의미하는 것은 뷰포트(viewport)의 크기가 1351px 이상일 경우 이미지는 416px 폭으로 표시하고 뷰포트의 크기가 992px-1350px 사이일 경우 뷰포트 폭의 1/3에서 약간의 여백을 뺀 크기로 표시하라는 것을 의미합니다.
위의 srcset의 URI 데이터에서 w=100&auto=format , w=200&auto=format 이 100w 일경우, 200w일 경우로 구분이 되어 서로 다른 크기의 width와 height이 적용되어 있음을 알 수 있습니다.
위와 같이 sizes 와 srcset 을 활용하여 뷰포트의 크기에 맞춰 로드 될 이미지의 크기를 미리 알려줌으로써 브라우저는 이미지의 크기를 미리 알고 있음으로 초기 페이지 렌더링을 더 빠르게 할 수 있을 뿐만 아니라 불필요한 크기의 이미지를 다운로드하는 것을 방지함으로써 로딩 시간을 단축 시킬 수 있습니다.
2. 리소스의 거리 줄이기
리소스의 거리를 줄이는 가장 대표적이고 이미지를 최적화 한다고 할 경우 가장 많이 언급되는 것이 CDN을 사용하라는 것입니다. CDN을 사용하는 것이 이미지의 최적화에 많은 영향을 주는 이유는 무엇일까요?
CDN이 이미지의 최적화에 있어서 수행하는 역할은 굉장히 많지만 그 중에서도 눈에 띄는 특징은 자원이 이동해야 하는 물리적인 거리를 짧게 함으로써 웹의 성능을 개선할 수 있다는 점입니다! CDN은 전 세계에 분산 된 서버 네트워크를 사용하여 사용자와 가장 가까운 서버에서 콘텐츠를 제공함으로써 이를 실현합니다.
CDN(Content Delivery Network)은 지리적으로 분산 된 서버들을 연결한 네트워크입니다. CDN의 많은 서버들은 네트워크 에지라고 불리는 최종 사용자와 가까운 위치에 배치됩니다.
여기서 네트워크 에지는 주로 CDN 제공 업체가 운영하는 서버들을 의미하며, 이는 사용자와 원본 서버 사이의 중간 지점에 위치합니다. CDN은 사용자의 요청을 DNS 기반 라우팅 등의 방법을 통해 지리적으로 가장 가까운 또는 가장 효율적인 CDN 서버로 안내하여, 해당 서버에서 요청된 콘텐츠를 제공합니다. Unsplash 또한 CDN을 이용하여 이미지 최적화를 하고 있다는 것을 Unsplash Image의 Response Header 에서 확인할 수 있었습니다.
x-cache 헤더는 사용자가 보낸 요청한 이미지가 CDN의 캐시 계층을 통과하면서 각각의 캐시 상태에 대한 정보를 포함하고 있습니다. x-served-by 는 각각의 캐시 계층의 서버 정보, 어느 나라의 서버가 데이터를 갖고 있었고 콘텐츠를 제공했는 지에 대한 정보를 알 수 있습니다. 위의 내용이 Unsplash 또한 CDN을 사용하고 있음을 알 수 있음을 알 수 있는 증거입니다. 위의 예시를 활용하여 CDN이 어떻게 이미지를 최적화 하는데 사용할 수 있는 지에 대해서 설명해보겠습니다.
위의 그림에서 추가적으로 확인할 수 있는 것은 분산 캐싱을 이용한다는 것입니다. 여러 지역에 위치한 캐시 서버들(ICN, CHI, TYO)이 콘텐츠를 저장하고 제공합니다. 이러한 분산 캐싱을 활용하여 사용자와 가장 가까운 위치의 네트워크 에지 서버를 발견 했을 경우 바로 이미지를 전달하고 프로세스를 종료하기 때문에 네트워크 대역폭에 대한 경합을 줄이고 네트워크 시간을 완전히 없애는 것이 가능하다는 장점을 갖고 있습니다.
위의 그림은 가까운 네트워크 에지 서버에서 찾고자 하는 이미지가 발견되지 않았을 경우에 대한 흐름을 나타내고 있습니다. 사용자가 찾으려고 하는 이미지가 모든 네트워크 에지 서버에 caching이 되어 있지 않을 경우도 있을 수 있습니다. 이 경우 사용자로부터 가까운 네트워크 에지 순으로 요청을 전달하며 이미지를 발견할 때 까지 요청을 전달하고 이미지를 발견하였을 경우 해당 이미지를 반환하면서 caching을 진행함으로써 다음 번에 같은 요청이 왔을 경우 빠른 응답을 할 수 있게 끔 기능을 수행합니다.
CDN을 사용함으로써 얻을 수 있는 장점은 지금까지 설명한 리소스의 거리 줄이기 라는 장점 만을 갖지 않습니다. 각각의 CDN은 Edge Computing 을 활용하여 동적으로 이미지 리사이징을 진행한다 거나 브라우저에서 사용이 가능한 호환성에 맞는 이미지 포맷으로 변환을 해주거나 자동으로 이미지를 개선해주는 등의 최신 기술들을 활용하여 더 빠른 로딩 시간, 낮은 대역폭 사용, 더 나은 사용자 경험을 얻을 수 있게 끔 하기 때문에 웹에서 이미지를 사용한다고 하면 CDN은 항상 강조되는 이미지 최적화 수단이라고 할 수 있습니다.