Why your website should be under 14kb in size
Having a smaller website makes it load faster — that's not surprising. What is surprising is that a...
dev.to
크기가 작은 웹 사이트일수록 로드하는 시간이 줄어든다는 것은 놀랍지 않은 일입니다.
하지만 정말 놀라운 것은 14kB의 페이지가 15kB의 페이지보다 훨씬 빠르게 로드된다는 것입니다.(아마 612ms 정도 빠를 것입니다.) 반면에 15kB 페이지와 16kB의 페이지의 차이는 아주 사소합니다.
이는 TCP의 slow start 알고리즘 때문에 발생하는 차이입니다. 이 아티클에선 이 알고리즘이 무엇인지, 어떻게 동작하는지, 그리고 왜 여러분들이 신경써야 하는지를 다룹니다. 그 전에 기본 개념에 대해 먼저 살펴보겠습니다.
What is TCP?
Transmission Control Protocol은 Internet Protocol를 사용하여 데이터 패킷을 안전하게 전송하기 위한 방법입니다. 이들을 때로는 TCP/IP라고 합니다.
브라우저가 웹사이트(또는 이미지나 스타일 시트)를 요청하면 HTTP를 이용하여 요청하게 됩니다. HTTP는 TCP 위에서 동작하고 하나의 HTTP 요청은 여러개의 TCP 패킷들로 구성됩니다. IP 자체는 한 장소에서 다른 장소의 인터넷으로 데이터를 전송하는 패킷들을 위한 시스템일 뿐입니다. IP는 패킷이 목적지에 성공적으로 도착했는지 확인할 방법이 없습니다.
웹 사이트의 경우 모든 데이터가 도착하는 것이 중요합니다. 그렇지 않으면 웹 페이지의 일부 청크들이 누락됩니다. 스트리밍 라이브 비디오처럼 이런 것들이 중요하지 않은 웹의 경우도 있습니다.
TCP는 브라우저와 여러분의 웹 사이트 서버가 서로 패킷들이 잘 도착했는지 소통할 수 있게 하는 IP의 확장판입니다. 서버는 패킷들을 보내고 브라우저로부터 오는 패킷들이 도착했다는 응답을 기다립니다.(이 응답을 acknowledgement 또는 ACK이라고 합니다.) 잘 도착했다고 응답이 오면 다른 패킷들을 더 보내고 ACK을 받지 못하면 다시 패킷들을 보내게 됩니다.
What is TCP slow start?
TCP slow start는 동시에 패킷들을 얼마나 보낼 수 있을지 알아내기 위해 서버가 사용하는 알고리즘입니다. 브라우저가 서버에 처음 커넥션을 만들면, 서버는 둘 사이의 대역폭(bandwidth)가 얼마나 되는지 알 수 없습니다.
대역폭은 네트워크 상에서 단위 시간당 전송될 수 있는 데이터의 양을 의미하는 단위입니다. 일반적으로 초당 비트(b/s) 단위로 측정됩니다. 배관에 비유하자면, 대역폭은 파이프에서 초당 얼마나 많은 물이 나올 수 있는지에 비유할 수 있습니다.
서버는 연결이 처리할 수 있는 데이터의 양을 알 수 없으므로 일반적으로 10개의 TCP 패킷으로 소량의 안전한 데이터를 전송하는 것으로 시작합니다. 이러한 패킷이 사이트 방문자에게 성공적으로 도달하면 방문자의 컴퓨터는 패킷이 수신되었다는 ACK을 다시 보냅니다. 그러면 서버는 더 많은 데이터를 다시 보내지만 이번에는 패킷의 양이 두 배로 늘어납니다. 이 과정은 패킷이 손실되어 서버가 ACK을 수신하지 못할 때까지 반복됩니다.(이 때 서버는 계속해서 패킷을 보내지만 속도가 느려집니다.) 이것이 TCP slow start의 요점입니다. 실제로는 알고리즘이 다양하지만 기본적으로 작동하는 방식은 동일합니다.
So where does 14kB come from?
대부분의 웹 서버에서 TCP slow start 알고리즘은 10 TCP 패킷을 보내는 것으로 시작합니다. TCP 패킷의 최대 사이즈는 1500 바이트입니다. (최대 사이즈는 TCP 명세에 의해 정해지지 않고, 이더넷 표준에 의합니다.)
각 TCP 패킷은 헤더로 40바이트를 사용합니다. IP는 16바이트, 추가적으로 TCP를 위해 24 바이트를 사용합니다. 결과적으로 TCP 패킷당 1460 바이트가 남은 것입니다. 10 * 1460 = 14600 bytes이므로 대략 14kB가 됩니다!
따라서 웹 사이트나 웹 사이트 중요한 부분을 14kB에 맞출 수 있다면 사용자와 서버 사이에서 돌아다니는데 걸리는 시간을 많이 아낄 수 있습니다.
한 번 왕복이 얼마나 비용이 드는가?
사람들은 참을성이 없습니다. 그리고 한 번 왕복하는 건 아주 긴 시간입니다. 게다가 latency에 따라 달라집니다. latency는 데이터 출처로부터 목적지까지 데이터의 패킷이 이동하는데 걸리는 시간을 의미합니다.
대역폭이 파이프에서 초당 흐르는 물의 양이라고 하면, 대기시간은 물방울이 파이프에 들어가서 다른 끝에서 빠져나가는데 걸리는 시간입니다.
나쁜 대기 시간에 대한 재밌는 예시를 보여들겠습니다.
위성 인터넷
위성 인터넷은 지구 주위를 도는 위성에 의해 제공되는 인터넷입니다. 이 인터넷은 인구가 매우 적은 지역, 석유 굴착소, 유람선이나 항공사의 기내 와이파이 등에 사용됩니다.
나쁜 대기시간에 대한 예시를 설명하기 위해, 여러 석유 굴착 장치가 주사위를 잊어 14kb 미만의 missingdice.com 사이트에서 Dungeons & Dragons 게임을 플레이한다고 가정해보겠습니다.
먼저 핸드폰을 사용해서 웹페이지에 대한 요청을 보내게 됩니다. 핸드폰은 장비의 와이파이 라우터로 요청을 보내는데 이 장비는 데이터를 위성 접시로 요청을 보내고 다행히도 1ms 밖에 걸리지 않습니다. 위성 접시는 지구를 도는 위성에 데이터를 전송합니다. 일반적으로 이것은 지구 표면 위 35786km 정도 정지 궤에 있는 위성을 사용합니다. 광속은 299792458 m/s이므로 지구에서 위성으로 메시지를 보내는 데 120ms가 소요됩니다. 그 다음 위성은 메시지를 다시 지상으로 보내는 데 이때 120ms가 더 소요됩니다.
지상 기지국에서 서버가 지상에 있는 곳이면 어디든지 요청을 보내야만 합니다.(광성유 케이블에 있을 때 빛은 200000000 m/s로 느려집니다.) 지상 기지국과 서버 사이의 거리가 뉴욕과 런던 사이의 거리와 같아면 약 28ms가 소요되지만 뉴욕과 시드니의 거리라면 80ms 정도 소요됩니다. 수치상 편하게 60ms가 소요된다고 해봅시다.
요청은 서버에서 처리되는 데 약 10ms가 소요되며 처리된 데이터는 다시 서버가 전송합니다. 지상 기지국에 돌아와 우주로 전송되고 위성 접시로 돌아와 왕파이 라우터, 석유 장치 핸드폰을 거치게 됩니다.
이를 계산 해보면 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612ms라는 식을 세울 수 있습니다.
각 데이터의 왕복마다 612ms가 소요됩니다. 시간이 오래 걸리지 않는 것처럼 보이지만 웹사이트가 첫 번째 리소스를 가져올 때 여러 번 왕복할 수도 있답니다. 게다가 HTTPS는 첫 왕복을 수행하기 전에 두 번의 추가 왕복이 필요하니 최대 1836ms가 걸리겠군요.
실제로 나쁜 네트워크 환경에서의 대기시간
위성 인터넷은 고의적인 나쁜 예시처럼 보일 수 있지만 요점을 설명하기 위해 선택한 비유입니다. 그러나 네트워크 상황이 좋지 않은 곳에 있는 경우 대기 시간은 여러 이유로 더 나빠질 수 있습니다.
- 2g 모바일 평균 대기시간: 300ms ~ 1000ms
- 3g 네트워크: 100ms ~ 500ms
- 뮤직 페스티벌처럼 사람이 엄청 많이 모이는 곳
- 아주 많은 트래픽을 처리하는 서버
- 안좋은 기기
또한 연결이 불규칙하게 되면 패킷이 손실되므로 손실된 패킷을 가져오는 데도 추가적인 왕복이 발생합니다.
그렇다면 어떻게 해야 하는가?
여러분들의 웹 사이트 방문자를 사랑하고 그들이 행복하기를 원한다면 당연히 웹 사이트 크기를 가능한 줄여야 합니다. 각 페이지가 14kB를 넘지 않는 것이 좋은 목표가 됩니다. 14kB는 압축을 포함한 크기이므로 압축하지 않았을 때 일반저긍로 50kB 정도까지도 가능합니다. 일단 자동 재생 비디오, 팝업, 쿠키, 쿠키 허용 배너, 소셜 네트워크 버튼, 트래킹 스크립트, 자바스크립트와 css 프레임워크, 그리고 아무도 좋아하지 않는 다른 쓸모없는 것들을 없앴다면 아마도 당신은 이 목표를 달성할 수 있게 될 겁니다.
그러나 14kB에 맞추려고 최선을 다했으나 불가능할 때도 14kB 규칙은 여전히 유용합니다. 만약 여러분들이 방문자에게 처음으로 보내지는 14kB의 데이터가 유용한 정보를 제공하는지를 확인하세요. 예를 들어 중요한 CSS, JS, 앱을 사용하는 방법을 설명하는 텍스트의 첫 단락들과 같이 말입니다.
주의 - 14kB 규칙은 압축하지 않은 HTTP 헤더를 포함합니다. (심지어 HTTP/2의 첫 번째 응답에서도 말입니다.) 또한 이미지가 포함되어 있으므로 위에 있는 것만 로드하는 식으로 작게 유지하거나 방문자가 기다리고 있음을 알도록 placeholder를 활용하세요.
규칙에 대한 몇 가지 경고
14kB 규칙은 컴퓨팅의 기본 법칙보다는 경험적인 이론에 가깝습니다.
- 어떤 서버들은 TCP slow start 첫 윈도우 사이즈를 10이 아닌 30 패킷으로 증가시키도 합니다.
- 때때로 서버들은 큰 윈도우를 사용하게 하는 TLS 핸드쉐이크를 사용하면 많은 패킷으로 시작할 수 있다는 것을 알고 있습니다.
- 서버는 라우트가 관리할 수 있는 패킷 수를 캐시하고 다음 연결 시 더 많은 패킷을 보낼 수 있습니다.
- 다른 경고 - 이 규칙이 항상 성립하는 것은 아닌 이유에 대한 글
HTTP/2와 14kB 규칙
14kB 규칙은 HTTP/2를 사용할 때 더 이상 적용되지 않다고 하기도 합니다. 저는 이 이슈에 대한 글들을 모두 읽어 봤지만 HTTP/2를 사용하는 서버가 10개의 패킷으로 시작하는 TCP slow start를 사용하지 않는 증거는 보지 못했습니다.
HTTP/3와 QUIC
HTTP/2와 비슷하게 HTTP/3와 QUIC도 14kB 규칙과 무관하다는 의견이 있습니다만 사실이 아닙니다. QUIC는 14kB 규칙을 권장합니다.