이번에 모바일 검색 속도개선 작업을 하면서 크롬 개발자도구를 많이 활용하게 되었다.  피들러나 크롬 개발자도구를 통해 개선점을 찾고 확인하는데 도움이 많이 되었는데 올바른 사용법과 정보를 알지 못해서 이번 기회에 정리를 해보려고한다.

그중에서 네트워크 패널의 타임라인 컬럼 리소스 클릭시 보여지는 상세정보 레이어에 해당하는 내용부터 정리해 보았다. (요청 링크를 누르고 우측 timing 탭을 통해서도 확인이 가능하다.)

 

Queuing
요청이 큐 된다면

• 해당 요청은 script/style 같은 리소스 보다 낮은 우선순위로 고려되어 랜더링 엔진에 의해 연기되었다. 이미지가 종종 큐가된다.
• 해당 요청이 사용불가한 TCP 소캣 확보를 기다리기 위해 홀드되었다.
• HTTP 1. 사용시 브라우저가 기본적으로 허용하는 6개의 TCP Connection 때문에 해당 요청이 홀드되었다.
• 시간이 캐시 만드는데 사용되었다(대체로 매우 빠르다)
  (리퀘스트 처리할 시간이 캐시 만드는데 사용되어서 큐되었단 말인 듯.
  ‘대체로 매우 빠르다’는 보통은 빨라서 이것때문에 큐될일이 없다는 말인가?)

Stalled/Blocking
요청이 보내지기 전까지 기다리는 시간이며 큐에 언급된 내용으로도 기다릴 수 있다.
추가로 스톨드/블럭킹 시간은 프록시 협상에 사용된 시간도 포함하고 있다.
(프록시 협상 : 요청주체와 응답주체간 컨텐츠 내용 협상 / 프록시 서버 연결협상, 컨텐츠 연결 협상등 다양한 negotiation이 해당 내용의 원인이 되는 것 같다.)

Proxy Negotiation
프록시 서버 커넥션 연결에 사용된 시간

DNS Lookup
DNS Lookup에 사용된 시간으로  페이지의 모든 새 도메인은 DNS lookup을 위해 roundtrip이 요구된다.
(브라우저에서 처음 인식되는 도메인 주소에 대해서 DNS Lookup을 하는데 DNS 프로토콜 설계상 즉시 IP응답을 주지 못하고 여러 DNS 서버간 통신 후 IP 변환이 되는 경우 시간이 걸리게된다. 여기서 말하는 roundtrip는 이 전체 과정(a full round-trip)을 의미하는 것 같다.)

Initial Connection/Connecting
TCP 핸드쉐이킹/커넥션 재시도와 SSL negotiating을 포함한 커넥션 수립에 걸린시간

SSL
SSL 핸드쉐크 완료에 사용된시간

Request Sent / Sending
이슈된 네트워크 요청에 사용된 시간. 대게 밀리세컨드의 일부이다.
(밀리세컨드보다 조금 걸린단 소린가?)

Waiting (TTFB, time to frist byte)
초기 응답 대기에 사용된 시간 그리고 최초 바이트를 위한 시간.
이 시간은 서버 roundtrip의 숨겨진 부분을 잡는다.추가적으로 서버응답을 위한 대기시간에 사용된 시간이다.

Content Download/Downloading
응답 데이터를 받는데 사용된 시간

 

출처 : https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing

해석해서 옮겨보았는데 모르는 용어들이 많아 좀 더 찾아보면서 정리를 해야할 것 같다.

글 보시고 수정 및 조언을 주실분들은 아래 댓글로 남겨주시면 너무 감사하겠습니다.^^

 

생활코딩 @윤동현님 DNS Lookup의 round-trip 의견 주셔서 감사합니다.