오늘의발견
웹성능 최적화! 구글 라이트하우스를 활용한 웹사이트 진단 및 개선 방법
안녕하세요! aloveu입니다.
블로그를 운영하든 웹사이트를 운영하든 SEO가 중요하다는 건 모두 아실 텐데요.
이 SEO에 중요한 영향을 미치는 웹성능에 대해서 구글에서 제공하는 lighthouse라는 성능체크툴을 이용해 알아보려고 합니다.
라이트 하우스 말고 다른 페이지 성능 결과를 보여주는 사이트는 https://pagespeed.web.dev/?hl=ko 도 있어요.
| Lighthouse 실행하기
크롬에서 웹사이트를 들어간 다음에 F12를 눌러봅니다.
그러면 devtools가 뜨는데 여기 상단탭에 보면 lighthouse라는 탭이 있을 겁니다.
Navigation (Default)를 선택하고 진단할 Device와 categories를 선택한 후에 Analyze page load 버튼을 눌러보면 페이지가 새로고침되면서 페이지가 모두 로드될 때까지 체크해서 리포트를 줍니다.
그러면 이 리포트를 기반으로 하나씩 개선해 봅니다.
| 웹성능 최적화 하기
Protocol 최적화
HTTP1.1은 동시 Request 수가 제한이 되어있습니다. (크롬의 경우 최대 6개 연결 제공 - 병렬요청)
따라서 한 페이지에서 요청하는 리소스 수가 많다면 그만큼 느리게 되므로 1.1을 사용한다면 리퀘스트수를 줄이는 게 좀 더 빠른 로딩이 가능합니다.
하지만 요즘 웹페이지들은 한 페이지당 호출하는 리소스가 꽤 많아서 한계가 있습니다.
그래서 프로토콜을 HTTP/2로 변경해야 하는데 멀티플렉싱 기능으로 리소스가 많더라도 1.1보다 훨씬 빠른 로딩속도를 보여줍니다.
참고 : https://sw-ryu.tistory.com/m/83
리소스(js, css, img..) 크기 최소화
img가 화면상에 작은 영역만 보이는 콘텐츠가 불필요하게 큰 이미지로 바인딩된 경우나 이미지 퀄리티 때문에 과도한 용량을 잡아먹는 경우 등이 있습니다.
js나 css는 사실 img에 비해서는 용량 자체가 적으니 우선 이미지에만 신경 써주셔도 됩니다.
특히 블로그 글을 작성할 때 사진을 휴대폰으로 찍은 사진을 그대로 가져다가 쓴다거나 하면 큰 낭패를 보실 수 있습니다.
요즘은 블로그 툴들에서 이미지 업로드를 할 때 최적화해서 사이즈별로 최적화를 해주지만 그렇지 않은 경우들도 있으니 크기를 최적화해서 올리는 습관을 가지시면 좋습니다.
이미지 형식(webp..)을 최적화
thumbnail이나 포스트에 삽입하는 이미지의 형식은 webp로 변환해 줍니다.
webp는 무손실 압축 확장자라서 퀄리티는 유지한 상태로 더 작은 용량으로 제공해 줄 수 있기도 하고 구글이 개발한 포맷이기도 하니 구글 검색에도 가산점을 받을 수 있지 않을까 생각해 봅니다.
cdn서비스를 사용하고 계시다면 cdn에서 허용을 해주셔야 하고 MIME type도 추가해주셔야 합니다.
WebP 지원 브라우저 : https://caniuse.com/webp
캐시 최적화( cache-control, cdn, serviceworker.. )
이미지, js, css 같은 리소스에 대해서 캐시 최적화를 해주셔야 합니다.
자주 바뀌지 않는 리소스들은 캐시 유효시간을 최대한 길게 잡아 주셔야 합니다.
그리고 서버의 리전이나 부하를 생각해서 cdn서비스를 사용하시는 게 좋습니다.
캐시 컨트롤 하는 방법으로만 한 포스팅을 해야 할 만큼 방대하지만 여기서는 간단히만 적겠습니다.
defer, async 속성 적용
defer 브라우저는 defer 속성이 있는 스크립트를 ‘백그라운드’에서 다운로드합니다.
따라서 이 속성을 추가하면 스크립트를 다운로드하는 중에도 html 파싱이 멈추지 않습니다.
그리고 defer 스크립트 실행은 페이지 구성이 끝날 때까지 지연됩니다.
DOM이 준비된 후에 실행되는데 DOMContentLoaded 이벤트 발생 전에 실행되는 반면 async는 백그라운드에서 다운로드되지만 async 스크립트 실행 중에는 html파싱이 멈춥니다.
https://ko.javascript.info/script-async-defer
resource preload
현재 페이지에서 확실하게 사용하는 리소스들을 preload 합니다.
보통 font 파일을 미리 로드하는데 다른 리소스보다 먼저 로드하게 됩니다. ( FOIT, FOUT를 방지 - 폰트를 다운로드하기 전 글꼴이 표시가 안된다거나 대체 택스트로 랜더링 되는 현상 )
<link rel="preload" href="[파일경로]" as="font" type="font/woff" crossorigin>
https://web.dev/codelab-preload-web-fonts/
https://devs.vercel.app/webfont-foit-fout
domain preconnect
외부 도메인의 리소스를 참고하는 것을 브라우저에게 미리 알려 주는 역할을 합니다.
브라우저에서 필요한 소켓을 미리 설정할 수 있게 하기 때문에 DNS, TCP, TLS 왕복에 필요한 시간을 절약할 수 있습니다.
preconnect는 외부 도메인과 연결을 구축하기 때문에 많은 CPU 시간을 차지할 수 있습니다.
보안 연결의 경우 더 많은 시간을 차지할 수 있습니다.
10초 이내로 브라우저가 닫힌다면, 이전의 모든 연결 작업은 낭비되는 것이기 때문에 브라우저가 빨리 닫힐 수 있는 페이지에서는 preconnect를 사용하지 않는 것이 좋습니다.
<link rel="preconnect" href="[도메인]" crossorigin>
https://web.dev/optimize-lcp/? utm_source=lighthouse&utm_medium=lr#preload-important-resources
Reflow, Repaint
위에서도 잠깐 설명했지만 브라우저가 페이지를 그릴 때 가장 많은 리소스를 잡는 것 중에 하나가 리플로우, 리페인트입니다. 따라서 되도록이면 최소화하는 게 좋은데 그렇게 하기 위해서는 아래와 같이 처리해야 합니다.
- 애니메이션이 있는 엘리먼트는 주변 엘리먼트에 영향을 주지 않아야 합니다.
- 콘텐츠 사이즈 변경이 자주 일어나지 않아야 합니다.
- 이미지 요소에 width, height 가 명시 되면 좋습니다.
- 스켈레톤 UI를 적용하면 좋습니다.
Animation은 GPU
애니메이션은 되도록 cpu에 올리지 말고 gpu에 올려서 성능 최적화해야 합니다.
요즘은 pc들의 gpu 성능이 상당히 좋아져서 cpu와 좀 나눠서 작업을 할당하는 게 좋습니다.
보통 페이지 첫 로딩 때나 reflow가 일어날 때 cpu 사용률이 확 뛰게 되는데 생각보다 많이 사용합니다.
따라서 gpu 쪽으로 뺄 수 있는 것들은 되도록 빼는 게 좋은데 무턱대고 다 빼면 오히려 성능이 저하하니 적당히 합의점을 찾아 gpu에 올리면 됩니다. (그래픽카드 성능차이)
gpu로 올릴 수 있는 조건
- CSS 3D Transform(translate3 d, preserve-3d, translateZ, backface-visibility 등)
- CSS Animation, CSS Filter 적용
- 자식 엘리먼트가 레이어로 구성된 부모 레이어
- 형제 엘리먼트가 상대적으로 낮은 Z-Index로 구성된 해당 엘리먼트
- Video, Canvas 엘리먼트
- will-change: transform
여기에 최종적으로 layout reflow 가 발생하지 않아야 합니다.
CPU와 GPU사용률을 보려면 크롬 개발자 보드에서 보실 수 있습니다.
과도한 DOM 크기 방지
코드상에 js 렉터(querySelector, getElementById..)를 통한 참조를 저장하고 있을 수 있어 메모리 용량 과부하가 걸릴 수 있습니다.
노드의 위치와 스타일을 지속적으로 다시 계산해야 해서 dom크기가 렌더링 속도에 크게 영향을 미치기 때문에 html 코드를 짤 때 간결하고 불필요한 코드를 제거할 수 있어야 합니다.
시멘틱 한 코드작성에 대해서는 따로 포스팅을 하겠습니다.
body에 노드가 800개부터 경고, 1400개 이상부터 오류 발생하는데 특히 한국은 화려한 페이지를 선호하는 경향이 있어 거의 이 항목은 걸린다고 봐야 합니다.
콘텐츠가 많으면 어쩔 수 없는 증상이라 컴포넌트 작업 때 최대한 불필요한 태그 지양할 수밖에 없습니다.
막대한 네트워크 페이로드 줄이기
전체 네트워크 요청이 페이지당 1600KB 까지가 적정 요청이고 최대 5000KB를 초과하지 않아야 합니다.
해결 방법으로는 압축, 이미지 경량화, 소스 minify, js 번들 크기 최소화를 위한 코드분할 적용등이 있습니다.
https://web.dev/route-level-code-splitting-in-angular/
FCP (First Contentful Paint)
사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점을 표시하기 때문에 로드 속도가 중요합니다.
1.8초 이내에 떠야 점수가 좋습니다. 중요한 콘텐츠가 위로 올라오면 좋지만 화면을 기획할 때부터 이 부분을 생각해서 부하가 적어 빨리 로드할 수 있는 콘텐츠를 위로 올리는 것도 한 방법입니다.
LCP (Largest Contentful Paint)
뷰포트에서 가장 큰 콘텐츠 요소가 렌더링 되는 시점을 측정합니다.
이 항목은 2.5초 안에 들어와야 빠름으로 표기해 줍니다.
보통 큰 썸네일이나 배너 영역들이 많이 걸리게 되는데 이미지 최적화는 물로 영역이 큰 콘텐츠의 api를 먼저 호출한다거나 위에서 말했듯이 빨리 로드할 수 있는 콘텐츠를 화면 상단에 배치하는 것도 방법입니다.
TTI (Time to Interactive)
완전히 상호 작용 가능하게 되는 데 걸리는 시간을 측정합니다.
상호작용이 가능하다는 말은 사실상 페이지가 거의 로드되어야 한다고 봐야 합니다.
3.8초 안이면 빠름이라고 명시는 하고 있지만 실제 툴을 돌려서 결과를 보면 측정하는 것과 살짝 다른 듯합니다.
개선 방법은 메인 스레드 작업을 최소화하고 js 실행 시간 단축해야 하는데 빌드할 때 chunk 파일을 잘 쪼개고 첫 로딩 때 부하가 걸리는 작업들을 다른 스레드로 뺀다거나(worker) 코드를 개선하는 방법들이 있습니다.
https://web.dev/interactive/
TBT (Total Blocking Time)
총 차단 시간 > 메인 스레드가 입력 응답을 막을 만큼 오래 차단되었을 때의 총시간을 측정합니다. (FCP와 TTI 사이 시간을 측정)
http1.1 인경우에 동시 호출할 수 있는 제한이 있기 때문에 그 뒤 호출들이 대기 상태로 빠지면서 이 시간이 급격하게 증가합니다.
가장 좋은 해결방안은 프로토콜 업데이트와 도메인 커넥션에서 잡아먹는 시간을 줄이는 domain preload 등의 작업을 진행하시면 됩니다.
TTFB (Time to First Byte)
리소스에 대한 요청과 응답의 첫 번째 바이트가 도착하기 시작하는 시점 사이의 시간을 측정하는 메트릭입니다.
보통 백엔드 대기시간을 줄이면 TTFB가 낮아집니다.
https://web.dev/articles/ttfb? hl=ko
CLS (Cumulative Layout Shift)
CLS항목은 쉽게 말해 콘텐츠 밀림 현상이 있으니 수정하라는 말입니다.
로딩 중에 콘텐츠가 밀리게 되면 사용자 경험도 좋지 않고 렌더링 비용 중 상당한 부분을 차지하는 layout reflow / repaint / recalcs 가 일어나면서 성능에 악영향을 미칩니다.
보통 api를 당겨온 이후에 데이터를 화면에 그리면서 컨텐츠가 밀리게 되는데 이걸 방지하기 위해서는 콘텐츠의 영역을 잡아두는 스켈레톤 UI를 적용하는 게 도움이 됩니다.
또, 특히 많이 걸리는 게 이미 지므로 이미지에 사이즈를 넣는 것도 한 방법이지만 반응형에는 어울리지 않습니다.
https://web.dev/articles/cls? hl=ko
| 마무리
오늘은 이렇게 웹 성능 최적화에 대해서 알아봤는데요.
성능을 측정하는 툴을 어떻게 사용하느냐에 따라서 많은 도움이 됩니다.
빨간색으로 경고로 뜨는 항목들은 보통 아래 링크들이 있으니 찾아 들어가 하나하나씩 수정하면서 성능 측정을 해보는 수밖에 없죠.
고난의 시간입니다. 🫥
하지만 이 성능개선이 구글의 SEO 정책에서도 언급되어 있을 만큼 엄청 중요한 작업이니 오래 걸리고 지루하더라도 하나씩 고쳐나가야 합니다.
읽어주셔서 감사합니다. ^___^
'IT > 개발' 카테고리의 다른 글
| 웹사이트 속도 향상을 위한 트리쉐이킹 활용법 (67) | 2024.03.28 |
|---|---|
| 프론트 개발자라면 꼭 알아야 할 package-lock.json의 비밀! (2) | 2024.02.14 |
| IntelliJ Test Case Setting (2) | 2024.01.25 |
| Vue3의 상태관리자로 Pinia를 사용해 봅시다. (0) | 2024.01.15 |
| Service Worker 적용해 보기 (0) | 2024.01.13 |
