(번역) 2024년 팽창하는 자바스크립트

원문 : https://tonsky.me/blog/js-bloat/

저는 최신 프런트엔드 개발에서 조금 멀어져있던 상태였습니다. 그러던 중 웹 페이지의 평균 크기가 수 메가바이트에 근접한다는 웹 팽창에 대한 글을 본 기억이 났습니다!

저는 웹 페이지의 평균 크기가 3MB라면, 자바스크립트 번들은 1MB 정도는 되어야 한다는 생각으로 지금까지 살아왔습니다. 당연히 콘텐츠가 여전히 대부분의 크기를 차지해야 하지 않을까요?

자, 이를 알아낼 수 있는 유일한 방법은 직접 해보는 것뿐입니다. 현실로 들어가 보시죠!

저는 이 글을 2024년에 작성하고 있으니, 몇 년 후에 속편이 나올 수도 있겠죠?

측정 방법

• macOS 기반의 파이어폭스 (그러나 어느 브라우저에서라도 동일해야 합니다)
• 시크릿 모드가 아님 (앱 내의 수치를 확인하고 싶었고, 실제 일상 경험과 비슷할 가능성이 더 높습니다)
• 모든 익스텐션 비활성화
• 자바스크립트만 확인
• 비압축
• 서비스 워커 활성화 (다시 한번 강조하면, 더 실제 환경에 가깝기 때문입니다)
• 모든 캐시 비활성화 (콜드 로드)

왜 자바스크립트만 확인할까요? 콘텐츠는 사이트마다 아주 다양하지만(유튜브의 비디오가 당연히 슬랙의 텍스트 메시지보다 무겁겠죠), 자바스크립트는 "상호작용의 복잡성"을 측정하기 위한 보편적인 지표입니다.

주요 목표는 브라우저가 코드를 구문 분석하고 실행하는 데 얼마나 많은 작업을 수행해야 하는지를 평가하는 것입니다.

몇 가지 기준을 설정하기 위해 이 블로그부터 시작하겠습니다.

위 수치는 0.004MB입니다. 이를 직접 재현하기 위해 설정해야 하는 모든 중요한 요소를 함께 강조 표시해 두었습니다.

랜딩 페이지

자, 랜딩 페이지와 상호작용이 없는 앱처럼 간단한 것부터 시작해 보겠습니다.

위키피디아처럼 약간의 상호작용이 있는 일반적인 페이지는 0.2MB 정도로 아래와 같은 결과가 나왔습니다.

Linear는 3MB로 이렇게 약간 증가하기도 합니다.

명심하세요. 이미지, 비디오, 심지어 스타일을 모두 제외한 값입니다! 오직 자바스크립트만 측정했습니다.

Zoom은 6MB로 안 좋은 랜딩 페이지입니다.

Vercel도 6MB로 유사합니다.

네, 랜딩 페이지일 뿐입니다. 앱도 없고, 기능도 없고, 호출도 없음에도 6MB의 자바스크립트가 필요합니다.

하지만 Gitlab은 13MB로 훨씬 더 나쁩니다.

아직 랜딩 페이지만 확인했을 뿐입니다.

대부분 정적인 웹사이트

정적인 텍스트를 보여주는 것보다 간단한 건 없습니다. Medium은 이를 위해 3MB가 필요합니다.

Substack은 4MB입니다.

더 진행해볼까요?

Quora는 4.5MB입니다.

Pinterest는 10MB입니다.

Patreon은 11MB입니다.

이 모든 것이 정적 페이지를 확인한 결과입니다...

검색

앱의 상호작용이 대부분 검색으로 제한되는 경우, 검색어를 입력하면 결과 목록이 표시됩니다. 이러한 앱은 얼마나 무거울까요?

StackOverflow는 3.5MB입니다.

NPM은 4MB입니다.

Airbnb는 7MB입니다.

Booking.com은 12MB입니다.

"하지만 Niki, 예약은 복잡한 과정이잖아요! 이 UI들을 보세요! 이 모든 필터와 사람들이 내가 찾는 장소를 예약하고 있다는 팝업창을요!"

네, 알겠습니다. 그럼 좀 더 간단한 구글의 경우를 봅시다. 구글은 어떨까요? 한 개의 입력창과 링크 목록만 있습니다. 그렇죠?

음, 무려 9MB나 필요하군요.

단지 링크 목록만 보여줄 뿐인데도요.

하나의 상호작용만 있는 앱

구글 번역기는 두 개의 텍스트 박스일 뿐입니다. 이를 위해 2.5MB가 필요합니다.

ChatGPT는 한 개의 텍스트 박스입니다. 7MB입니다.

물론 ChatGPT는 복잡합니다. 하지만 브라우저가 아닌 서버에서요!

비디오

Loom은 7MB입니다.

YouTube는 12MB입니다.

이를 사람들이 성능을 정말 중요시하는 서비스와 비교해 보겠습니다. Pornhub은 1.4MB입니다.

오디오

아무래도 오디오 서비스는 어떤 경우에든 12MB를 필요로하나 봅니다.

SoundCloud입니다.

Spotify입니다.

이메일

네, 비디오랑 오디오는 아마 무겁겠죠(우리는 콘텐츠가 아닌 JS의 크기만 측정하고 있다는 것을 잊지마세요!). 간단한 사무 작업으로 넘어가 보겠습니다.

Google Mail은 고작(고작!) 20MB입니다.

고작 메일함일 뿐인데! 도대체 어떻게 앱에 대한 전체 커스텀 C++/OpenGL 렌더링을 제공하는 Figma만큼이나 큰 크기일까요?

메일도 복잡하다고 생각하시는 분들도 있을 겁니다. UI도 많고 상호작용도 많죠. 20MB 정도가 괜찮을까요?

아뇨!

무조건 아닙니다. FastMail을 보세요. 같은 서비스이지만 2MB밖에 하지 않습니다. 10배 더 적습니다!

생산성

그래요, 아마 이메일이 너무 복잡할 수도 있겠죠? 그러면 더 간단한 건 어떨까요? TODO 리스트처럼요?

Todoist를 보면 9MB입니다.

Dropbox에서 폴더 내의 파일 목록을 보여주기 위해 10MB가 필요합니다.

패스워드 목록은 어떨까요? 1Password에서는 13MB가 필요합니다.

카드 형태의 목록은 어떨까요? 0.5MB 더해서, Trello는 13.5MB가 필요합니다.

알겠습니다, TODO 목록이 엄청 복잡할 수도 있겠죠? 그러면 채팅은 어떨까요?

자, Discord는 21MB가 필요합니다.

문서 편집

문서 편집은 어렵습니다, 그렇죠? 커서 움직임과 동기화 등등을 모두 구현해야 하니깐요.

Google Docs는 13.5MB입니다.

더 간단한 걸 볼까요? Notion은 16MB입니다.

소셜 네트워크

소셜 네트워크 서비스에서 좋아요 버튼에 필요한 일반적인 코드 크기는 12MB입니다.

트위터는 11MB입니다.

페이스북은 12MB입니다.

틱톡은 12.5MB입니다.

인스타그램은 페이스북보다 10배는 더 적은 기능을 제공하는데도 왜인지 16MB가 필요합니다.

링크드인은 블로그일까요? 플랫폼일까요? 링크드인에는 메세징과 소셜 기능이 있습니다. 어쨌든 31MB가 필요합니다.

그나저나 링크드인의 전문가 네트워크에 여러분들을 추가하고 싶네요.

아주 거대한 웹사이트 - 자체 카테고리

일부 웹사이트들은 너무 어리석고 터무니없게 크다 보니 따로 분류해서 보여주는 게 좋을 것 같습니다.

태스크 관리 소프트웨어인 Jira는 거의 50MB입니다!

Electron 컴파일된 WASM 전체 또는 무언가를 제공하는 걸까요?

하지만 이게 끝이 아닙니다! Slack은 5MB를 더해 55MB입니다.

네, Slack은 채팅 서비스죠. 여러 사용자 목록과 메시지, 그리고 리액션 기능이 있기도 하고요. JS가 발명되기 전에 HTML 자체로도 구현했던 것이기도 하죠?

오늘날엔 이들이 55MB입니다. 마치 브라우저가 망가지기까지 얼마나 많이 더 추가할 수 있는지를 실험하고 있는 것 같네요.

마지막 케이스는 정말 놀라웠습니다. 왜인지 react.dev 사이트는 평범한 2MB로 시작하지만 앞뒤로 스크롤 할 때마다 끝없이 커집니다. 재미로 100MB(자바스크립트만!)까지 해봤지만, 원하는 대로 더 늘릴 수도 있습니다.

https://tonsky.me/blog/js-bloat/react@2x.mp4?t=1708621056

무슨 일이 벌어지고 있는 걸까요? 블로그 게시물 일부를 언로드하고 다운로드하더라도 어떻게 그렇게 빨리 커질 수 있는 걸까요? 텍스트 자체는 단지 50KB(0.05MB)일 뿐입니다.

업데이트: 이러한 동작은 사실상 일반적인 사용자 경험을 대표하지 않는다는 점에 주목하게 되었습니다. 일반적으로 임베드된 코드 에디터는 첫 번째 로드 이후에 캐시되고, 그 이후 로드부터는 디스크 캐시에서 제공됩니다. 따라서 스크롤을 하더라도 네트워크 트래픽이 발생하지 않지만, 이 100MB의 자바스크립트는 여전히 구문 분석되고, 평가되며 스크롤 할수록 계속해서 초기화됩니다.

얼마나 빠르게 성능이 저하되고 있을까요?

얼마나 귀여운지 좀 보세요! 2015년에 일반적인 웹 페이지 크기는 쉐어웨어의 버전인 Doom1(2.5MB)에 근접했습니다.

2024년에 Slack은 55MB를 불러옵니다. 이는 모든 리소스를 포함한 오리지널 Quake1의 크기입니다. 하지만 Slack은 자바스크립트 단독 크기만이죠.

채팅 앱에서요!

그나저나 10MB는 얼마나 큰 수치일까요?

솔직히 말하자면 이 수치들을 모두 입력한 후에, 10MB는 그다지 크거나 특별하게 느껴지지도 않았습니다. 마치 10MB 코드를 제공하는 것이 일반적인 것처럼요.

평균적인 코드 라인이 65자라고 가정한다면, 약 ~150,000 라인에 해당하는 코드를 전송하는 셈입니다. 모든 웹 사이트에서요! 때론 단순히 정적인 콘텐츠만 보여주더라도요!

그리고 이 코드들은 이미 압축된 것입니다. 따라서 이는 마치 한 웹 사이트당 300,000줄 이상의 코드 라인을 갖는 것과 같습니다.

하지만 현대의 웹 사이트가 그렇게 복잡할까요? SPA의 대표 격인 구글 맵은 현대 표준으로도 매우 작은 규모입니다. 여전히 4.5MB에 불과합니다.

구글의 누군가가 심하게 뒤처지고 있나 봅니다. 현대의 프런트엔드 기술을 활용한다면 최소 20MB가 되어야 하는데 말이죠.

만약 당신이 저처럼 "Figma는 정말 복잡한 프런트엔드 앱이라서 큰 자바스크립트 다운로드 크기를 가질 거야"라고 생각하신다면, 음, 그건 맞습니다만 그러면 Gmail은 Figma만큼이나 복잡하고, LinkedIn은 1.5배 더 복잡하고, Slack은 2.5배 더 복잡하게 됩니다. ¯_(ツ)_/¯

결론

다운로드 크기만을 의미하는 게 아닙니다. 저도 다른 분들만큼이나 빠른 속도를 중요하게 생각합니다. 하지만 코드(자바스크립트)는 브라우저가 구문 분석하고, 메모리에 보관하며 실행해야 하는 것입니다. 무료가 아니라는 뜻이죠. 그리고 사람들은 성능과 배터리 수명에 관해 이야기합니다...

구식이라고 할 수도 있지만, 저는 콘텐츠가 코드 크기보다 중요하다고 굳게 믿고 있습니다. 만약 당신이 10,000자의 블로그 게시물을 작성한다면, 이를 렌더링하기 위해 1000x배 더 많은 자바스크립트가 필요한 것은 아닙니다.

아래 사이트는 제대로 하고 있습니다.

0.1MB입니다. 이것도 충분하죠!

하지만 동일한 인터넷과 타임라인 상에서 Gitlab은 정적인 랜딩 페이지를 보여주기 위해 13MB의 코드와, 500,000줄 이상의 JS 코드라인이 필요합니다.

이런.