2024년 자바스크립트 부피 팽창

 (tonsky.me)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 웹페이지가 실제 콘텐츠보다 훨씬 큰 비압축 JavaScript를 내려받는 사례가 흔해지면서, 단순 랜딩 페이지부터 업무용 앱까지 브라우저 부담이 커짐
  • 측정은 Firefox on macOS에서 확장 기능과 캐시를 끄고 JavaScript만 집계해, 이미지·동영상·스타일을 제외한 코드 실행 비용에 초점을 맞춤
  • Wikipedia는 0.2MB였지만 Linear 3MB, Zoom·Vercel 6MB, GitLab 13MB처럼 단순 페이지도 수 MB에서 두 자릿수 MB까지 올라감
  • 앱 영역에서는 Gmail 20MB와 FastMail 2MB가 10배 차이를 보였고, Jira 약 50MB와 Slack 55MB처럼 채팅·업무 도구의 코드량이 특히 큼
  • JavaScript는 다운로드 뒤에도 파싱·메모리 유지·실행 비용을 만들기 때문에, 작은 콘텐츠를 렌더링하려고 거대한 코드 번들이 필요한 구조는 성능과 배터리에 직접 부담이 됨

측정 방식과 비교 기준

  • 측정 환경은 Firefox on macOS였으며, 브라우저가 달라도 대체로 비슷할 것이라는 전제로 진행됨
  • 조건은 다음과 같음
    • 시크릿 모드가 아닌 일반 모드
    • 모든 확장 기능 비활성화
    • JavaScript만 측정
    • 비압축 크기 기준
    • Service Worker 활성화
    • 캐시를 비활성화한 콜드 로드
  • 콘텐츠는 사이트마다 편차가 커서 비교 대상에서 제외됨
    • YouTube의 동영상과 Slack의 텍스트 메시지는 본질적으로 크기가 다름
    • JavaScript는 상호작용 복잡도를 비교하기 위한 공통 지표로 사용됨
  • 핵심은 브라우저가 코드를 파싱하고 실행하기 위해 부담해야 하는 작업량임
  • 기준점으로 tonsky.me 블로그 자체는 0.004MB로 측정됨

랜딩 페이지와 정적 콘텐츠

  • 약간의 상호작용이 있는 일반 페이지 예시에서 Wikipedia는 0.2MB 수준임
  • 더 무거운 랜딩 페이지는 다음과 같음
    • Linear: 3MB
    • Zoom: 6MB
    • Vercel: 6MB
    • GitLab: 13MB
  • 위 수치는 이미지, 동영상, 스타일을 제외한 JavaScript 코드만의 크기임
  • 정적 텍스트를 보여주는 웹사이트도 수 MB의 JavaScript를 내려받음
    • Medium: 3MB
    • Substack: 4MB
    • Quora: 4.5MB
    • Pinterest: 10MB
    • Patreon: 11MB
  • 정적 페이지로도 가능해 보이는 콘텐츠 표시 작업에 큰 JavaScript 번들이 쓰이는 사례가 있음

검색과 단순 상호작용 앱

  • 검색 중심 앱은 질의 입력과 결과 목록 표시가 중심이지만, JavaScript 크기는 작지 않음
    • StackOverflow: 3.5MB
    • NPM: 4MB
    • Airbnb: 7MB
    • Booking.com: 12MB
  • Google 검색은 텍스트 필드와 링크 목록 중심의 화면임에도 9MB로 측정됨
  • 단순 입력 UI를 가진 서비스도 수 MB의 JavaScript를 사용함
    • Google Translate: 2.5MB
    • ChatGPT: 7MB
  • ChatGPT의 복잡성이 서버 쪽에 있다는 점과 별개로, 브라우저에는 7MB의 JavaScript가 내려옴

미디어 서비스와 이메일

  • 동영상 서비스의 JavaScript 크기는 다음과 같음
    • Loom: 7MB
    • YouTube: 12MB
    • Pornhub: 1.4MB
  • 오디오 서비스에서는 SoundCloud와 Spotify가 각각 12MB 수준으로 측정됨
  • 이메일 서비스에서는 차이가 크게 벌어짐
    • Google Mail: 20MB
    • FastMail: 2MB
  • FastMail은 같은 이메일 서비스 범주에서 Google Mail보다 10배 적은 JavaScript를 사용함
  • Google Mail의 20MB는 Figma처럼 커스텀 C++/OpenGL 렌더링을 포함하는 앱과 비교될 만큼 큰 수치임

생산성 도구와 문서 편집

  • 생산성 앱도 단순 작업 대비 JavaScript가 큼
    • Todoist: 9MB
    • Dropbox: 10MB
    • 1Password: 13MB
    • Trello: 13.5MB
    • Discord: 21MB
  • Dropbox는 폴더 안 파일 목록, 1Password는 비밀번호 목록, Trello는 카드 표시 같은 작업에 각각 10MB 이상을 사용함
  • 문서 편집 서비스는 두 자릿수 MB 수준임
    • Google Docs: 13.5MB
    • Notion: 16MB
  • 문서 편집에는 커서 이동과 동기화 같은 어려운 기능이 있지만, 비교 대상 서비스들의 JavaScript 크기는 여전히 큼

소셜 네트워크와 초대형 사례

  • 소셜 네트워크는 좋아요, 피드, 메시징 등을 위해 대체로 12MB 전후의 JavaScript를 사용함
    • Twitter: 11MB
    • Facebook: 12MB
    • TikTok: 12.5MB
    • Instagram: 16MB
    • LinkedIn: 31MB
  • LinkedIn은 블로그, 플랫폼, 검색, 메시징, 소셜 기능을 모두 포함하며 31MB로 측정됨
  • 매우 큰 웹앱 사례는 별도 범주에 가까움
    • Jira: 거의 50MB
    • Slack: 55MB
  • Slack은 사용자 목록, 메시지, 반응을 다루는 채팅 앱인데 55MB의 JavaScript를 내려받음
  • react.dev는 처음에는 2MB로 시작하지만, 스크롤을 반복하면 JavaScript가 계속 늘어나는 현상이 관찰됨
    • 예시로 100MB까지 증가시킬 수 있었음
    • 업데이트에 따르면 일반 사용자 경험에서는 임베디드 코드 에디터가 첫 로드 후 캐시에 저장되어 이후 네트워크 트래픽은 보이지 않음
    • 다만 스크롤할 때 100MB의 JavaScript가 계속 파싱, 평가, 초기화될 수 있음

10MB 코드가 뜻하는 것

  • 2015년 평균 웹페이지 크기는 Doom 1 셰어웨어 버전의 2.5MB에 가까워지고 있었음
  • 2024년 Slack은 JavaScript만으로 원본 Quake 1 전체 리소스 크기인 55MB에 도달함
  • 10MB의 코드가 일반적인 수준처럼 보이지만, 평균 코드 한 줄을 65자로 가정하면 약 15만 줄에 해당함
  • 이 코드는 이미 minify된 상태이므로, 원본 기준으로는 30만 줄 이상일 수 있음
  • Google Maps는 SPA의 대표 사례로 꼽히지만 4.5MB로 측정되어, 현대 웹앱 기준에서는 오히려 작은 편으로 비교됨
  • Figma는 복잡한 프런트엔드 앱이라 JavaScript 다운로드 크기가 큰 것이 자연스럽지만, Gmail은 Figma와 비슷하고 LinkedIn은 1.5배, Slack은 2.5배 수준임

브라우저가 치르는 비용

  • 문제는 다운로드 크기에서 끝나지 않음
  • JavaScript는 브라우저가 파싱하고, 메모리에 유지하고, 실행해야 하므로 지속적인 비용을 만듦
  • 콘텐츠 크기가 코드 크기보다 커야 한다는 기준에서 보면, 10K 문자짜리 블로그 글을 렌더링하기 위해 1000배 큰 JavaScript가 필요한 구조는 과도함
  • 좋은 예시로 언급된 사이트는 0.1MB의 JavaScript만으로 충분히 동작함
  • 같은 웹 환경에서 GitLab은 정적 랜딩 페이지 표시를 위해 13MB, 약 50만 줄 이상의 JavaScript를 필요로 하는 사례로 비교됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 10MB, 12MB 같은 것들과 성능을 진짜 신경 쓰는 Pornhub 1.4MB를 비교해보면 됨
    포르노 사이트들은 늘 실제 웹 하이테크였고 엔지니어링도 좋았지, 농담 같은 “테크” 대기업들과는 달랐음
    기본 UI/UX, 콘텐츠 전송, 상식적인 설계를 망친 기억이 거의 없음

    • 웹에서 단일 페이지 앱(SPA) 이 왜 그렇게 인기 있어졌는지 잘 이해가 안 됨
      실제 웹 애플리케이션에서는 페이지 새로고침이 원치 않는 동작이라는 이유만으로, 갑자기 모두가 웹사이트의 페이지 새로고침을 두려워하게 된 느낌임
      20년 동안 기업용 애플리케이션을 다뤘고, 태어나기 전 만들어진 시스템도 봤는데, React는 그런 시스템에선 이전의 끔찍한 클라이언트/서버 UI를 대체하는 최고의 프런트엔드였다고 봄
      Angular/Vue 등도 같은 맥락임. 하지만 일반 웹페이지에는 Gmail, Facebook처럼 상호작용과 실시간 갱신이 제품의 핵심인 경우가 아니면 거의 필요 없음
      Pornhub 같은 곳은 PHP로도 충분하고, 대부분의 웹사이트도 마찬가지임. HN이나 old.reddit.com을 아직도 선호하는 사람이 많은 걸 보면 되고, 더 느려진 새 Facebook보다 old.Facebook을 선호할 사람도 많을 것 같음
    • 포르노 사이트들이 쓰던 수많은 수상한 광고 기법도 기억남
      팝업, 팝언더, 가짜 콘텐츠로 비슷한 집계 사이트에 보내기, 콘텐츠 대신 제휴 사이트 열기, 검색 결과 오염시키기 같은 것들임
      포르노가 사람들이 말하는 만큼 기술을 이끄는 산업은 아니고, Betamax 대 VHS 관련 도시전설도 사실이 아니며 인터넷 혁신을 주도했다는 말도 과장임
      고품질 제품을 만드는 몇몇 플레이어는 있지만 업계 전체를 대표하진 않음. 링크 팜, 더미 콘텐츠, 복제 사이트, 허위 광고, 검색 결과 조작이 많음
      지금 상위 사이트들이 빠릿한 건 경쟁의 결과로 보임. UX가 나쁘면 공짜 포르노가 넘쳐나니 사용자가 바로 다른 곳으로 가고, 그래서 잔존율을 위해 최적화해야 함
      다른 웹사이트들은 주주, 콘텐츠 제공자, 독점 계약, 독점적 지위 같은 다른 유인이 있어서 사용자 경험을 그만큼 최적화하지 않아도 됨
    • 그 분야에서 일해봤는데, 성인 엔터테인먼트가 강하게 최적화되는 주된 이유 중 하나는 인터넷이 느린 국가의 사용자가 많기 때문임
      비디오 전송, 라이브 방송(예전엔 Flash, 지금은 WebRTC), 페이지 크기 등 온갖 것들을 최적화하는 데 셀 수 없이 많은 시간을 씀
    • playboy.com/app은 Pornhub보다 더 작아서 인증 상태에서 1.1MB, 비인증 상태에선 993KB임
    • YouTube도 “영상의 흥미로운 구간” 기능을 그대로 베껴갔음

  • 왜 압축 전 데이터를 보고 있는지 궁금함. 나쁜 예시로 든 몇몇 사이트도 압축하면 GMaps의 1.5MB보다 쉽게 작아짐
    Spotify나 GMail 같은 동적 앱은 페이지 로드 후 탐색이 빠르다면 괜찮다고 봄
    시작 시 업데이트에 몇 초 걸리는 Discord 같은 편이, 클릭할 때마다 최대 2초씩 기다리게 하는 GitLab보다 낫다
    요즘의 콜드 스타트와 정적 렌더링 우선순위가 일부 사이트에서는 오히려 경험을 망친다고 봄
    실험 삼아 GitHub에서 파일 트리를 탐색해보면, 내 기기에서는 GitHub의 다른 부분보다 훨씬 빠릿함. 우연히도 이 부분은 정적 렌더링이 아닌 거의 유일한 부분 중 하나임
    매일 수백 개의 GitHub 페이지를 클릭하는데, 파이프라인 하나 보려고 매번 전체 푸터를 다시 받게 하지 말고, 한 번 엄청난 양의 JavaScript를 보내고 가능한 한 많이 캐시해줬으면 함
    [1]: GMail과 Spotify는 예시일 뿐이고 실제로 쓰진 않음

    • 압축은 전송에는 도움이 되지만, 기기는 여전히 그 코드를 전부 파싱해야 함
      도달성 논의에서 이 문제가 자주 나오는데, iOS와 Android의 CPU 성능 격차가 크고, 대중이 많이 쓰는 저가형 기기까지 보면 오늘 팔리는 새 Android 기기가 2014년 iPhone보다 느린 경우도 있음
      개발자들이 최신 iPhone이나 플래그십 Android만 쓰면 코드 비대화가 중간 사용자에게 얼마나 큰 영향을 주는지 놓치기 쉬움
      https://infrequently.org/2024/01/performance-inequality-gap-...
    • 단일 페이지 로드에서도 스크립트를 압축 해제하고 사용하는 데 시간, 메모리, 디스크 공간, 전력이 듦
      캐싱은 다운로드와 압축 해제에 드는 전력·시간 비용은 줄여도, 실제 사용 비용은 없애지 못함
      개인적인 경험칙으로는 압축 전 JavaScript가 클수록 마우스를 움직이거나 키를 누르거나 스크롤할 때 CPU가 계속 실행하는 코드가 많아짐
      약간의 시간 효율을 포기하고 전력 효율을 얻는 쪽이 낫고, CSS로 대체할 수 있는 곳에서는 예쁜 동작보다 정적인 쪽을 선호함
      혹은 진짜 더 큰 문제는 클릭으로 URL이 다른 페이지로 이동하는 것 말고도 여러 동작에서 파일을 더 내려받는 사이트일 수 있음. 이는 숨은 비대화이고 아카이빙에도 매우 나쁨
      JavaScript로 주소창 URL은 그대로인데 다른 “페이지”가 보이게 만들지 않았으면 함. 이것도 아카이빙에 정말 나쁨
      또 다른 경험칙은, 압축 전 JavaScript가 클수록 보관된 사이트 버전이 제대로 동작할 가능성이 낮아진다는 것임
    • GitHub 파일 트리가 GitHub의 다른 부분보다 빠릿하다는 건 사실이지만, 그 부분은 느린 연결에서는 동작하지 않는 유일한 부분이기도 함
      지난주 인터넷이 느렸는데 GitHub 웹사이트에서 파일을 클릭하면 스크립트로 로드하려다 실패해서 파일 트리가 말 그대로 안 됐음
      대신 파일 URL을 복사해서 브라우저 주소창에 붙여넣으면 제대로 로드됨
    • Gmail은 끔찍함. 나만 그런지 모르겠지만 메일을 읽음 처리한 뒤 탭을 닫기 전에 20초를 기다려야 함. 안 그러면 읽음 상태가 저장되지 않음
      Spotify는 네트워크 연결성 문제가 큼. 앨범을 다운로드해도 네트워크가 바뀌면 완전히 패닉에 빠짐. 계속 온라인 상태를 유지하려는 시도보다 그냥 오프라인 모드가 나음
    • 지금 GitHub는 “Pjax”나 HTMX 스타일 기법의 최악 사례에 가까움
      그걸 보고 해당 아키텍처 전체를 판단하긴 어렵고, 아주 나쁜 SPA 하나를 가리키며 모든 SPA가 별로라고 말하는 것과 비슷함

  • 모든 소프트웨어는 그것을 만든 조직의 모습을 반영함
    전송되는 데이터의 대부분은 페이지 동작에 실제 필요한 JavaScript가 아니라 분석 도구와 각종 서드파티 스크립트일 가능성이 큼
    “elephant” 범주만 React 같은 지연 로딩 모듈에 해당함
    이런 것의 상당수는 이 문제를 모르거나 신경 쓰지 않는 마케팅 팀이 주도함
    개발자들은 Google Tag Manager나 다른 스크립트 삽입 서비스를 페이지에 붙였을 뿐인 경우가 많음. 어떤 경우엔 개발자가 그것조차 하지 않고, 운영 인프라의 프록시가 페이지를 수정함
    더 의미 있는 우려는 실제 일을 하는 사람보다 마케팅이 결과물에 더 큰 통제권을 가진다는 점일 수 있음
    “elephant” 페이지의 경우 비대화는 조직 자체에 있음. 몇몇 바보가 아니라 규모화된 바보들의 문제임

    • Google Tag Manager는 페이지 성능을 망치는 최고의 도구임
      이전 직장에서는 비기술 부서가 Google Tag Manager를 쥐고 있었고, 운영 페이지에 주입되는 쓰레기를 계속 감시해야 했음
      없애려고 정말 열심히 싸웠음
    • 예전엔 Google을 날렵하고 빠른 것과 연결해서 생각했음
      검색의 Google은 Yahoo보다 그랬고, Chrome도 출시 당시 IE/Firefox보다 그랬음
      Chrome 자체는 UI가 거의 없었고, 그게 기능이었음

  • 최근 뉴질랜드 로드트립에서 돌아왔는데, 시골 지역 상당수는 휴대폰 신호가 거의 없거나 아예 없음
    로밍까지 겹치면 한 겹 더 느려지는 느낌이라 많은 웹을 쓰기가 정말 힘들었음
    Spotify PM이 있다면 오프라인 UX를 검토해줬으면 함. 오프라인은 프리미엄의 핵심 기능 중 하나인데, 실제로 앱을 오프라인에서 쓰려 하면 여러 면에서 너무 별로임

    • 오프라인은 불안정한 인터넷보다 훨씬 나음
      Spotify가 인터넷이 있다고 판단하면 모든 컨텍스트 메뉴 내용을 서버에 물어보고, 몇 초 동안 응답을 기다리다가 어떤 때는 메뉴 표시를 포기하고 어떤 때는 오프라인 모드였으면 즉시 됐을 동작으로 되돌아감
      이 플레이어가 정말 싫음
    • Spotify는 적어도 iOS에서 온라인/오프라인 이분법에 빠진 것 같음
      지연 시간이 아주 높거나 손실이 많은 중간 상태에서는 실제로는 오프라인처럼 동작해야 하는데 Spotify는 온라인이라고 생각함
      다만 이런 문제는 매우 흔하고 Spotify만 실패하는 건 아니며, 올바른 임계값을 정하기 어렵긴 할 것임
    • 런던에 사는데 보통은 어디서나 신호가 좋음. 하지만 지하철망은 예외이고 5G를 배포 중이지만 아직 완전히 깔리진 않았음
      Spotify는 왜 신호가 없을 때 앱이 뭔가를 로드하는 데 30초나 기다리게 하는지 모르겠음. 다운로드해둔 팟캐스트를 계속 듣고 싶을 뿐임
    • Spotify 오프라인 모드가 너무 짜증 나서, 직접 오프라인 우선 iOS 음악 앱을 만들기 시작했음
    • 오프라인 모드로 되돌아가는 타임아웃 값을 더 공격적으로 잡으면 될 것 같음
      어떤 공학적 결정 때문에 이런 시나리오의 가중치를 재는 일이 그렇게 복잡해졌는지 궁금함

  • 이 글은 특히 실제 웹 애플리케이션에서 JavaScript 파일이 왜 그렇게 큰지 분해해서 보지 않는다는 점을 완전히 놓치고 있음
    예를 들어 Google Translate는 자세히 보면 한 번 상호작용하고 끝나는 앱이 아님. 사전, 대체 제안, 음역, 발음, 여러 입력 방식 등이 있음
    그런 점을 감안해도 2.5MB는 너무 크고, 일부 선택 기능은 지연 로딩할 수 있고 그래야 한다고 보지만, 지금 글은 너무 게을러서 더 깊은 논의에 별 도움이 안 됨

    • 그런 것들은 거의 초기 번들에 들어 있지 않지 않나? 대부분 서버에서 오는 데이터일 것임
      if data.transliteration show icon with audio embed에 JavaScript가 얼마나 필요하겠음?
    • 글 자체를 까고 싶진 않지만, 스크린샷 로딩이 느린 게 웃기긴 했음
      이미지가 클 수 있고 많았으니 이해는 되지만, 약간 아이러니했음
    • 대부분의 앱이 최적화 여지는 분명 있지만, “텍스트 박스 하나 보여주려고 JavaScript 몇 MB라니” 식으로 과도하게 단순화하면 비교가 완전히 쓸모없어짐

  • 여기서의 함의가 “JavaScript가 너무 많다”라는 건 알지만, 이 중 얼마나 많은 부분이 순수한 추적용 쓰레기인지도 이야기해야 함

    • 거의 모든 회사의 브랜드 사이트에는 보통 마케팅과 UX 피드백 수집을 위한 추적·분석 라이브러리가 깔려 있음
      더 나쁜 건 일부가 호스트 코드에 묶이지 않고 외부에서 가져와져서 지연 시간과 잠재적 보안 위험을 늘린다는 점임
    • 이전 직장에서 Google Tag Manager와 전쟁을 벌여야 했음
      개발자 개입 없이 마케터가 웹 애플리케이션에 아무 쓰레기나 주입하게 해주는 도구였음
      관계도 좀 망가졌고 이기지도 못했으며, 성능은 여전히 형편없음
      그다음 성능 문제를 일으키는 건 지도와 차트 같은 무거운 라이브러리들이고, 보통은 똑똑한 지연 로딩으로 해결됨
      직접 겪은 것들로는, 아주 작은 기능인데도 시작 시 QR 코드 스캔 라이브러리와 지도 라이브러리를 로드한 경우, 모든 국제화 문자열을 시작 시 폭포식 요청으로 받아 어떤 JS도 실행되기 전에 막힌 경우, Zendesk가 페이지 성능을 완전히 망가뜨렸지만 상부 지시라 지연 로드만 걸 수 있었던 경우가 있음
      그다음은 DOM 요소나 재렌더링, 폭포식 요청을 너무 많이 유발하는 잘못 설계된 코드임
      마지막으로 앱 수준 코드 크기가 오는데, 이것도 지연 로딩으로 고칠 수 있지만 애플리케이션이 아주 거대해지기 전에는 보통 필요하지 않음
    • 광고 차단기를 켜고 테스트하면 쉬움
      예를 들어 GitLab 랜딩 페이지는 추적 스크립트를 막자 13MB에서 “겨우” 6MB가 됨
      마케팅 부서는 항상 소프트웨어 비대화를 두 배로 늘릴 것임
    • 그래도 악질 추적 코드 조각들이 메모리를 메가바이트 단위로 먹을 수는 없지 않나? 사용자 세션 데이터를 모아서 어딘가로 보내기만 하면 되는데

  • 인기 사이트들이 콜드 로드에서 얼마나 많은 JavaScript를 로드하는지 비교한 내용임. 주요 포인트는 다음과 같음
    PornHub는 YouTube보다 약 10배 적은 JS를 로드함(1.4MB 대 12MB)
    Gmail은 이해하기 어려울 정도로 footprint가 큼(20MB). Fastmail은 10배 가벼운 2MB이고, Figma는 더 복잡한 앱인데도 비슷한 20MB임
    Jira는 58MB라니 엄청남

    • Pornhub는 작아야 함
      Jira는 한 번 다운로드된 뒤 업데이트 전까지 오프라인 앱처럼 로컬에서 로드될 것임
      Pornhub는 시크릿 모드에서 실행될 가능성이 높아서 캐시가 도움이 안 됨
    • YouTube는 내게는 꽤 빠릿하게 느껴지지만, Figma는 웹 앱 중 일관되게 최악의 경험이었음
      Jira도 끔찍하고 느림
    • Figma는 WASM을 쓰기 때문에 전체 크기는 훨씬 큼: https://www.figma.com/blog/figma-faster/
    • 이메일 클라이언트에 왜 20MB JS가 필요한지 모르겠음
    • YouTube가 12MB라니, 대체 어떻게 그렇게 됨?

  • https://wordsandbuttons.online/의 모든 페이지는 애니메이션과 상호작용이 있어도 여전히 64KB 미만임
    예를 들어 이 페이지 https://wordsandbuttons.online/trippy_polynomials_in_arctang...는 51KB임
    코드도 전혀 경제적이지 않음. 80%는 약간씩 다른 복붙이고, 영리하게 줄이려는 시도도 없음. 전부 오래된 바닐라 JS이고 압축도, 공백 제거도 없음
    “View page source”로 열면 코드가 완전히 읽을 수 있는 상태임
    비결은 의존성 0 정책임. 서드파티도 내부 의존성도 없음. 필요한 코드는 HTML 파일과 함께 모두 받음
    역설적으로 장기적으로는 복붙이 비대화의 원인이 아니라 방지책임

    • 최소한 여백은 좀 추가할 수 있을 듯함
      모바일에서는 가장자리가 말 그대로 안 보임
    • 의존성과 “현대적” JS 도구로도 같은 일을 할 수 있음
      의존성 자체가 원인이 아니라 증상임. 웹사이트와 회사들이 더 이상 비대화를 줄일 유인을 갖지 않으니, 중복 의존성이 거의 정리되지 않는 것임

  • 2015년의 The Website Obesity Crisis 글 [1]이 떠오름. 그 이후 [2] 상황은 더 나빠졌고, 벌써 거의 10년이 지났음
    앞으로 10년 뒤에는 2015년쯤의 PC로 웹 탐색이 불가능해질 거라고 말하는 게 어리석은 걸까? 아무것도 바뀌지 않으면 그렇게 보임
    2013년 구형 MacBook에 최신 Firefox를 올려도 https://civitai.com 페이지의 23.98MB JavaScript를 감당하지 못하고, 이 재앙 같은 웹 프런트엔드를 렌더링하려다 30초 정도 멈춤
    웹만의 문제가 아님. 모바일 올인원 앱들도 너무 커져서 2013년 폰으로는 마찬가지로 로드가 안 되고, 그중 절반은 웹 기술 스택 위에 작성돼 있음
    예산이 큰 회사들이 왜 네이티브 애플리케이션을 쓸 여유가 없는지 모르겠음
    [1] https://idlewords.com/talks/website_obesity.htm
    [2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

  • 웹의 상태가 매우 슬픔
    광섬유 연결을 쓰는 대부분의 사람은 웹이 얼마나 느려졌는지도 못 느낌
    하지만 아직 2Mbps 연결에 있으면 정말 끔찍함. 내가 그런 상황이고, 고통스럽다
    그래서 광고/추적 차단기를 쓰지 않는 건 아예 고려할 수 없음
    Ublock Origin을 켠 상태로 이 테스트를 보고 싶음

    • 나도 보고 싶음
      이 코드 대부분은 사용자 추적과 광고 관리용일 것 같음
    • 2Mbps 연결이라면, iPhone 3나 첫 Nexus 폰에서 현대 앱을 쓰면 무슨 일이 생기겠음?
      더 좋고 빠른 컴퓨터와 네트워크 속도가 생겼는데도 앱과 웹사이트를 계속 더 작게 만드는 데 집중해야 한다고 생각하는 건지 이해가 안 됨
    • 새 Raspberry Pi는 과거 스마트폰과 경쟁하고, 그 스마트폰들은 또 예전 서버와 비슷한 연산 성능을 가졌음
      무어의 법칙 덕분에 개발자들은 최적성을 희생하고 더 많이 밀어붙이며 빠르게 움직일 수 있었고, 이런 경우가 많음
    • 광섬유 연결을 쓰는 대부분의 사람이라니? 돈 있는 사람도 광섬유가 없는 경우가 많을 것 같고, HN에서도 확실히 대부분은 아닐 듯함
답변달기