웹 성능 진단하기

들어가며

강의자료 초반에 있던 클라이언트-서버 구조도인데 성능과 밀접한 관련이 있는 cache를 잘 시각화 해둔 것 같다

웹 성능 측정하기

강의에서 성능을 측정해주는 사이트 를 소개해주고 있었는데, 여기서 여러가지를 측정해볼 수 있었다. 카테고리별로 점수를 매겨서 학점처럼 보여준다.

• First Byte Time : 웹 서버에서 받은 컨텐츠의 첫 번째 바이트가 얼마만에 도착했는가?

• Keep-Alive Enabled : TCP 연결을 재사용하기 위한 Keep-Alive 설정이 되어 있는가?

• Compress Transfer : 스크립트 파일이 Content-Encoding으로 압축되어 있는가?

• Compress Image : 이미지를 압축했는가?

• Cache Static Content : 정적 파일이 캐싱 설정이 되어 있는가?

웹 성능 예산

웹 성능 예산 이란 쉽게 말해서 ‘성능을 위해서 최소한 이 예산은 넘지말자’ 라는 맥락에서 여러 지표들을 나타낸 것이다. 지표들은 정량/시간/성능 이렇게 세 카테고리로 분류될 수 있다. 웹 성능 예산에 대해 잘 정리된 브런치 가 있어 따로 정리하진 않겠다.

성능 부분에 관해서는 구글에서 Page Speed Insight 라는 것을 제공하고 있다. 여기서 원하는 웹 사이트의 성능을 점검해볼 수 있다.

테스트로 네이버를 돌려 봤는데 점수가 너무 낮다

개선을 어떻게 해야할지 전략까지 짜준다

위 링크된 브런치 내용중 마지막 부분이 참 재밌었는데, 저자가 개발자인데도 기획자 입장에서 생각해봤다는 것이 참 배울만 했다. 기획자 입장에서도 단순히 ‘좀 느린 것 같은데’ 라고 개발자에게 말하면 개발자마다 받아들이는 것이 다르겠지만 대부분 그런 발언에 대해 굉장히 방어적일 것이라 생각한다. 나는 브라우저 기반으로 서비스를 제공하는 회사에 다녀본 적이 없어서 웹 성능에 대해서는 크게 고민해본 적이 없어서 저런 상황이 자주 발생하는 것인지는 모르겠다.

하지만 저러한 기획자의 불만(?)이 빈도가 높게 발생하는 것이라면 적어도 성능 예산의 개념에 근거하여 시간과 성능스코어 두 가지로는 숫자를 가지고 자기주장을 할 수 있을 것 같다. 반대로 개발자도 막연하게 느리다고 피드백을 받는다면 숫자를 들어서 최소한의 기준을 충족하고 있다고 커뮤니케이션 할 수 있을 것 같고 애초에 개발 단계에서부터 성능 예산을 고려하여 개발하는 것이 좋겠다 싶다.

웹 성능 예산은 아래 예시와 같이, 정량 / 시간 / 규칙 기반으로 산정할 수 있어요. 성능 목표에는 정답이 없지만, 3초의 법칙 (3초 안에 로딩되지 않으면 53%의 사용자가 떠나고 로딩 시간이 길어질수록 사용자 이탈률이 늘어남)이 있듯, 서비스의 성능 목표를 두는 것이 필요합니다.

• 메인 페이지의 모든 오브젝트 파일 크기는 10MB 미만으로 제한한다.

• 모든 웹 페이지의 각 페이지 내 포함된 자바스크립트 크기는 1MB를 넘지 않아야 한다.

• 검색 페이지에는 2MB 미만의 이미지가 포함되어야합니다.

• LTE 환경에서의 모바일 기기의 Time to Interactive는 5초 미만이어야 한다.

• Dom Content Loaded는 10초, First Meaningful Paint는 15초 미만이어야 한다.

• Lighthouse 성능 감사에서 80 점 이상이어야한다.