그런 말을 들은 적이 있다. 프론트엔드에 쉽게 도전하지만 꽤나 까다로운 직무라고. 그 이유는 백엔드가 성능을 개선한다면 눈에 확 띄지만, 프론트엔드가 성능을 개선한다고 하면 눈에 띄지 않을 가능성이 있다. 개발 관련 유투브에서 들었는데 기억이 나지 않는다.
4G 5G를 앞다투는 시대에 low한 네트워크 환경으로 접속하는 사람이 있을까? 싶지만, 나는 데이터를 다쓰면 무료 3G로 변환되는데 그 때 웹페이지가 늦게 구동되면 새로고침을 무한대로 한다. 나보다 더 low 한 네트워크 환경에서 접속할 일이 정말 정말 없을까? 아니라고 생각하기 때문에 위와 같은 유투브를 추천 받았다. 그래서 이 글은 그저 유투브를 요약한 글이다.
백엔드의 성능 분석가는 서버가 얼마나 많은 요청을 처리할 수 있는지에 대한 부분을 고민한다.
백엔드가 트래픽에 대한 내용을 고민한다면, 프론트엔드는 입력한 내용을 어떻게 빠르게 반응할 수 있는가이다. 반응성과 관련된 내용에 대해 고민한다.
에라이로 발음해주셔서 까먹지 않을 것 같다..
1. 초기 로딩 속도 : "얼마나 빠르게 페이지를 볼 수 있나요?"
2. 인터렉션 속도 : "스크롤 버벅여요" "애니메이션이 두둑 끊겨요"
흔히 '어디가 느리대' 라고해서 그 부분만 접근하면 문제의 본질을 파악하기 어렵다.
원하는 속도가 나올 때까지 아래의 3 단계를 반복한다.
먼저, 웹서비스가 어떻게 돌아가는지에 대한 이해가 필요하다.
- 주소를 입력하면 request 요청이 간다.
- 서버에서 response로 html을 string 형태로 클라이언트에 보낸다.
- 서버에서 응답이 온 것으로 브라우저는 화면에 그린다.
로딩 과정은 waterfall 차트를 어떻게 개선하느냐이다. waterfall은 network에서 확인할 수 있다. waterfall의 높이, 폭, 간격을 줄인다면 성능이 개선된다.
waterfall의 높이를 줄이는 방법은 request 수를 줄이는 것이다. request를 줄여야하는 까닭은 브라우저는 호스트당 연결할 수 있는 갯수가 정해져 있기 때문이다. connection 수가 초과한다면 다른 요청은 브라우저에서 대기하게 된다.
위와 같은 방법은 가장 기본적인 방법이고, 가장 효과적인 방법은 불필요한 자원들을 요청하지 않는 것이다.따라서 아래와 같은 요청을 하는지 체크한다.
네이버는 waterfall을 볼 것이 없어서 블로그의 waterfall을 보았다.(캡쳐에는 intial connection은 없다.)
초기 connection 갯수는 웹 브라우저단에서 할 수 있는게 없다. 기본 http 프로토콜을 변경한다. HTTP2.0은 connection 하나 당 여러개의 스트림을 보낼 수 있기 때문에 HTTP2.0 을 사용해준다.
이것이 느리면 서버에서 느린 것이다.
프론트엔드에서 가장 중요한 파트이다. 이것이 느린 까닭은 2가지 원인이 있다. 컨텐츠 크기가 큰 경우이거나, 네트워크 속도가 느리거나.
이미지 크기에 대한 부분이 가장 중요하다. 일단 큰 이미지는 네트워크 트래픽만 많이 먹는 것이 아니라, 브라우저 화면에 그리기까지의 많은 비용을 요구한다. (이미지 데이터를 RGB로 변경하는데 많은 비용이 들기 때문에) 그러나, Retina 이상의 PC에서 볼 때 크기가 작은 것은 거슬릴 수 있다. 그래서 srcset, source를 이용하는 방법은 비현실적이다.
<head>
태그에서 css와 필수 JS만 넣는다.