[번역] 웹사이트 크기가 14KB보다 작아야 하는 이유
Opened this issue · 0 comments
원문 : https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/
https://dev.to/shadowfaxrodeo/why-your-website-should-be-under-14kb-in-size-398n
크기가 작은 웹사이트일수록 로드하는 시간이 줄어든다는 것은 놀랍지 않은 일입니다.
진짜 놀라운 것은 14kb 페이지가 15kb 페이지보다 훨씬 빠르게 로드된다는 것이죠. (아마 612ms정도 빠를 겁니다.) 반면에 15kb 페이지와 16kb 페이지의 차이는 아주 사소합니다.
이는 바로 TCP slow start 알고리즘때문에 발생하는 차이입니다. 이 아티클에선 이 알고리즘이 무엇인지, 어떻게 동작하는지, 그리고 왜 여러분들이 신경써야 하는지를 다룹니다. 그 전에 기본 개념에 대해 먼저 빠르게 살펴보겠습니다.
TCP란 무엇인가?
Transmission Control Protocol(TCP)는 Internet Protocol(IP)을 사용하여 데이터 패킷을 안전하게 전송하기 위한 방법입니다. 이들을 때로는 TCP/IP라고 합니다.
브라우저가 여러분의 웹사이트(또는 이미지나 스타일시트)를 요청하면 HTTP를 사용하여 요청하게 됩니다.
HTTP는 TCP 위에서 동작하며 하나의 HTTP 요청은 여러 개의 TCP 패킷들로 구성됩니다.
IP 자체는 한 장소에서 다른 장소의 인터넷으로 데이터를 전송하는 패킷들을 위한 시스템일뿐입니다. IP는 패킷이 목적지에 성공적으로 도착했는지 확인할 방법이 없습니다.
웹사이트의 경우, 여러분도 알다시피 모든 데이터가 도착하는 것이 중요합니다. 그렇지 않으면 웹페이지의 일부 청크들이 누락됩니다. 스트리밍 라이브 비디오처럼 이런 것들이 중요하지 않은 웹의 경우들도 있습니다.
TCP는 브라우저와 여러분의 웹사이트 서버가 서로 패킷들이 잘 도착했는지 소통할 수 있게 하는 IP의 확장판입니다.
서버는 패킷들을 보내고 브라우저로부터 오는 패킷들이 도착했다는 응답을 기다립니다. (이 응답을 ACK이라고 부릅니다.) 잘 도착했다고 응답이 오면 다른 패킷들을 더 보내고, ACK을 받지 못하면 다시 패킷들을 보내게 됩니다.
TCP slow start란?
TCP slow start는 동시에 패킷들을 얼마나 보낼 수 있을지 알아내기 위해 서버가 사용하는 알고리즘입니다.
브라우저가 서버에 처음 커넥션을 만들면, 서버는 둘 사이의 대역폭(bandwitdth) 이 얼마나 되는지 알 수 없습니다.
대역폭은 네트워크 상에서 시간당 전송될 수 있는 데이터의 양을 의미하는 단위입니다. 보통은 초당 비트의 개수로 측정됩니다.(b/s). 일반적으로 이를 배관으로 비유하기도 하는데 대역폭을 초당 파이프에서 나오는 물의 양으로 생각하면 됩니다.
서버는 커넥션이 다룰 수 있는 데이터의 양을 알지 못하기 때문에 작고 안전한 정도의 크기를 가지는 데이터(일반적으로 TCP 패킷)를 보내기 시작합니다.
그 패킷들이 사이트 방문자에게 성공적으로 도달했다면, 그들의 컴퓨터는 패킷이 잘 도착했다고 ACK을 다시 보냅니다. 서버는 다시 더 많은 데이터를 보내게 되는데 이때는 전에 보냈던 패킷의 두 배를 보냅니다.
이 과정은 패킷을 잃어버리거나 서버가 ACK을 받지 못할 때까지 반복됩니다. (이 시점에서 서버는 패킷을 계속 보내기는 하지만 더 적은 속도로 보냅니다.)
이것이 TCP slow start의 요지입니다. 실제론 알고리즘이 더 다양하지만 본질적인 동작 방식은 위 설명과 같습니다.
14kB는 어디서 왔는가?
대부분의 웹 서버에서 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가 소요되며 처리된 데이터는 다시 서버가 전송합니다. 지상 기지국에 돌아와 우주로 전송되고 위성 접시로 돌아와 왕파이 라우터, 석유 장치 핸드폰을 거치게 됩니다.
phone -> WiFi router -> satellite dish -> satellite -> ground station -> server -> ground station -> satellite -> satellite dish -> WiFi router -> phone
이를 계산 해보면 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612ms라는 식을 세울 수 있습니다.
각 데이터의 왕복마다 612ms가 소요됩니다. 시간이 오래 걸리지 않는 것처럼 보이지만 웹사이트가 첫 번째 리소스를 가져올 때 여러 번 왕복할 수도 있답니다. 게다가 HTTPS는 첫 왕복을 수행하기 전에 두 번의 추가 왕복이 필요하니 최대 1836ms가 걸리겠군요.
실제로 나쁜 네트워크 환경에서의 대기시간
위성 인터넷은 고의적인 나쁜 예시처럼 보일 수도 있지만 요점을 설명하기 위해 선택한 비유입니다. 그러나 네트워크 상황이 좋지 않은 곳에 있는 경우 대기 시간은 여러 이유로 더 나빠질 수 있습니다.
- 2g 모바일 평균 대기시간: 300ms ~ 1000ms
- 3g 네트워크: 100ms ~ 500ms
- 뮤직 페스티벌처럼 사람이 엄청 많이 모이는 곳
- 아주 많은 트래픽을 처리하는 서버
- 안좋은 기기
또한 연결이 불규칙하게 되면 패킷이 손실되므로 손실된 패킷을 가져오는 데도 추가적인 왕복이 발생합니다.
그렇다면 어떻게 해야 하는가?
여러분들의 웹사이트 방문자를 사랑하고 그들이 행복하기를 원한다면 당연히 웹사이트 크기를 가능한 줄여야 합니다. 각 페이지가 14kB를 넘지 않는 것이 좋은 목표가 됩니다.
14kB는 압축을 포함한 크기이므로 압축하지 않았을 때 일반적으로 50kB정도까지도 가능합니다. Apollo 11 guidance 컴퓨터가 겨우 72kB 메모리만 가지고 있다는 것을 고려하세요.
일단 자동 재생 비디오, 팝업, 쿠키, 쿠키 허용 배너, 소셜 네트워크 버튼, 트래킹 스크립트, 자바스크립트와 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 규칙을 권장합니다.