Web Performance Optimization 1 | 웹 성능 최적화 1
Edit on GitHub성능이 곧 사용자 경험이다.
페이지 로딩 시간은 검색엔진의 검색 결과에도 영향을 미치는데, 보통 속도가 빠른 사이트가 느린 사이트보다 검색 결과 목록의 상위에 표시된다.
모바일 기기에서 웹 페이지를 로딩하는데 시간이 더 오래 걸리는 첫 번쨰 이유는 모바일 기기의 데이터 전송 방식에서 찾을 수 있다.
모바일 기기가 데이터를 송수신하려면 네트워크와 무선 채널을 연결해야 한다.
무선 기지국과 모바일 기기를 연결하기 위한 협상과정을 거져 데이터를 전송할 수 있게 되면 통신사는 무선 기지국으로 송신된 데이터를 통신사 내부망을 거쳐 인터넷에 연결한다.
이 일련의 단계로 대기 시간이 늘어난다.
무선 채널을 통해 송수신하는 데이터가 없어 타임아웃이 발생하면 채널이 유휴 상태에 빠질 수도 있다.
그 후 데이터를 다시 송수신하면 새로운 채널이 만들어지고 앞의 모든 과정을 처음부터 다시 시작하므로 잠재적으로 웹 페이지를 로딩하는 시간에 큰 악영향을 미치게 된다.
페이지 속도의 원리
브라우저가 콘텐츠를 렌더링하는 방법
사용자가 사이트의 URL을 브라우저의 주소창에 입력한 직후부터 사이트의 디자인을 화면에 보여주는 순간까지 사용자의 브라우저와 서버는 서로 필요한 데이터를 교환한다.
먼저 브라우저가 데이터를 얻기 위해 서버에 요청을 보낸다.
이렇게 브라우저가 새로운 도메인을 요청에 보내려면 콘텐츠가 있는 서버를 먼저 찾아야 하는데 이 과정을 DNS 조회라고 한다.
DNS 조회를 통해 웹 호스팅이 인터넷의 어디에서 이루어지는지 검색한 후 검색된 서버로 사용자가 보낸 콘텐츠 요청이 도달한다.
브라우저는 일정 기간동안 이 위치를 기억하는데 매 요청마다 DNS 조회를 하는 시간 낭비가 생기지는 않는다.
일단 서버가 사용자의 브라우저로부터 첫 요청을 받으면 서버는 이 요청을 확인한 후 페이지를 렌더링하기 위해 브라우저가 찾는 콘텐츠의 위치를 확인한다.
그 다음 서버는 이미지나 CSS, HTML 혹은 다른 종류의 콘텐츠를 브라우저의 요청에 대한 결과로 반환한다.
브라우저는 서버가 반환한 자원을 다운받은 후 사용자를 위해 화면에 렌더링한다.
브라우저가 서버로부터 받은 콘텐츠의 첫 번째 바이트 도착 시간을 TTFB(Time to First Byte)라 한다.
TTFB는 사이트의 백엔드가 얼마나 빨리 요청을 처리한후 콘텐츠를 반환했는지 측정하는데 유용하다.
하지만 브라우저가 서버의 응답을 콘텐츠의 첫 바이트를 받자마자 사용자에게 화면을 표시할 수 있는 것은 아니다.
프론트엔드에서 페이지의 콘텐츠를 모두 다운받은 후 렌더링을 해야 하는데 여기서 시간이 추가로 걸리기 때문이다.
게다가 어떤 파일들을 브라우저가 쉽게 처리한 후 렌더링까지 할 수도 있지만 블로킹 자바스크립트 처럼 사용자의 브라우저가 추가적인 콘텐츠를 렌더링하기 전까지는 처리할 수 없는 것도 있다.
브라우저는 보통 웹 페이즈를 렌더링하는 시간을 줄이기 위해 서버에 보내는 콘텐츠 요청을 병렬로 처리한다.
요청
웹 페이지 구성에 필요한 콘텐츠를 요청할 떄 크기와 횟수를 최적화하면 사이트의 페이지 로딩 시간이 엄청나게 달라질 것이다.
요청하는 콘텐츠 조각의 크기가 커지면 다운받는 시간과 브라우저에서 처리하는 시간 그리고 페이지에서 보여주는 시간도 당연히 길어진다.
또한 페이지를 렌더링하는데 필요한 콘텐츠 중 독립적인 조각이 많다면 페이지를 완전히 로딩하는데 더 많은 시간이 걸린다.
그러므로 사이트를 로딩하는 시간을 줄이려면 화면을 그리는데 필요한 이미지, CSS, 자바스크립트 파일 등의 개수뿐 아니라 크기까지 줄여야한다.
연결
페이지를 로딩하는 데 필요한 요청의 수와 브라우저가 콘텐츠를 가져오기 위해 만드는 연결의 수는 서로 다를 수 있다.
각 연결마다 도메인을 찾기 위한 DNS 조회, 초기접속 부분이 있다.
만약 자원들이 HTTPS를 통해 제공된다면 그 자원들을 가져오기 전에 SSL 협상이 포함될 수도 있다.
브라우저가 서버와의 연결을 유지하고 다른 자원 요청을 위해 연결을 재사용하는 것을 지속 연결이라고 부른다.
페이지 크기
페이지 로딩에 필요한 HTML이나 이미지, 그 밖에 다른 콘텐츠 모두 총 페이지 로딩 시간에 영향을 준다.
일반적을 페이지를 표시하는데 필요한 콘텐츠의 양이 늘어날수록 사용자가 페이지를 로딩하는데 걸리는 시간도 길어지므로 페이지에 포함된 콘텐츠의 양은 적을수록 좋다.
체감 성능
중요 렌더링 경로
페이지를 불러올떄 브라우저는 문서 객체 모델이라 불리는 DOM을 만드는 것부터 시작한다.
사용자의 브라우저는 웹 서버에서 HTML을 받아 파싱한다.
이 과정은 바이트를 문자로 문자열을 <body>와 같은 토큰으로, 토큰을 프로퍼티와 규칙을 가진 객체로 만들고 최종적으로 이 객채들을 서로 연결하면서 데이터 구조를 만드는 순서로 진행된다.
이를 통해 페이지를 표시하기 위해 브라우저가 앞으로 처리할 모든 페이지 작업에 필요한 DOM 트리가 만들어진다.
브라우저가 HTML을 파싱하는 과정에서 스타일시트를 만나면 브라우저는 모든 작업을 일시 중단하고 서버에 파일을 요청한다.
브라우저가 파일을 받으면 앞에서 한 작업과 유사한 작업을 반복한다.
바이트가 문자로 문자열이 토큰으로 토큰이 객체가 되고 객체가 트리 구조로 연결되고 마지막으로 CSS의 객체 모델인 CSSOM으로 생성 된다.
다음으로 브라우저는 DOM과 CSSOM을 결합해 화면에 보이는 모든 요소의 위치와 크기를 계산하는데 필요한 렌더링트리를 만든다.
렌더링 트리는 페이지를 표시하는데 필요한 정보만 가지고 있다.
마지막으로 브라우저는 최종적으로 만든 렌더링 트리를 이용해 화면을 표시한다.
중요 렌더링 경로를 최적화하는 방법에는 몇 가지가 있다.
먼저 CSS는 렌더링을 멈추게 하는 자원 중 하나이므로 미디어 타입과 미디어 쿼리를 이용해 어떤 부분을 멈추기 않고 계속 렌더링할지 표시하는 것이다.
또 다른 방법은 자바스크립트를 가능한 효율적으로 로딩하는 것이다.
비동기로 선언하지 않은 자바스크립트는 브라우저가 DOM을 만드는 것을 중단할 수 있다.
쟁크
웹 페이지를 스크롤할떄 화면이 버벅거리거나 건너 뛰는 현상을 쟁크라고 한다.
브라우저가 초당 60프레임 이하로 렌더링할때 발생한다.
보통 버벅거리는 현상은 브라우저가 페이지의 변경사항을 화면에 표현하는 과정에서 발생한다.
브라우저는 배경이나 색상, 테두리 그림자 같은 요소의 시각적 속성이 변경되면 이를 화면에 새로 그린다.
또는 사용자가 페이지에 포함된 요소의 시각적 속성에 영향을 미치는 행동을 할때에도 브라우저는 화면을 새로 그린다.
페이지 속도에 영향을 미치는 다른 요소
지리
사용자의 지리적 위치는 사이트의 로딩 시간에 크게 영향을 줄 수 있다.
서버가 거리상 멀리 떨어져 있으면 사용자의 브라우저가 서버에 접속하는데 더 많은 시간이 걸릴 것이다.
이런 이유로 전세계 사용자를 고객으로 삼는 사이트들이 CDN을 사용한다.
CDN은 전세계에 데이터를 미리 복사한 서버를 준비하여 사용자가 거기상 가장 가까운 서버에 접근하도록 하는 방식을 시간을 절약한다.
네트워크
사용자의 거주 지역에 따라 대역폭 자체의 제한이나 주어진 기간에 소비할 수 있는 대역폭의 양에 제한이 있을 수 있다.
브라우저
각 브라우저마다 콘텐츠 요청과 렌더링을 약간씩 다르게 처리하기 때문에 사용자가 사용하는 브라우저 또한 사이틩 체감 성능에 영향을 줄 수 있다.