웹 성능 진단하기
Last updated
Last updated
강의자료 초반에 있던 클라이언트-서버 구조도인데 성능과 밀접한 관련이 있는 cache를 잘 시각화 해둔 것 같다
First Byte Time : 웹 서버에서 받은 컨텐츠의 첫 번째 바이트가 얼마만에 도착했는가?
Keep-Alive Enabled : TCP 연결을 재사용하기 위한 Keep-Alive 설정이 되어 있는가?
Compress Transfer : 스크립트 파일이 Content-Encoding으로 압축되어 있는가?
Compress Image : 이미지를 압축했는가?
Cache Static Content : 정적 파일이 캐싱 설정이 되어 있는가?
테스트로 네이버를 돌려 봤는데 점수가 너무 낮다
개선을 어떻게 해야할지 전략까지 짜준다
위 링크된 브런치 내용중 마지막 부분이 참 재밌었는데, 저자가 개발자인데도 기획자 입장에서 생각해봤다는 것이 참 배울만 했다. 기획자 입장에서도 단순히 ‘좀 느린 것 같은데’ 라고 개발자에게 말하면 개발자마다 받아들이는 것이 다르겠지만 대부분 그런 발언에 대해 굉장히 방어적일 것이라 생각한다. 나는 브라우저 기반으로 서비스를 제공하는 회사에 다녀본 적이 없어서 웹 성능에 대해서는 크게 고민해본 적이 없어서 저런 상황이 자주 발생하는 것인지는 모르겠다.
하지만 저러한 기획자의 불만(?)이 빈도가 높게 발생하는 것이라면 적어도 성능 예산의 개념에 근거하여 시간과 성능스코어 두 가지로는 숫자를 가지고 자기주장을 할 수 있을 것 같다. 반대로 개발자도 막연하게 느리다고 피드백을 받는다면 숫자를 들어서 최소한의 기준을 충족하고 있다고 커뮤니케이션 할 수 있을 것 같고 애초에 개발 단계에서부터 성능 예산을 고려하여 개발하는 것이 좋겠다 싶다.
웹 성능 예산은 아래 예시와 같이, 정량 / 시간 / 규칙 기반으로 산정할 수 있어요. 성능 목표에는 정답이 없지만, 3초의 법칙 (3초 안에 로딩되지 않으면 53%의 사용자가 떠나고 로딩 시간이 길어질수록 사용자 이탈률이 늘어남)이 있듯, 서비스의 성능 목표를 두는 것이 필요합니다.
메인 페이지의 모든 오브젝트 파일 크기는 10MB 미만으로 제한한다.
모든 웹 페이지의 각 페이지 내 포함된 자바스크립트 크기는 1MB를 넘지 않아야 한다.
검색 페이지에는 2MB 미만의 이미지가 포함되어야합니다.
LTE 환경에서의 모바일 기기의 Time to Interactive는 5초 미만이어야 한다.
Dom Content Loaded는 10초, First Meaningful Paint는 15초 미만이어야 한다.
Lighthouse 성능 감사에서 80 점 이상이어야한다.
강의에서 를 소개해주고 있었는데, 여기서 여러가지를 측정해볼 수 있었다. 카테고리별로 점수를 매겨서 학점처럼 보여준다.
웹 성능 예산 이란 쉽게 말해서 ‘성능을 위해서 최소한 이 예산은 넘지말자’ 라는 맥락에서 여러 지표들을 나타낸 것이다. 지표들은 정량/시간/성능 이렇게 세 카테고리로 분류될 수 있다. 가 있어 따로 정리하진 않겠다.
성능 부분에 관해서는 구글에서 라는 것을 제공하고 있다. 여기서 원하는 웹 사이트의 성능을 점검해볼 수 있다.
