프론트엔드 개발자로 일하게 된지 반 년이 넘었다. 서비스를 만들고 개발하고는 있지만, 돌아가게 하는 정도로 개발하는 것과 거기서 그치지 않고 빠르게 돌아가도록 하는 것은 보이는 것 이상의 차이가 있다고 생각한다. 지금까지 배운 최적화 방식에 대해 기록하기 전에, 프론트엔드 개발자가 왜 성능 최적화를 할 수 있어야 하는지에 대해 고찰해 보자.
웹 성능 최적화, 왜 해야 할까?
우리 회사에서는 MAU가 천만 단위인 서비스를 운영하고 있다(내가 개발하는 서비스는 다른 서비스지만). 물론 웹에서만 서비스되는 기능은 아니고 앱을 통해서도 접속할 수 있지만, 웹으로 이용하는 사람도 적지 않을 것이라고 생각한다. 회사에서 일하기 이전부터 해당 시스템에 가입해서 이용해 왔던 나도 역시 웹 버전으로 많이 이용한다.
그러면, 서비스를 이용하는 사람이 되어 한번 생각해 보자. 아무리 네트워크가 빠른 환경에서 좋은 컴퓨터를 사용하더라도 사이트에서 무언가를 클릭할 때마다 1~2초씩은 기다려야 하는 서비스와, 재깍재깍 반응하는 서비스. 웹 사이트를 떠나서 제공하는 서비스가 유사한 곳이라면 당연히 모두가 후자를 사용하지 않을까?
간단히 생각하면, 웹 성능의 저하는 이용자의 이탈로 이어진다는 것이다. 그리고 이용자의 이탈은 수익의 저하를 말한다. 그 어떤 회사에서 제공하는 그 어떤 서비스도 이용자가 이탈하는 것을 원하지는 않을 것이다. 무언가 어두운 어른의 사정이 있지 않은 이상...
또, 현실적인 이유를 한 가지 더 생각해 보자. 우리는 프론트엔드 개발자니까 이번엔 개발자의 입장에서 생각해 보도록 하자. 답은 단순하다. 개발자로서의 경쟁력을 갖출 수 있다는 것이다. 더 쉽게 말하면 몸값을 올릴 수 있다고 해도 되는걸까? 솔직히 프론트엔드 개발, 진입 장벽도 낮고 이 바닥 몇년 동안 뭐 개발 학원이니 하면서 붐이 일어나서 양산형 개발자가 우후죽순 나온 마당에 경쟁력을 갖추는 건 정말 중요하다고 생각한다.
회사의 매출과 직결되는 스킬을 가지고 있는 개발자라는데, 매력적인 요소가 되지 않을까 싶다.
웹 성능 측정을 해 보자
웹 성능 최적화에 진심인 구글에서는 PageSpeed Insights 라는 이름으로 웹사이트의 성능을 측정할 수 있는 서비스를 운영하고 있다. 해당 서비스는 다양한 지표를 통해 웹 사이트의 성능을 측정하고 그것을 수치화해서 성능이 좋은지 아닌지를 표시해 준다.
측정해 본 김에 각각의 지표가 무엇을 나타내는지 한번 알아보도록 하자.
- LCP - 페이지가 로딩을 시작하고 사이즈가 가장 큰 콘텐츠가 표시되는 데까지 걸리는 시간
- FID - 페이지와 사용자의 첫 상호작용이 시작해서 핸들러가 그것을 처리할 수 있는 데까지 걸리는 시간
- CLS - 페이지가 로드되고 레이아웃이 변경되는 것을 수치화한 것
- FCP - 페이지가 로딩을 시작하고 첫 콘텐츠가 표시되는 데까지 걸리는 시간
- INP - 사용자가 페이지와 상호작용하였을 때 반응하는 속도
- TTFB - 페이지가 서버로 데이터를 요청하고 첫 바이트를 받는 데까지 걸리는 시간
위 세 가지인 LCP, FID, CLS는 웹 사이트 성능 측정에 있어 중점적으로 검사되는 항목이므로 아주 중요하다고 할 수 있다. 특히, CLS의 경우 해당 수치가 높은 사이트라면...
이런 짜증나는 상황을 유발할 수도 있다.
INP같은 경우에는 분명 내가 처음 이런 지표를 측정해 봤을 때 이 자리에 표시되어 있는 건 INP가 아니라 FID(First Input Delay)였는데, 어느새 바뀌어 있어서 알아 보니 FID와 비슷하지만 좀 더 신뢰할만한 지표라고 해서 조만간 INP가 FID를 대체할 것이라고 한다. FID는 첫 상호작용만 검사하는 데에 비해 INP는 모든 상호작용을 검사해서 가장 느린 속도값을 측정한다고 한다. 또, TTFB의 경우 서버의 성능과도 상관이 있다.
그러면 완성된 서비스에서만 성능을 측정할 수 있는가? 당연히 그건 아니고, 우리가 개발 중인 사이트를 로컬 환경에서 돌려 가면서 성능을 측정할 경우 개발자 도구의 기능을 이용하면 된다. 나는 프론트엔드 개발을 할 때에는 Chrome을 사용하기 때문에 Chrome 기준에서 설명을 하자면, 성능 측정은 개발자 도구의 메뉴 중에서 Lighthouse라는 기능이 행하게 된다.
참고로, 여러분들에게도 프론트엔드 개발을 할 때에는 Chrome 기준에서 개발을 하는 것을 추천한다. 나도 단순 브라우징에는 10년 이상 Firefox만을 사용한 골수 Firefox 유저지만 많은 사람들이 Chrome 또는 Chromium 기반의 브라우저를 사용하고 있으니까 그냥 Chrome을 일단 제일의 기준으로 삼고 개발하고 있다. 나만 사용할 서비스를 개발하는 것도 아니니까... 뭣도 모르고 처음 Firefox로 개발할 때, 첫 프로젝트에서 Firefox에서는 없었던 버그가 Chrome에서 생겨서 QA에서 잡힌 기억이 있다.
웹 성능 최적화의 분류
이대로 글을 마치면 뭔가 시원찮아지니까, 웹 성능 최적화에는 어떤 것들이 있는지 살짝만 먼저 엿보도록 하자.
웹 성능 최적화는 크게 두 가지로 나눌 수 있다. 첫번째는 로딩 성능이고, 두번째는 렌더링 성능이다. 로딩 성능은 HTML, CSS, JS나 이미지, 비디오 등의 리소스를 불러오는 데에 걸리는 성능이고, 렌더링 성능은 불러온 리소스를 화면에 그리는 데에 걸리는 성능이다.
로딩 성능 최적화에는 다음과 같은 것들이 있다.
- 이미지 사이즈 최적화
- 코드 스플릿
- 텍스트 압축
- Lazy loading
- Preloading
렌더링 성능 최적화에는 다음과 같은 것들이 있다.
- 보틀넥 코드 최적화
- 애니메이션 최적화
다음 포스트에서는 이러한 최적화를 하기 위해 알아야 할 것이 무엇이 있고, 어떻게 진행하는지에 대해 차근차근 알아 보도록 하자.
'공부 > 기타' 카테고리의 다른 글
TypeScript + ESLint + Prettier 설정하기 (0) | 2022.03.13 |
---|---|
macOS에서 VSCode로 C++ PS 환경 구축하기 (0) | 2021.12.25 |
Ubuntu Server 20.04.1 한글 깨짐 현상 (0) | 2021.03.12 |