▲

49MB 웹페이지

 (thatshubham.com)
2P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • 뉴욕타임스 웹사이트의 한 기사 페이지가 422개의 네트워크 요청과 49MB 데이터 전송을 발생시키며, 단순한 기사 열람조차 과도한 리소스를 요구함
  • 페이지 로딩 과정에서 수십 개의 광고 입찰 요청과 추적 스크립트가 동시에 실행되어, 브라우저 CPU와 배터리를 소모시키는 구조임
  • 이러한 적대적 UX 설계는 쿠키 배너, 구독 팝업, 자동 재생 영상, 화면 점유형 광고 등으로 이어져 사용자의 읽기 경험을 방해함
  • 광고 수익 극대화를 위한 ‘체류 시간’과 ‘노출률’ 중심의 비즈니스 모델이 독자 경험을 희생시키며, 엔지니어조차 이 구조에 얽매여 있음
  • 글은 텍스트 중심의 경량 뉴스 페이지(text.npr.org 등) 를 예시로 들며, 독자와 비즈니스가 공존할 수 있는 단순하고 존중받는 웹 경험의 복원을 강조함

49MB 웹페이지의 현실

  • 뉴욕타임스 웹사이트 접속 시 422개의 요청과 49MB 데이터가 발생, 페이지 안정화까지 2분 소요
    • 이는 Windows 95 전체 용량(28장의 플로피 디스크) 보다 크며, MP3 음악 10~12곡 분량에 해당
    • 단 몇 문단의 텍스트를 읽기 위해 앨범 한 장을 다운로드하는 셈임
  • 과거보다 하드웨어 성능이 비약적으로 향상되었음에도, 광고·트래킹 중심의 웹 프레임워크가 그 진보를 상쇄함

CPU 부하와 추적 구조

  • 뉴스 사이트는 프로그램형 광고 입찰 시스템을 브라우저 내에서 실행함
    • Rubicon Project, Amazon Ad Systems 등으로의 비동기 입찰 요청이 동시에 발생
    • 브라우저는 수 MB의 자바스크립트를 다운로드·파싱·컴파일해야 하며, 이는 메인 스레드 부하로 이어짐
  • 사용자는 텍스트를 요청했지만, 브라우저는 5MB의 추적 스크립트를 먼저 처리하고, 이후 광고 삽입이 이루어짐
  • 동시에 행동 추적 비콘(POST 요청) 과 보이지 않는 픽셀 리디렉션(doubleclick.net, casalemedia) 이 작동하여 교차 사이트 식별을 수행
  • 이러한 과정은 모바일 발열·배터리 소모를 유발하며, 사용자는 자신도 모르게 고빈도 데이터 거래 시장에 참여하게 됨

적대적 UX와 상호작용 비용

  • 페이지 진입 시 GDPR 쿠키 배너, 뉴스레터 구독 모달, 알림 허용 팝업이 연속적으로 등장
    • 사용자는 콘텐츠 접근 전 여러 번의 클릭과 스크롤을 수행해야 함
    • 이는 NNgroup의 ‘상호작용 비용(Interaction Cost)’ 과 ‘미니멀리즘 디자인’ 원칙을 위반
  • Economic Times 사례에서 사용자는 세 개의 모달을 닫고, 상단 배너를 넘겨야만 본문 접근 가능
  • 구글의 Core Web Vitals 기준에서도 이러한 침입형 인터스티셜은 SEO 감점 요인으로 명시됨

레이아웃 불안정과 광고 삽입

  • 독자가 문단을 읽는 도중, 광고 입찰이 완료되면 iframe 광고가 삽입되어 텍스트가 250픽셀 이동
    • 이는 누적 레이아웃 이동(CLS) 으로 측정되며, 이탈률 상승과 직결
  • 구글은 이 문제를 공식적으로 감점하지만, 자사 광고 제품이 동일한 문제를 유발하는 모순 존재
  • 자동 재생 영상은 스크롤 후에도 화면 하단에 고정되어 계속 재생되며, 닫기 버튼은 작고 클릭 영역이 좁음
    • 이는 Fitts의 법칙 위반 사례로 지적됨

모바일 환경의 공간 낭비

  • 평균 모바일 뷰포트 800px 중, 로고·공유바·브라우저 UI가 상당 부분을 차지
    • 실제 콘텐츠는 Guardian 페이지 기준 11% 만 표시
  • 광고·모달 89% vs 콘텐츠 11% 의 비율은 사용자의 시각적 피로와 스크롤 빈도를 증가시킴
  • ‘X’ 버튼을 광고 클릭 영역 근처에 배치해 오클릭을 유도하는 ‘fat-finger tax’ 전략도 존재
  • Jagran 등 일부 인도 뉴스 사이트는 앱 설치 유도 모달과 구독 팝업으로 본문 접근을 방해

개선 방안 제시

  • 콘텐츠 표시 전 3~4개의 닫기 동작을 강요하는 구조는 사용자의 인지 자원을 낭비
    • 팝업은 60초 체류 또는 50% 스크롤 이후에만 노출하도록 조정 필요
    • 쿠키 동의와 뉴스레터 구독을 하단 비차단형 섹션으로 통합 가능
  • 광고 슬롯은 고정 높이 컨테이너로 예약해 레이아웃 이동 방지
    • 예: min-height: 250px; background: var(--skeleton-loader);
    • 광고 실패 시 ResizeObserver로 비가시 영역에서만 축소 처리

경량 뉴스 사이트의 존재

  • text.npr.org, lite.cnn.com, cbc.ca/lite 등은 추적·모달 없는 경량 버전 제공
    • RSS 피드 기반 뉴스 소비도 여전히 활발
  • 이러한 사례는 단순하고 콘텐츠 중심적인 웹 경험에 대한 수요가 여전함을 보여줌

결론: 독자의 주의력은 자원

  • 현재 뉴스 UI는 독자를 포획 대상으로 간주하며, 광고 노출을 극대화하는 구조로 설계됨
  • 그러나 수익성과 접근성은 양립 가능하며, 엔지니어들도 이 구조에 불만을 품고 있음
  • 문제의 근원은 단기 CPM 중심의 비즈니스 인센티브
  • 독자의 주의력을 추출 가능한 자원으로 취급하는 시스템이 형성되었으며,
    RSS 사용·탭 닫기·이탈률 증가가 이에 대한 가장 강력한 저항 행위로 제시됨
▲
GN⁺ 16시간전  [-]
Hacker News 의견들
  • 우리 개발자들이 한 웹사이트를 열 때마다 약 750MB를 사용했음
    서버가 느리다는 티켓이 들어와 확인해보니, 페이지의 모든 동영상이 미리 일부씩 preload되고 있었음
    사무실이 데이터센터와 광케이블로 직접 연결돼 있어서 그나마 버텼던 것임
    웹 개발자들에게는 128kbit 이상의 네트워크 속도를 주면 안 된다고 생각함. 그 이상이면 전부 엉망이 됨
    • Chromium이나 Firefox 기반 브라우저의 Network 탭에서 3G나 4G 속도를 시뮬레이션할 수 있음
      CPU 제한 기능과 함께 쓰면 저사양 환경에서 사이트 성능을 점검하기에 좋음
    • 128kbit 제한은 마케팅 부서에도 적용해야 함. 추적 스크립트의 주범이 그들이기 때문임
    • 빠른 컴퓨터로 개발하더라도, 테스트는 Chromebook 같은 저사양 기기에서 해야 함
    • mcmaster.com처럼 문맥 인식 프리패칭이 잘 구현된 사이트를 참고할 만함
      느린 개발 서버를 쓰면 자연스럽게 불필요한 리소스를 줄이게 되는 훈련 효과가 있음
    • 예전에 text.npr.org 같은 텍스트 웹을 Lyx로 사용했음
      Gopher, Gemini, IRC 기반 Bitlbee 등 초저속 환경에서도 잘 작동했음
      Electron 앱 개발자들도 2GB RAM, 구형 Celeron급 PC에서 테스트해야 진짜 완성된 앱이라 할 수 있음
  • 실험 삼아 nytimes.com을 열어봤는데, 추적 픽셀과 광고 스크립트가 정말 끔찍했음
    그래도 전송량 기준으로 보면 44.47MB 중 36.3MB가 저널리즘용 동영상이었음
    즉, 과도한 광고보다는 영상 중심의 콘텐츠 구조가 문제인 셈임
    • 하지만 왜 모든 페이지에 자동 재생 영상이 있어야 하는지 의문임
      사용자가 클릭하기도 전에 36MB를 강제로 내려받게 하는 건 납득하기 어려움
  • 요즘 NYT는 완전히 바닥으로 치닫고 있음
    광고와 자바스크립트 덩어리 때문에 아예 읽지 않음. 대신 제목만 복사해 다른 사이트에서 읽음
    기본적으로 JavaScript를 꺼둔 상태로 브라우징하며, 광고는 거의 보지 않음
    JS를 끄면 페이지가 훨씬 빠르고, 개인정보 유출 위험도 줄어듦
    이런 방식이 비윤리적이라고 생각하지 않음. 사이트들이 먼저 불공정하게 행동했기 때문임
    • lite.cnn.com, text.npr.org, newsminimalist.com 같은 경량 뉴스 사이트들이 훨씬 쾌적함
    • NYT는 이런 사용자가 수익에 기여하지 않는 소수라는 걸 알고 있음
      차라리 방문하지 않는 게 그들에게도 이득일 정도임
    • 대부분의 사람들은 JS나 메가바이트 단위에 관심이 없음
      콘텐츠가 보이고 작동하면 그걸로 충분하다고 생각함
      NYT는 이런 ‘기술에 무관심한 다수’를 대상으로 함
    • YouTube가 앞으로도 대체 클라이언트를 허용할지, 아니면 DRM으로 막을지 궁금함
  • 2005년 우리 가족의 첫 브로드밴드 요금제는 월 400MB 제한이었음
    신문 산업의 근본 문제는 광고 기반 경제 모델 붕괴임
    과거엔 인쇄비만 독자에게 받고, 나머지는 광고로 충당했음
    하지만 지금은 Facebook Marketplace, Craigslist 등이 그 광고를 모두 가져감
    결국 뉴스는 틈새 상품이 되었고, 독자 데이터 판매는 마지막 몸부림임
    • 2010년에 120MB짜리 게임 업데이트를 받아서 부모님께 혼난 기억이 있음
      월 250MB 제한이었으니 지금 생각하면 믿기 어려움
  • 요즘 웹 개발은 정말 광고와 추적 지옥임
    HN처럼 JS 한 줄 한 줄을 신중히 다루는 사이트가 오히려 신의 선물처럼 느껴짐
    웹을 덜 비대하게 만들어야 함
    • 웹사이트가 메모리를 다 쓸 수 있다고 해서, 꼭 그렇게 해야 하는 건 아님
    • 페이지 위에 온갖 팝업과 오버레이가 덮여서 콘텐츠를 볼 수조차 없는 경우가 많음
      이런 UX로 돈을 벌 수 있을 리 없는데도 계속 반복함
  • Windows 95 설치 용량(약 40MB) 으로 비교하는 단위가 재밌음
    예전엔 Win95도 ‘비대하다’고 불렸는데, 지금 웹페이지는 그보다 훨씬 큼
    광고 자체보다 리소스 낭비와 산만함이 문제임
    JS를 켜자마자 화면이 요란해지면 바로 나가버림
    • 광고 산업의 경제 구조가 궁금함
      사용자 짜증을 유발하면서 얻는 몇 센트가 과연 가치가 있는지 의문임
      대부분의 사람들은 그냥 무관심하게 받아들이는 듯함
      나는 30대 후반 개발자로, ‘자유로운 인터넷’ 세대라 광고에 대한 인내심이 거의 없음
  • 항공사 웹사이트는 특히 심각함. Air Canada 같은 곳은 단순한 예약 과정조차 수 MB의 JS로 뒤덮여 있음
    예전 Amadeus 터미널처럼 명령줄 기반 인터페이스가 그립음
    웹이 다시 사용자 중심으로 돌아가려면 어떻게 해야 할지 고민임
    • China Southern 웹사이트는 최악이었음
      필드 라벨 오류, 잘린 placeholder, 중국어로 뜨는 date picker,
      좌석 선택 후 “선택 불가” 메시지 등 UX가 완전히 붕괴되어 있었음
    • Big Tech의 트렌드 추종에 빠진 개발자들을 비판해야 함
      단순한 HTML 폼으로도 충분히 쓸 만한 사이트를 만들 수 있음
      JS를 남용하는 건 세뇌된 결과임
    • 요즘 웹은 개발자 이력서 채우기용으로 만들어지는 느낌임
    • 광고 클릭 외의 새로운 수익 모델이 필요하다고 생각하지만, 대안은 아직 모르겠음
  • 기사에서 DNS 차단 리스트를 언급하지 않은 건 아쉬움
    나는 Hagezi ultimate list로 거의 모든 광고를 차단하고, 데스크톱에서는 uBlock으로 미세 조정함
    Google·Adobe 폰트 도메인도 직접 차단해 속도와 프라이버시를 개선했음
    • 정밀 테스트는 안 했지만, 필터 덕분에 트래픽이 1/10 이하로 줄어든 느낌임
  • 웹사이트에서 스크립트 실행을 허용한 결정은 90년대 최대의 실수였음
    사용자가 검증하지 않은 프로그램이 내 컴퓨터에서 실행되는 건 근본적으로 잘못된 구조임
    JS를 끄면 사이트가 망가지는 건 개발자들이 잘못 설계했기 때문임
    HTML과 실행 코드가 분리됐더라면 세상이 훨씬 나았을 것임
    • 단순히 읽기 전용 콘텐츠를 보기 위해 실행 코드를 다운로드해야 하는 건 말이 안 됨
      서버에서 렌더링해 결과만 보내면 충분함
    • 하지만 사용자들이 인터랙티브 웹을 원했기 때문에 스크립팅은 결국 도입됐을 것임
      49MB짜리 페이지는 그저 우선순위의 반영일 뿐임
      빠른 인터넷이 보편화된 지금, 대부분의 사용자는 문제를 느끼지 않음
  • 아이러니하게도, 이런 비판 글조차 Cloudflare Insights 같은 3rd-party 리소스를 불필요하게 불러옴
    나는 uBlock Origin 하드 모드로 이런 리소스를 완전히 차단함
답변달기