TECH CONCERT: FRONT END 2019 - 오늘부터 나도 FE 성능분석가

Urther·2022년 7월 13일
0
Youtube- TECH CONCERT: FRONT END 2019 - 오늘부터 나도 FE 성능분석가

그런 말을 들은 적이 있다. 프론트엔드에 쉽게 도전하지만 꽤나 까다로운 직무라고. 그 이유는 백엔드가 성능을 개선한다면 눈에 확 띄지만, 프론트엔드가 성능을 개선한다고 하면 눈에 띄지 않을 가능성이 있다. 개발 관련 유투브에서 들었는데 기억이 나지 않는다.

4G 5G를 앞다투는 시대에 low한 네트워크 환경으로 접속하는 사람이 있을까? 싶지만, 나는 데이터를 다쓰면 무료 3G로 변환되는데 그 때 웹페이지가 늦게 구동되면 새로고침을 무한대로 한다. 나보다 더 low 한 네트워크 환경에서 접속할 일이 정말 정말 없을까? 아니라고 생각하기 때문에 위와 같은 유투브를 추천 받았다. 그래서 이 글은 그저 유투브를 요약한 글이다.

백엔드의 성능 분석가와 프론트의 성능 분석가

백엔드의 성능 분석가는 서버가 얼마나 많은 요청을 처리할 수 있는지에 대한 부분을 고민한다.

백엔드가 트래픽에 대한 내용을 고민한다면, 프론트엔드는 입력한 내용을 어떻게 빠르게 반응할 수 있는가이다. 반응성과 관련된 내용에 대해 고민한다.

LAI (Loading and Interaction)

에라이로 발음해주셔서 까먹지 않을 것 같다..

1. 초기 로딩 속도 : "얼마나 빠르게 페이지를 볼 수 있나요?"
2. 인터렉션 속도 : "스크롤 버벅여요" "애니메이션이 두둑 끊겨요"

그래서, 성능 개선은 어떻게?

흔히 '어디가 느리대' 라고해서 그 부분만 접근하면 문제의 본질을 파악하기 어렵다.

  1. 대상 정하기 ( 나무를 보기보다는 숲을 보아야 한다.)
  • 서비스에서 가장 많이 사용하는 화면은 무엇인가?
  • 서비스에서 사용자에게 가치 있는 화면은 무엇인가?
  1. 개선 프로세스
    1) 측정 : 어디가 느린곳인지 측정한다
    2) 분석 : 이것을 가지고 분석한다.
    3) 최적화

원하는 속도가 나올 때까지 아래의 3 단계를 반복한다.

초기 로딩 속도 개선

먼저, 웹서비스가 어떻게 돌아가는지에 대한 이해가 필요하다.

  1. 주소를 입력하면 request 요청이 간다.
  2. 서버에서 response로 html을 string 형태로 클라이언트에 보낸다.
  3. 서버에서 응답이 온 것으로 브라우저는 화면에 그린다.

로딩 과정은 waterfall 차트를 어떻게 개선하느냐이다. waterfall은 network에서 확인할 수 있다. waterfall의 높이, 폭, 간격을 줄인다면 성능이 개선된다.

1. waterfall의 높이 줄이기

waterfall의 높이를 줄이는 방법은 request 수를 줄이는 것이다. request를 줄여야하는 까닭은 브라우저는 호스트당 연결할 수 있는 갯수가 정해져 있기 때문이다. connection 수가 초과한다면 다른 요청은 브라우저에서 대기하게 된다.

  1. js, css 파일을 merge해서 하나의 파일로 가져가는 방법이다. (webpack과 같은 번들링)
  2. image sprite 방법으로 요청하는 수를 줄인다.

위와 같은 방법은 가장 기본적인 방법이고, 가장 효과적인 방법은 불필요한 자원들을 요청하지 않는 것이다.따라서 아래와 같은 요청을 하는지 체크한다.

  • 실수로 요청한 자원이 있는가?
  • 초기 로딩시 필요 없는 JS (다른 페이지에서 사용하는 JS는 다운 받지 않아도 된다.)
  • 뷰포트 바깥에 있는 이미지 제거 ( ex : 캐러셀이 될 수 있다. 로딩 이후에 올리거나, 캐러셀을 넘기는 행동을 할 때 이미지를 불러오는 방법을 사용하는 것이 큰 도움이 된다.)

2. 폭 줄이는 방법

네이버는 waterfall을 볼 것이 없어서 블로그의 waterfall을 보았다.(캡쳐에는 intial connection은 없다.)

1 ) initial connection

초기 connection 갯수는 웹 브라우저단에서 할 수 있는게 없다. 기본 http 프로토콜을 변경한다. HTTP2.0은 connection 하나 당 여러개의 스트림을 보낼 수 있기 때문에 HTTP2.0 을 사용해준다.

2 ) Waiting for server response

이것이 느리면 서버에서 느린 것이다.

3 ) Content Download

프론트엔드에서 가장 중요한 파트이다. 이것이 느린 까닭은 2가지 원인이 있다. 컨텐츠 크기가 큰 경우이거나, 네트워크 속도가 느리거나.

  • JS 혹은 CSS 콘텐츠 크기 줄이기
    - 위에서 언급한 번들링 뿐만 아니라, gzip(코드의 난독화, 주석제거 등의 작업을 해줌)을 이용해준다.
  • 이미지 정보

    이미지 크기에 대한 부분이 가장 중요하다. 일단 큰 이미지는 네트워크 트래픽만 많이 먹는 것이 아니라, 브라우저 화면에 그리기까지의 많은 비용을 요구한다. (이미지 데이터를 RGB로 변경하는데 많은 비용이 들기 때문에) 그러나, Retina 이상의 PC에서 볼 때 크기가 작은 것은 거슬릴 수 있다. 그래서 srcset, source를 이용하는 방법은 비현실적이다.

3. 간격 줄이기

  • <head> 태그에서 css와 필수 JS만 넣는다.
  • JS는 body 태그 마지막에 넣는다. 중간 중간에 JS를 넣지 않는다.
  • preload라는 속성을 이용하여 CSS와 폰트, 이미지가 함께 로딩될 수 있도록 한다. (상대적으로 로딩이 빨라질 수 있다.)
profile
이전해요 ☘️ https://mei-zy.tistory.com

0개의 댓글