해당 글을 참고해서 작성한 글입니다.
https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/
왜 14KB보다 작아야 할까?
더 빠르니까...
당연히 작으면 작을수록 빠른거 아니야?
물론 웹사이트의 크기가 작을수록 상대적으로 속도는 빨라지는건 사실이다.
여기서 핵심은 13KB와 14KB는 별로 차이가 없지만, 14KB와 15KB는 차이가 있다는 부분이다.
직접 테스트한 결과를 밑에서 볼 수 있는데, Content Download 속도에서 5ms 정도의 차이를 볼 수 있다.
13KB 파일
14KB 파일
15KB 파일
14KB가 상대적으로 빠른 이유
14KB인 페이지가 상대적으로 빠른 이유는 TCP의 동작방식에 대해 알아봐야 한다.
우리 웹사이트는 HTTP 프로토콜 위에 동작하고, HTTP 프로토콜은 TCP 프로토콜 위에서 동작한다.
보통 하나의 HTTP 요청을 보내면 여러개의 TCP 패킷으로 나누어서 보내는데,
이런 여러개의 패킷을 TCP에서는 어떻게 보내는지 알아보자.
TCP 프로토콜
Stop and Wait
Stop and Wait 방식은 말그대로 하나의 패킷을 보내고 응답(ACK) 받을때까지 기다리고 다음 패킷을 보내는 방식이다.
이렇게 매번 잘 받은걸 확인하고 다음 패킷을 보내면 네트워크 속도는 어마어마하게 느릴것이다.
Sliding Window
위에서 설명한 Stop and Wait 방식을 사용하면 너무 비효율적이기 때문에 오늘날의 TCP는 대부분 Sliding Window 방식을 사용한다.
Sliding Window 방식은 한번에 하나씩 패킷을 보내는게 아닌 특정 윈도우 사이즈 만큼의 패킷들을 한번에 보내는 방식이다.
이런 방식을 사용하면 한번에 여러개의 패킷들을 보낼 수 있어서 훨씬 빠르고 효율적으로 데이터를 전송할 수 있다.
윈도우 사이즈는 어떻게 정할까?
Sliding Window 에서 윈도우 사이즈를 결정하는 요소에는 크게 흐름제어 윈도우(rwnd) 와 혼잡제어 윈도우(cwnd) 부분이 있는데,
흐름제어 윈도우(rwnd)는 수신자측에서 최대로 처리할수 있는 윈도우 크기를 말하고,
혼잡제어 윈도우(cwnd)는 네트워크에서 최대로 처리할 수 있는 윈도우 크기를 말한다.
이때 윈도우 사이즈는 rwnd 와 cwnd 중에서 더 작은 값을 사용한다.
일반적인 경우에서는 rwnd > cwnd 이므로 보통 윈도우 사이즈는 cwnd 크기라고 볼 수 있다.
Slow Start
Slow Start 는 혼잡 제어 방식중 하나로, 혼잡제어 윈도우 크기를 정하는 방식중 하나이다.
처음에 전송할때는 네트워크의 대역폭같은 환경을 전혀 모르므로 정해진 Initial Window 크기만큼 전송한다.
보통 Initial Window 의 크기는 10이라서 처음에는 10개의 패킷을 보낸다.
패킷이 손실없이 잘 보내지면 2배씩 윈도우 크기를 늘려서 빠르게 보낸다.
만약 네트워크가 혼잡해서 패킷 손실이 발생한다면 윈도우 크기를 감소시킨다.
실제 혼잡제어 방식들은 더 다양하지만 본질적으로는 비슷하게 동작한다.
그래서 왜 14KB인데?
위에서 말했듯이 보통 처음 보내는 패킷 수는 10개이다.
보통 패킷의 MTU(최대 전송 단위)는 1500바이트 이고, IP와 TCP 헤더크기가 각각 20바이트 이다.
즉 하나의 패킷에서 헤더 크기를 제외한 1460바이트 가 사용할 수 있는 payload 크기이다.
여기서 10개의 패킷을 보낸다면 1460 * 10 = 14600 바이트 이고 약 14KB 라고 할 수 있다.
그래서 웹사이트 크기가 14KB 이내이면 패킷들을 한번에 보낼 수 있는 것이다.
한번에 못보내면 얼마나 느린데?
앞에서 14KB와 15KB의 속도 차이를 보면 약 5ms 정도로 무시해도 될 정도로 미미한 차이로 볼 수 있다.
그러나 개발자 도구에서 3G 환경을 기준으로 테스트 해보면 약 50ms 정도의 차이를 볼 수 있다.
만약 위성 인터넷을 사용한다면 매 왕복마다 약 600ms 정도까지도 느려질 수도 있다.
이외에도 네트워크가 혼잡하거나, 서버에 트래픽이 많이 몰리거나, 아니면 중간에 패킷이 손실될 수도 있다.
사실은요...
14KB 제한이 현실적이지 못한 여러가지 이유들이 있다.
-
HTTP 요청을 압축할 수 있으므로 실제 데이터는
50KB정도 담을 수 있다. -
패킷을 항상 처음에 10개씩 보내는게 아니라 설정값이나 환경에 따라 달라질 수 있다.
-
HTTPS에서 비대칭키 암호화를 통해 대칭키 암호를 주고받은 후에 실제 데이터를 보낸다.
마지막으로
위에서 알아본 것과 같이 14KB 규칙이 지금은 현실적이지 못한 것 같다.
그래도 14KB 규칙의 원리를 알면 네트워크 최적화에 도움이 더 많이 될 것 같다.
급 훈훈
참고 링크
일반적인 경우, rwnd >> cwnd 이므로 보통 sender의 window size는 cwnd에 의해 결정된다
https://ddongwon.tistory.com/87
TCP Initial Window를 4개 -> 10개 세그먼트로 늘리자는 RFC 문서
https://datatracker.ietf.org/doc/html/rfc6928
TCP 흐름제어, 오류제어
https://evan-moon.github.io/2019/11/22/tcp-flow-control-error-control
TCP 혼잡제어
https://evan-moon.github.io/2019/11/26/tcp-congestion-control
중요한 CSS를 14KB 안에 포함하기
https://web.dev/articles/extract-critical-css?hl=ko
<meta charset>태그를 1024바이트 안에 포함하기
https://developer.chrome.com/docs/lighthouse/best-practices/charset?hl=ko
최신 TCP에서는 IP Fragmentation을 허용하지 않는다.
https://networkengineering.stackexchange.com/a/80755
Critical Resources and the First 14 KB - A Review
https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/
