▲

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

 (tonsky.me)
2P by neo 4달전 | favorite | 댓글 1개

JavaScript의 부피 문제

  • 현대 프론트엔드 개발에 다소 문외한이었으며, 웹 페이지 크기가 수메가바이트에 이르는 웹 부피에 대한 기사를 기억함.
  • 평균 웹 페이지 크기가 3MB라면 JavaScript 번들은 대략 1MB 정도일 것이라는 인상을 받음.
  • 실제로 얼마나 되는지 확인하기 위해 실험을 진행함.

방법

  • macOS에서 Firefox 사용 (다른 브라우저에서도 동일할 것)
  • 익명 모드가 아닌 일반 모드 (앱 내부의 숫자를 보고 싶고, 실제 경험에 더 가까울 것이라고 생각함)
  • 모든 확장 프로그램 비활성화
  • JavaScript만 측정
  • 압축되지 않은 상태
  • 서비스 워커 활성화 (더 현실적인 상황을 위해)
  • 모든 캐싱 비활성화 (처음부터 로딩)

랜딩 페이지

  • 일반적인 약간의 상호작용이 있는 페이지 예: Wikipedia, 0.2MB
  • 약간 부풀어 오른 페이지 예: Linear, 3MB
  • 나쁜 랜딩 페이지 예: Zoom, 6MB; Vercel, 6MB; Gitlab, 13MB

주로 정적인 웹사이트

  • 정적인 텍스트 벽을 보여주는 것보다 간단할 수 없음.
  • Medium은 그저 이를 위해 3MB가 필요함.
  • Substack은 4MB, Quora는 4.5MB, Pinterest는 10MB, Patreon은 11MB가 필요함.

검색

  • 앱의 상호작용이 주로 검색으로 제한됨.
  • StackOverflow는 3.5MB, NPM은 4MB, Airbnb는 7MB, Booking.com은 12MB가 필요함.
  • Google은 단순한 텍스트 필드와 링크 목록을 보여주는 데 9MB가 필요함.

단일 상호작용 앱

  • Google Translate는 두 개의 텍스트 박스를 위해 2.5MB가 필요함.
  • ChatGPT는 하나의 텍스트 박스를 위해 7MB가 필요함.

비디오

  • Loom은 7MB, YouTube는 12MB가 필요함.
  • Pornhub는 성능에 신경을 쓰는 사이트로 1.4MB만 필요함.

오디오

  • SoundCloud와 Spotify 모두 12MB가 필요함.

이메일

  • Google Mail은 20MB가 필요함.
  • FastMail은 같은 기능을 제공하면서도 2MB만 필요함.

생산성

  • Todoist는 9MB, Dropbox는 10MB, 1Password는 13MB, Trello는 13.5MB가 필요함.
  • Discord는 채팅을 위해 21MB가 필요함.

문서 편집

  • Google Docs는 13.5MB, Notion은 16MB가 필요함.

소셜 네트워크

  • Twitter는 11MB, Facebook은 12MB, TikTok은 12.5MB, Instagram은 16MB, LinkedIn은 31MB가 필요함.

거대한 카테고리

  • Jira는 거의 50MB, Slack은 55MB가 필요함.
  • react.dev는 처음에는 2MB로 시작하지만 스크롤하면 무한정 커질 수 있음.

점점 빠르게 악화되는가?

  • 2015년에 평균 웹 페이지 크기는 Doom 1의 공유 버전(2.5MB)에 근접했음.
  • 2024년에는 Slack이 55MB를 차지하며, 이는 JavaScript만으로 원래 Quake 1의 크기와 같음.

10MB는 얼마나 큰가?

  • 10MB는 이제 그렇게 크거나 특별하게 느껴지지 않음.
  • 평균적으로 한 줄에 65자를 가정하면, 약 150,000줄의 코드를 각 웹사이트마다 전송하고 있음.
  • Google Maps는 현대 기준으로 비교적 겸손한 4.5MB임.

결론

  • 다운로드 크기만이 문제가 아님.
  • JavaScript는 브라우저가 파싱하고, 메모리에 유지하고, 실행해야 하는 것임.
  • 내용이 코드 크기를 초과해야 한다고 믿음.
  • Gitlab은 정적 랜딩 페이지를 표시하기 위해 13MB의 코드, 500K+ LoC의 JS가 필요함.

GN⁺의 의견:

  1. 웹 개발의 현재 상태에 대한 현실적인 진단으로, 웹사이트의 JavaScript 크기가 사용자 경험과 성능에 미치는 영향을 이해하는 데 도움이 됨.
  2. 프론트엔드 개발자들에게 최적화의 중요성을 상기시키며, 필요 이상의 자원을 사용하지 않도록 주의를 환기시킴.
  3. 웹사이트의 성능과 관련하여 개발자 커뮤니티 내에서 논의를 촉진할 수 있는 흥미로운 데이터를 제공함.
▲
neo 4달전  [-]
Hacker News 의견
  • 성인 웹사이트는 실제로 성능에 신경을 쓰는 사례로, Pornhub는 단 1.4MB의 데이터만 로드함. 이는 일부 기술 대기업들이 보여주는 성능에 비해 훨씬 우수함. Pornhub는 기본적인 UI/UX나 콘텐츠 전달에서 실수하는 경우가 거의 없음.
  • 뉴질랜드 시골 지역에서 로밍 서비스를 사용하며 웹 사용 경험이 매우 불편했음. Spotify의 오프라인 사용자 경험(UX)도 개선이 필요함.
  • 압축되지 않은 데이터를 왜 보고 있는지에 대한 의문 제기. 동적 앱인 Spotify와 Gmail은 페이지 로딩 후 빠른 탐색이 가능하다면 용서받을 수 있음. 일부 사이트들은 초기 로딩에 중점을 두어 사용자 경험을 저하시키고 있음.
  • 소프트웨어는 그것을 만든 조직을 반영함. 대부분의 데이터 전송은 실제 페이지 작동에 필요한 자바스크립트가 아닌 분석 및 제3자 스크립트임. 마케팅 팀이 이러한 사항에 대해 무지하거나 관심이 없음.
  • 웹 애플리케이션의 자바스크립트 파일 크기에 대한 분석이 누락되었음. 예를 들어 Google Translate는 단순한 상호작용 앱이 아니며, 많은 기능을 포함하고 있음에도 불구하고 2.5MB는 여전히 과도함.
  • Wordsandbuttons.online 웹사이트의 모든 페이지는 애니메이션과 상호작용에도 불구하고 64KB 미만임. 이는 제3자 의존성이 없는 정책 덕분임.
  • 자바스크립트의 과도한 사용뿐만 아니라 추적 스크립트의 양에 대해서도 논의할 필요가 있음.
  • 인기 있는 사이트들에서 로드하는 자바스크립트의 양을 비교함. 예를 들어, Pornhub는 YouTube보다 약 10배 적은 자바스크립트를 로드함.
  • 웹의 현재 상태는 매우 슬픔. 고속 인터넷 연결을 사용하는 사람들은 웹이 얼마나 느려졌는지 인지하지 못함. 광고/추적기 차단기를 사용하지 않는 것을 고려할 수 없음.
  • 복잡한 프레임워크와 추상화를 만들어 유지보수를 쉽게 하려고 하지만, 많은 개발자들이 자바스크립트 기초조차 모르고 있음. 웹 애플리케이션을 과도하게 공학화하고, 실제 언어를 숨기는 너무 많은 계층을 만듦. 자바스크립트 자체를 배우고 프레임워크보다는 순수 자바스크립트를 사용하면 자바스크립트 코드베이스를 크게 줄일 수 있음.
답변달기