▲

15kB 페이지보다 14kB 페이지가 훨씬 더 빠르게 로드될 수 있음 (2022)

 (endtimes.dev)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 웹사이트 크기를 14kB 이하로 유지하면 15kB일 때보다 로딩 속도를 크게 단축할 수 있음
  • 이 현상은 TCP 슬로우 스타트 알고리듬에 의해 발생하며, 첫 데이터 전송량 한계로 인해 체감 속도 차이가 나타남
  • 14kB는 대부분의 서버가 처음에 보내는 10개 TCP 패킷의 용량에 해당함
  • 위성 인터넷 등 높은 레이턴시 환경에서는 한 번의 추가 왕복(RTT)이 612ms 이상의 지연을 초래함
  • 실제로 14kB 미만으로 주요 콘텐츠를 넣거나, 첫 14kB 내에 중요한 리소스를 배치하는 것이 웹 성능 최적화에 효과적임

개요 및 주요 원리

  • 웹사이트의 크기가 작을수록 빨리 로드된다는 점은 잘 알려진 사실임
  • 하지만 14kB에서 15kB로 넘어가는 순간, 첫 응답 속도에서 획기적 차이가 발생하는 점은 예상치 못한 사실임
  • 15kB와 16kB 페이지 사이의 속도 차이는 미미하지만, 14kB와 15kB 사이에는 최대 612ms 차이가 생길 수 있음

TCP란 무엇인가

  • Transmission Control Protocol (TCP) 는 IP(Internet Protocol) 위에서 작동하며, 패킷의 신뢰성 보장을 담당함
  • 웹 브라우저는 HTTP 요청 시 여러 개의 TCP 패킷을 전송함
  • IP만 사용할 때는 패킷이 도착했는지 확인할 수 없어서, TCP가 패킷 수신 확인(ACK) 기능을 제공함
  • 서버는 소량의 패킷을 먼저 보내고, 브라우저에서 ACK를 받으면 추가 패킷을 전송함
  • ACK가 없을 경우, 패킷 재전송 절차가 실행됨

TCP 슬로우 스타트란

  • TCP 슬로우 스타트는 서버가 네트워크 연결 품질(대역폭)을 파악하기 위해 단계적으로 패킷 전송량을 늘려가는 알고리듬임
  • 접속 초기에 서버는 소량(일반적으로 10개)의 패킷만 전송함
  • 방문자 컴퓨터에서 ACK를 정상적으로 보내면 패킷 전송량을 두 배로 증가시킴
  • ACK 누락이 발생하면 이후에는 느린 속도로 패킷을 보냄
  • 실제 알고리듬은 구현마다 세부 차이가 있지만 개념은 동일함

14kB 기준의 근거

  • 대부분의 서버는 슬로우 스타트에서 TCP 패킷 10개를 한 번에 보냄
  • TCP 패킷 최대 크기는 1500바이트이지만, 헤더(40바이트) 를 제외하면 1460바이트가 실질 데이터임
  • 따라서 10 x 1460 = 14600바이트(약 14kB) 가 첫 전송 극한치임
  • 웹사이트 또는 중요한 리소스를 14kB 이하(압축 적용 시는 원본 데이터 수십 kB 수준)에 맞추면, 시작 왕복 지연 없이 표시 가능함

한 번의 왕복이 얼마나 큰 지연을 유발하는가

위성 인터넷 예시

  • 높은 레이턴시 환경의 대표 예로 위성 인터넷(석유 시추선, 유람선 등) 사용자가 있음
  • 휴대폰에서 홈페이지 요청 시, 라우터 → 위성 안테나 → 우주 위성 → 지상국 → 서버, 각 구간 이동에 수십~수백 ms 소요됨
  • 전체 전송 왕복에는 두 번의 우주 왕복, 네트워크 구간 이동, 서버 처리까지 포함해 약 612ms의 추가 지연 발생함
  • HTTPS를 사용할 경우, 추가 핸드셰이크로 인해 1836ms까지 늘어날 수 있음

육상 네트워크의 레이턴시

  • 2G, 3G 등 모바일 네트워크에서도 100~1000ms까지 레이턴시가 발생함
  • 혼잡한 상황이나 서버 과부하, 패킷 손실 등 다양한 환경에서 추가 지연이 생길 수 있음

14kB 규칙을 적용한 웹사이트 최적화 전략

  • 웹사이트나 페이지를 가능한 한 작게 만드는 것이 핵심임
  • 각 페이지의 압축된 전송량이 14kB 이하가 되도록 설계하는 것이 이상적임
    • 압축 적용 시 실제 콘텐츠는 ~50kB까지 포함 가능
  • 자동재생 동영상, 팝업, 추적기, 불필요한 JS/CSS 등 대부분의 불필요 요소를 줄이면 충분히 달성 가능함
  • 만약 14kB로 전체 구현이 어렵다면, 첫 14kB에 핵심 리소스 및 주요 콘텐츠(CSS, JS, 주요 텍스트 등)를 우선 배치하는 것이 중요함
  • HTTP 헤더(압축 불가) , 이미지(필요 최소한/위치한 부분만 로딩 또는 플레이스홀더 적용)도 14kB 내에 포함됨

14kB 규칙의 예외와 최신 프로토콜 이슈

  • 14kB 규칙은 지나친 일반화는 아니지만, 몇 가지 예외 사항 존재함
    • 일부 서버는 초기 윈도우를 30패킷으로 확장함
    • TLS 핸드쉐이크를 통해 더 큰 윈도우 허용 가능성 있음
    • 라우트별로 전송 가능 패킷 수를 캐싱하여 다음 접속 시 더 많이 보낼 수 있음
  • HTTP/2에서도 서버가 TCP 슬로우 스타트로 10 패킷부터 시작하는 관행은 대체로 변하지 않음
  • HTTP/3, QUIC에서도 14kB 규칙이 공식적으로 권장됨

요약 및 참고 자료

  • 기술적 근거와 추가 설명 자료들은 각 링크를 통해 확인 가능함
  • 최초 발행: 2022-08-25, 최근 수정: 2022-08-26, 작성자: Nathaniel, 관련 태그: 웹 성능, HTTP, TCP

참고 링크

  • Ethernet 프레임과 TCP 헤더 구조, 레이턴시 및 대역폭 관련 추가 자료, TCP/QUIC 사양 등
▲
GN⁺ 11시간전  [-]
Hacker News 의견

  • 소프트웨어 개발자는 미디어 계층에 좀 더 관심을 가질 필요가 있음, 특히 3G/5G의 신뢰성과 지연에 대해 저자가 짚은 점이 인상적임. 라디오는 거의 항상 재전송이 일어나고, 대부분의 HTTP 통신에서 패킷이 순서대로 도착해야 UI가 업데이트됨. 실제로 단일 REST 요청도 요청과 응답이 1400바이트 미만일 때에만 실제 한 패킷으로 처리됨. 그 이상이면 ‘단일’ 요청이 사실 여러 패킷으로 분할됨. 이 중 하나라도 문제가 있으면 모든 패킷이 순서대로 도착해야 화면이 제대로 갱신됨. 실험해보고 싶으면 Chrome 개발자 도구에서 3G 모드와 패킷 손실을 켜고 테스트하면 작은 최적화 하나만으로도 UI 반응성이 크게 개선되는 것을 볼 수 있음. 그래서 API와 UI를 최대한 작게 만드는 것이 설득력 있는 이유임

  • 내 홈페이지 전송 용량이 압축 기준 7.0kB임

    • /
    • main.css
    • favicon.png
    • 총합 7.0kB 블로그 리스트 및 전체 웹사이트는 내 커스텀 정적 사이트 제너레이터(공개: site.lisp, Common Lisp 사용)로 만듦. 수학 관련 포스트에는 KaTeX를 클라이언트 렌더링으로 사용 중인데, 이 경우 347.5kB나 추가됨
    • katex.min.css 23.6kB
    • katex.min.js 277.0kB
    • auto-render.min.js 3.7kB
    • KaTeX_Main-Regular.woff2 26.5kB
    • KaTeX_Main-Italic.woff2 16.7kB
    • 총 추가 347.5kB 언젠가 KaTeX를 서버 렌더링으로 바꿀까 고민 중임. 이 블로그는 대학 기숙사 시절부터 해온 나만의 열정 프로젝트임. 모든 HTML과 템플릿, CSS까지 직접 작성했고, 각 페이지에 꼭 필요한 요소만 넣으려 항상 신중하게 구성해서 작은 용량 유지 중임
    • 내 홈페이지
    • 수학 포스트 모음
      • 굳이 더 나은 방식을 쓰지 말라는 건 아니지만, LaTeX 표현 같은 동적 컴포넌트가 로드될 때 클라이언트 렌더링에서 발생하는 지연은 일반 사용자에게 거의(또는 진짜) 감지되지 않음. 지나친 최적화도 문제임. 이 모든 SEO 기반 퍼포먼스 추구는 수백만 뷰의 트래픽이 있는 서비스가 아니면 시간 대비 얻는 이득이 별로임. 무인 배를 바다에서 조력으로 조정하는 것에 공기역학까지 걱정하는 수준임. 자원이 한정된 입장에서 총 비용과 이익을 고려하면 최적화가 항상 최고의 선택은 아님
      • 수학 콘텐츠가 적은데 굳이 KaTeX를 쓴다면, MathML(mathml-core)을 대체로 검토해보는 것도 방법임
      • 수학 공식이나 LaTeX 표현을 굳이 클라이언트 js로 렌더하는 게 이해되지 않음. 왜 미리 HTML/CSS로 변환해서 미리 렌더된 상태로 넣지 않는지 의문임
      • 무거운 라이브러리는 초기 페이지 렌더 후에 로드하거나, 뷰포트에 보일 때만 SVG로 공식 그래픽을 불러오는 것도 아이디어임. 내 생각임

  • 14kB 목표는 다소 도전적이지만, 초기 10패킷 내로 제한하는 아이디어도 흥미로움. 나처럼 웹사이트 용량에 집중하는 프로젝트로 512kb.club이 있음. 사이트 크기를 골프 스코어처럼 비교하는 곳임. 내 사이트(anderegg.ca)는 등록 전에 전 자원 합산 71kB가 나왔음. 이 프로젝트 덕분에 Cloudflare Radar도 알게 되었는데, 사이트 분석 및 페이지 용량 측정에 좋은 툴이 있음. 주 목적은 전체 인터넷 대시보드지만 페이지 사이즈 분석 도구도 포함되어 있음

    • 사용자 입장에서 묻고 싶은데, 남은 500kB는 무엇을 위해 쓰는 것임? 나는 90% 텍스트만 필요하고, 나머지도 벡터 그래픽이면 충분함. 14 kB만으로도 텍스트와 그래픽이 꽤 들어가는데, 나머지 500은 뭐에 쓰임?
    • 512kb가 현실적인 기준임. 나도 내 웹사이트에 이 기준을 적용함. 14kb 수준 웹사이트는 이미 웹의 기준을 넘어서버렸음
    • 개인 웹사이트라면 512kb는 충분히 달성 가능함. 내 다음 타깃은 99kb(100kb 이내)임. 주말 몇 번만 투자하면 무난함. 내 사이트는 512kb에서 Orange 등급임

  • 이걸 좀 더 재미있게 실험해보고 싶다면, 초기 윈도우(IW) 크기는 서버 측에서 설정할 수 있음. 예를 들어 아래와 같이 조정 가능함

    • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 검색해보면 지금은 CDN이 초기 윈도우를 30 패킷(45kb)까지 주는 경우도 있다고 함
    • 13년 전에는 10패킷도 ‘치팅’으로 여겨졌음. 관련 내용은 이곳과 http://blog.benstrong.com/2010/11/…">벤스트롱 블로그(아카이브) 참고
    • CDN의 초기 윈도우가 30패킷이라는 근거 자료 있는지 궁금함
    • 그냥 '나쁜 시민'처럼 1000 패킷으로 설정할 수도 있음... 다만 단점은 누군가 다이얼업이나 bufferbloat 있는 연결에서 병목이 생길 수 있음

  • 아래 글에서 설명한 내용도 적용됨: Cloudflare 블로그 - 러시아 ISP가 16KB까지만 허용해 대부분 웹 브라우징이 불가능해진 현상. Cloudflare 분석에 따르면, 러시아 ISPs가 자국 사용자의 인터넷 throttling을 통해 웹자산당 처음 16KB까지만 로딩되게 제한 중임

  • TCP Slow Start가 뭔지 모르는 사람과, 웹사이트 로딩 지연을 미세하게까지 신경 써야 할 정도로 관심 있는 사람의 교집합은 매우 적음. 스타트업은 우선 스타트업에 집중해야 하고, 대기업만이 이런 최적화에 집착할 여력이 있음

    • "중요한 것부터 집중하니까 성능 최적화까지 신경 쓸 겨를이 없다"는 식으로 접근하면 영원히 신경 쓰지 않게 됨. 그래서 요즘 대다수 앱과 사이트가 느리고 형편없음
    • 만약 그게 사실이라면 Microsoft 같은 곳의 소프트웨어는 언제나 완벽하게 최고 효율로 동작해야 함
    • 개념적으로는 맞는 말 같음. 그런데 Figma의 Evan Wallace가 성능에 집착하지 않았다면 Figma는 지금의 모습이 될 수 없음. 어떤 땐 '성능' 자체가 곧 제품의 주요 기능이 되기도 함
    • 이건 선택의 문제가 아니라 그냥 디폴트로 따라오게 만들 수도 있음. 나는 10억개 셀, 체크박스 데모[1] 모두 datastar를 써서 겨우 10kb 조금 넘음. 모바일 네트워크와 3G에서 차이가 큼. 내 실험으론 14kb 넘으면 품질 낮은 연결에선 3초 더 걸렸음. datastar 메인테이너가 TCP slow start까지 챙겨준 덕에 오히려 노력을 안 해도 덩달아 이득을 봄
    • 기업 규모가 성능 최적화와 큰 관련 있다고 생각하지 않음. 오히려 대형 기업이 더 느린 경우가 많음

  • 내 홈페이지가 17.2KB임!(의존성 제외) 개인 페이지에 정말 최적화를 열심히 해서 Lighthouse 100점 만점도 달성함. 전엔 불가능할 줄 알았는데 성공함. 참고로 Rails로 만들었음. 이런 최적화, 실제로 할 만한 가치가 있음. 반응없는 느낌 없이 번개처럼 뜨는 페이지 경험은 그 자체로 매우 만족스러움

    • news.ycombinator.com이 즉각 로드되는 걸 경험하면 심리적으로도 엄청 쾌적해서, 쉬는 시간마다 자동적으로 열게 됨
    • 수천 개 사이트용 템플릿 코드 최적화를 엄청나게 해서 Lighthouse 100/100/100/100 점수를 냈음. 모바일도 완벽 100. 초기 로드는 17.2kB보다 훨씬 커서 120kB 가량이지만, 비법은 모든 불필요한 HTTP 요청을 없애고, "above-the-fold" 영역만 JS 실행, 나머지는 lazy eval, defer 등 가능한 한 지연 로드. JS/CSS는 inline 처리, 서드파티 위젯도 팝업 아이콘 등 'facade' 방식으로 실제 요청은 뒤로 미룸. SSR 백엔드 덕도 큼. Vimeo 배경 동영상 위도 100점이었으나 Youtube로는 불가능. 완벽한 점수 내는 방법은 Lighthouse 결과를 해석해 코드베이스 자체를 완전히 다시 짠 거였음. 덕분에 속도 관련 클라이언트 컴플레인이 완전히 사라져서 SEO나 실제 점수 자체에서도 큰 경쟁력이 됨
    • Rails는 렌더링 최적화와 직접적 연관은 없음. 완벽한 Lighthouse 점수 축하함

  • 글에 두 가지 논리적 약점이 있다고 생각함

    1. 위성통신에서 패킷 하나 보내는 데 약 1600ms 걸린다는 수식이 있지만, 14kb룰의 근거로는 약함. 큰 웹사이트와 비교가 없으니 10패킷 ≠ 16초임을 보여주지 못함
    2. 웹페이지 이미지도 14kb룰에 포함시킨다고 했는데, 이미지가 처음 로딩에 inline되는 경우가 얼마나 있나? 실제론 아주 드문 예외 케이스라 99.9% 적용 안 되는 점을 더 명확히 언급해야 함 - "<i>이미지 인라인되는 경우?</i>"라면, 대표적으로 초기 화면에만 등장하는 저해상도 썸네일에 CSS blur를 추가하고, 진짜 이미지는 나중에 비동기로 fade in하는 기법이 있음. 제대로 하면 1~200바이트 정도 추가 소비만 발생함. 내 블로그엔 적용했고, Wordpress, Medium 같은 플랫폼에도 많이 채택됨. 주로 상업용 프론트엔드 하이퍼최적화용 트릭임 - 사용자 대부분이 저지연 위성 연결을 쓰는 것처럼 가정하고, 모든 웹사이트가 수 MB 단위인 현실에서 내 페이지만 못 견딘다는 전제에도 동의하지 않음

  • 요즘 세대가 단순 정적 웹사이트도 Next.js 같은 프레임워크로 만드는 경향이 있음. 이제는 HTML+CSS+js 시대가 저물어 아쉬움을 느낌

    • 동의함. 나도 최소 리소스·자바스크립트 직접 최적화·14kb 룰 사이트 다 해봤는데, 이 방식은 설계와 아키텍처 제약으로 이어짐. 기능이 늘면 그때의 '최소화' 결정들이 전부 기술 부채가 됨. 대부분은 '프레임워크 없는 순수 웹'에 환상 가졌다가, 어느 순간 그게 더 고역이 됨. 근데 이소모픽 JS 프레임워크 쓰면 일단 정적 페이지로 시작해서 적당히 최적화하다 필요하면 thick client JS로 전환할 수 있음
    • 이미 트렌드가 다시 이동 중임. 요즘 프레임워크들은 대부분 정적 사이트도 잘 지원함. Astro 같은 건 아예 정적 사이트용으로 탄생했음
    • 이제야 알았나 싶은데, 사실 jQuery 인기가 급등하던 2010년 전부터 쭉 그래왔음
    • Next.js는 번들 코드를 아주 강하게 최적화해서 람다나 작은 서버 런칭에 최적임. Next로 만든 정적 사이트도 번들 아주 작게 만듦

  • 지연뿐 아니라 자원 소모 최소화는 지속가능한 미래의 필수 조건임. 네트워크가 환경에 끼치는 영향도 결코 적지 않음. 댓글 분위기가 비꼬는 듯한 느낌이 아쉬움. 이 최적화가 궁극의 솔루션 시대는 아니지만, 에너지 사용량 감소 효과가 더 강조됐으면 함

    • 인터넷 트래픽 대부분이 동영상 스트리밍임. 웹페이지에서 몇 메가 최적화해봐야 티도 안 남. 효율성 자체는 논의 필요하지만, 모든 영역에서 최적화하는 노력이 정작 최적화가 필요한 분야에 자원을 소모할 수 있음
    • 이건 낙과도 아님. 웹페이지 1~2mWh 아낄까 최적화하는 동안, 검색엔진 한 번 쿼리할 때 100배, 챗봇 한 번은 1만배 더 씀. 캐싱이나 lazy loading으로 상당 부분 완화되고 있음
    • 페이지 크기 줄이기에 신경 쓰는 건 거의 쓸데없는 짓임. 연간 웹서핑으로 쓰는 전기량을, 안전상 10배로 잡아도 햄버거 하나 만드는 데 드는 에너지보다 한참 적음. 오히려 개발자가 일주일 동안 최적화 대신 샐러드 한 끼 먹는 게 환경 영향이 큼
    • 완전 동의함. 예전에 BBC 갔다가 작은 텍스트 기사 하나로 캐시에 120MB나 저장되는 걸 보고 충격받음. 쓸데없이 많은 에너지와 낭비 문화를 조장함. 내 웹사이트도 최대한 미니멀하게 만들었고, 유튜브 업로드도 4K 대신 1080P만 씀. 4K, 8K는 굳이 존재할 필요가 없음. 사람들은 흔히 태양광을 몇 MW 추가하는 이야기만 하는데, 사실 '더 적게 생산'하는 노력이 얼마나 좋을지 상상해봐야 함. 56K 모뎀 시절 작은 웹 규모가 그립고, 어디선가 중간점이 있었을 텐데 지금은 훨씬 지나쳐버림
    • 사람들이 신경 끄는 건 결국 본인에게 직접적인 영향이 미치기 시작하면 일어남. 나 역시 환경을 고려하는 편임. AI가 더 나쁘다는 반론도 있는데, 사실 AI도 이런 무거운 페이지를 크롤링함. 그리고 14kb 기준은 모바일 평균 페이지 페이로드 대비 1%도 안 됨
답변달기