2017년에 웹 비대화가 느린 인터넷을 쓰는 사용자에게 어떤 영향을 미치는지 살펴봤다. 미국에서도 많은 사용자가 광대역 속도를 이용하지 못했다는 점 때문에 웹의 상당 부분을 쓰기 어려웠다. 지금도 미국 안팎에서 여전히 많은 사용자가 광대역 속도를 쓰지 못하고 있으며, 현대 웹의 상당 부분이 느린 인터넷을 쓰는 사람에게는 쓸 수 없다는 점은 마찬가지다. 다만 대역폭이 기하급수적으로 증가하면서(닐슨에 따르면 고급 회선 기준으로 연 50%씩 증가한다) 일반적인 사이트의 비대화 속도를 앞질렀기 때문에 이 문제는 2017년보다는 덜 심각해졌다. 물론 연결이 좋지 않은 사람들에게는 여전히 심각한 문제다.

웹 앱의 CPU 성능은 대역폭만큼 빠르게 늘지 않았다. 그래서 저속 회선을 쓰는 사람에게는 웹이 점점 더 열리고 있지만, 고속 회선을 쓰더라도 저사양 기기를 쓰는 사람에게는 오히려 웹이 점점 더 닫히고 있다. 예를 들어 Tecno Spark 8C에서 “현대적인” Discourse 기반 포럼을 열어 보면 브라우저가 가끔 그대로 죽어버린다. 죽지 않을 때 성능을 재 보면 반응성은 8 MHz 286에 1200 baud 모뎀으로 BBS에 접속하던 때보다 훨씬 떨어진다. 집 인터넷이 1Gbps인데도 메시지 제목을 불러오는 데 “필요한” 압축 페이로드 크기 2.6 MB는 비교적 가볍게 느껴진다. 전송된 페이로드 크기는 “겨우” 1000x 늘었을 뿐이며 이는 인터넷 속도 증가에 비하면 왜소하다. 하지만 CPU 속도에서는 정반대다. 웹 브라우징과 포럼 로딩 성능만 놓고 보면 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) CPU로는 Discourse를 감당하지 못한다. 이 CPU는 286보다 대략 100000x 빠르다. 어쩌면 1000000x 빠른 기기라면 충분할지도 모른다.

Tecno Spark 8C를 잘 모르는 분들을 위해 말하자면, 지금 새로 검색해 보면 Tecno Spark 8C 한 대를 나이지리아에서는 USD 50-60, 인도에서는 USD 100-110 정도에 살 수 있다. 중위 가구 소득 대비로 보면 이는 오늘날 미국에서 최신 아이폰을 사는 것보다 훨씬 더 큰 부담이다.

세계적인 기준으로 보면 Tecno Spark 8C는 저사양 기기라고 하기도 어렵다. 그래서 더 낮은 사양의 Itel P32(여전히 지금 사람들이 쓰는 가장 낮은 사양과는 거리가 멀다)에서의 성능도 함께 살펴볼 것이다. 여기에 M3 Max Macbook (14-core), M1 Pro Macbook (8-core), 그리고 크롬 개발자 도구에서 10x 스로틀링을 건 M3 Max도 비교한다. 모든 기기에 최대한 유리한 조건을 주기 위해 상당히 빠른 인터넷(1Gbps에, 부하 시 지연 시간이 동급 제품 대부분보다 낮다고 벤치마크된 와이파이 라우터)으로 테스트했다. 블로깅 및 마이크로블로깅 플랫폼(이 블로그, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon), 포럼 플랫폼(Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, myBB), 그리고 소규모 사업자가 흔히 쓰는 플랫폼(Wix, Squarespace, Shopify, 그리고 다시 WordPress)을 살펴볼 것이다.

아래 표에서 각 행은 하나의 웹사이트를, 레이블 열을 제외한 각 열은 하나의 지표를 나타낸다. 사이트 이름 열 다음에는 전송된 압축 크기(wire)와 압축 해제된 원본 크기(raw)가 있다. 이어서 기기별로 Largest Contentful Paint*(LCP*)와 메인 스레드 CPU 사용량(CPU)이 있다. 구글 문서는 LCP를 다음과 같이 설명한다.

Largest Contentful Paint(LCP)는 사용자가 페이지의 가장 큰 콘텐츠가 보이는 시점을 측정한다. LCP 지표 값은 사용자가 페이지 로드를 시작한 시점부터 페이지의 주요 콘텐츠가 렌더링될 때까지 걸린 시간을 나타낸다.

LCP는 구글 PageSpeed Insights에서 “코어 웹 바이탈” 지표 중 하나로 제시되기 때문에 흔히 최적화 목표로 삼는다. 이 문서에서 LCP 옆에 별표(*)를 붙인 이유는 크롬이 측정하는 LCP가 위 정의처럼 “콘텐츠” 기준이 아니라 화면의 큰 영역이 칠해지는 시점을 기준으로 하기 때문이다. 사이트들이 LCP에 맞춰 최적화하면서 사용자에게 전혀 쓸모없는 큰 화면 갱신을 먼저 띄우고 정작 실제 콘텐츠는 LCP 이후에 나타나게 하는 일이 흔해졌다. 그런 경우에는 쓸모없는 큰 갱신이 일어났을 때가 아니라 유용한 콘텐츠가 실제로 나타난 시점을 기준으로 타임스탬프를 잡았다. 테스트의 전체 세부 사항과 이 지표들을 선택한 이유는 부록에서 다룬다.

CPU 시간은 “코어 웹 바이탈”은 아니지만, 저사양 기기에서 체감하는 사용성과 상관관계가 매우 높아 간단한 지표로 여기에 제시한다. 자세한 논의는 부록을 참고하라. CPU 시간이 지표로서 유효한 이유 중 하나는 다른 모든 지표가 좋아도 CPU를 엄청나게 쓴다면 그 페이지는 저사양 기기에서 쓸 수 없기 때문이다. CPU를 100%로 30초 동안 쓴다면 페이지는 30초 내내 전혀 쓸 수 없고, 50%로 60초 동안 쓴다면 60초 내내 겨우 쓸 수 있는 수준이 된다. 또 다른 이유는 흔히 쓰이는 지표들에 비해 CPU 시간은 수치를 속이기가 어렵고, 사용자 체감에 영향을 주지 않으면서 수치를 크게 움직이는 최적화가 어렵다는 점이다.

아래 표의 색상은 크기와 속도 모두 초록에 가까울수록 작고 빠르고, 빨강에 가까울수록 크고 느리다는 뜻이다. 극단값은 검은색으로 표시했다.

첫눈에 표는 대체로 예상과 들어맞는다. 초고속 기기가 아니면 느리게 느껴지는 사이트들이 표에서도 느리게 나온다(즉 저사양 기기에서 max(LCP*,CPU)가 높다). 사람들이 어떤 플랫폼이 저사양 기기에서 가장 빠르고 느릴지 예측해보라는 설문(Mastodon, Twitter, Threads)에서도 대체로 WordPress와 Ghost가 Substack과 Medium보다 빠르고, Discourse가 phpBB, XenForo, vBulletin 같은 오래된 PHP 포럼보다 훨씬 느릴 것이라고 정확히 맞췄다. 구글 PageSpeed Insights(PSI) 점수도 뽑아봤지만(표에는 표시하지 않음) 그 점수와 체감의 상관관계는 그리 강하지 않았다. 몇몇 사이트는 페이지를 실제로 빠르게 만들지 않으면서도 PSI 점수만 잘 나오도록 최적화했기 때문이다.

이런 저사양 기기를 한 번도 써보지 않았다면, 대체로 많은 사이트가 아예 쓸 수 없고 무거운 것(앱이나 거대한 웹사이트)을 불러오면 충돌이 난다고 생각하면 된다. 무거운 앱에서 너무 무거운 작업을 해도 충돌이 난다. 리뷰에 따르면 PUBG 같은 3D 게임도 그럭저럭 돌릴 수 있다는 Tecno Spark 8C지만, 그렇다고 이 기기가 현대적인 텍스트 중심 소셜 미디어나 웹 포럼에서 글을 읽을 만큼 빠르다는 뜻은 아니다. PUBG에서는 40fps가 나오지만, 이런 사이트에서 스크롤할 때는 0.4fps도 안 나올 때가 쉽게 있다.

표에서 느린 기기를 쓰면 얼마나 많은 사이트가 쓸 수 없는지 알 수 있다. 10s+ CPU인 페이지는 모두 로드가 끝난 뒤에도 상당히 불편하다. 스크롤이 매우 끊기고 자주 초당 몇 프레임으로 떨어지며 때로는 그 이하로도 떨어진다. 링크를 탭하면 지연이 너무 길어 탭이 제대로 됐는지 알 수 없다. 다시 탭하면 첫 번째 탭이 처리되면서 두 번째 탭이 엉뚱한 동작을 하게 되는 악명 높은 상황이 생기지만, 기다리자니 원래 탭이 제대로 인식되지 않았거나(혹은 엉뚱한 위치에서 인식됐거나) 해서 결국 너무 오래 기다리게 된다. MyBB는 모바일 사이트를 제공하지 않아 구글에서 모바일 친화적이지 않다고 감점되지만, 실제로는 스크롤과 탭이 제대로 동작하기 때문에 이런 저사양 모바일에서 가장 빠른 몇 개 사이트를 제외한 모든 사이트보다 훨씬 쓸 만하다.

또 하나 알 수 있는 것은 기기별로 상대 성능 편차가 얼마나 큰가 하는 점이다. 예를 들어 M3/10과 Tecno Spark 8C를 비교하면, danluu.com이나 Ghost 같은 곳에서는 M3/10이 Tecno Spark 8C를 그럭저럭 비슷하게 근사하지만(danluu.com은 훨씬 너무 빨리 로드된다), Medium, Substack, Twitter에서는 Tecno Spark 8C가 CPU 기준으로 약 3배 느리고, Reddit과 Discourse에서는 4배 정도, Shopify에서는 오히려 10배 이상 빠르다. Wix의 경우 CPU 근사치는 비슷한데 Tecno Spark 8C의 LCP*는 3배 이상 느리다. 크롬이 컴퓨터에서 편리하게 느린 기기를 시뮬레이션할 수 있게 해주는 것은 좋지만, 크롬의 CPU 스로틀링(혹은 기본으로 제공되는 다른 옵션 조합)만으로는 실제 기기에서 나오는 결과와 꽤 다른 결과가 나온다. 자세한 이유는 이 글의 범위를 넘지만, 이 글에서는 느린 페이지는 기기가 느려질수록 초선형적으로 더 느려지고, 한 페이지에서의 느림이 다른 페이지에서의 느림을 잘 예측하지 못한다는 점만 기억하면 충분하다.

기기 중심이 아니라 사이트 중심으로 보면, Discourse, Medium, Reddit 같은 사이트는 빠른 M3와 M1 컴퓨터에서는 CPU를 그리 많이 쓰지 않지만 Tecno Spark 8C에서는 가장 느린 축에 속한다(Reddit의 CPU가 ∞로 표시된 이유는 아무 상호작용 없이 마냥 기다려도 ~90% CPU를 계속 쓰기 때문이다). Discourse는 상호작용을 조금 하거나 그냥 가만히 두기만 해도 가끔 브라우저 자체가 충돌한다. 예를 들어 Discourse를 로드하고 두 번 스크롤한 뒤 1~2분 정도 가만히 두었더니 브라우저가 죽은 적이 있다. 일관성을 위해 표에서는 페이지가 일단 로드됐으므로 FAIL로 표시하지 않았지만, 현실적으로 브라우저가 충돌할 정도로 무거운 페이지는 표에서 FAIL인 경우보다 사용자 경험이 훨씬 나쁘다. 웹 비대화가 느린 연결을 쓰는 사용자에게 어떤 영향을 미치는지 살펴봤을 때처럼, 웹의 상당 부분이 느린 연결을 쓰는 사람에게는 쓸 수 없었듯 느린 기기에서도 마찬가지다.

또 하나 보이는 패턴은 대체로 오래된 사이트가 더 빠르다는 것이다. 시각적으로 10~20년 동안 업데이트되지 않은 것처럼 보이는 사이트들이 가장 빠른 축에 속하는 경향이 있다. 예를 들어 가장 덜 현대화되고 가장 오래돼 보이는 포럼인 MyBB는 M3에서 Discourse보다 LCP* / CPU 기준 3.6x / 5x 빠르지만, Tecno Spark 8C에서는 그 차이가 19x / 33x이며, 전체 스케일링을 고려하면 Itel P32에서는 Discourse가 제대로 동작한다면 차이가 훨씬 더 클 것으로 보인다.

또 다른 예는 Wordpress(old)와 Medium, Substack 같은 더 새롭고 유행하는 블로깅 플랫폼을 비교한 것이다. Wordpress(old)는 M3 Max에서 Medium보다 LCP* / CPU 기준 17.5x / 10x, Substack보다 5x / 7x 빠르고, Tecno Spark 8C에서는 각각 4x / 19x, 20x / 8x 빠르다. Ghost는 눈에 띄는 예외로, Medium보다 1년 늦게 출시된 현대 플랫폼이지만 오래된 플랫폼과 경쟁할 만큼 빠르다(현대 WordPress도 논쟁의 여지는 있지만 예외로 볼 수 있다). 포럼 중에서는 NodeBB도 어느 정도 예외에 가깝다(자세한 내용은 부록 참고).

Discourse, Reddit, Substack처럼 페이지를 부분적으로 먼저 불러온 뒤 나머지를 동적으로 불러오는 현대적 기법을 쓰는 사이트는 표의 점수보다 실제 체감이 더 나쁘게 느껴지는 경향이 있다. 원칙적으로는 단순한 방식으로 구현하면 저사양 기기에서도 잘 동작하는 사이트를 만들 수 있지만, 실제로 동적 로딩을 쓰는 사이트는 너무 복잡해서 저사양 기기에서는 극도로 버벅인다. 예측 가능한 거리만큼 스크롤하기가 대체로 어렵거나 불가능해서 사용자가 실수로 너무 멀리 스크롤하면 추가 로딩이 발생해 페이지가 3s-10s 멈춰 버린다. 스크롤하면서 지나간 부분을 아예 제거해 버리는 페이지도 많은데, 그런 페이지는 사실상 쓸 수 없다. 페이지 검색 같은 기본 웹 기능도 대체로 동작하지 않는다. 이런 식의 동적 로딩이 걸린 페이지는 단순하고 빠른 ctrl/command+F 검색에 의존할 수 없고 자체 검색을 만들어야 한다. 그 품질은 천차만별이다(예전에는 구글 문서에서 꽤 잘 됐지만, 최근 몇 개월 혹은 1년 정도는 로딩이 너무 오래 걸려 문서를 열고 일부러 기다렸다가 검색해야 브라우저의 쓸모없는 기본 검색이 뜨는 걸 피할 수 있다. Discourse 검색은 저사양 기기는 물론 그리 빠르지 않지만 그렇다고 특별히 느리지도 않은 기기에서도 제대로 동작한 적이 거의 없다).

원칙적으로는 이렇게 로딩 시 엄청난 CPU를 태우는 현대 페이지들이 미리 작업을 해두면 이후 상호작용이 미리 작업을 덜 하는 페이지보다 더 빠르고 가벼워질 수도 있다(이런 페이지들을 옹호하는 흔한 논리다). 하지만 테스트한 페이지들에서는 그렇지 않았다. 초기 로드도 더 느리고, 이후 로드도 더 느리며, 로드가 끝난 뒤에도 더 느리다.

왜 미리 이렇게 많은 작업을 해두는 이론이 실제로는 나중에 더 빠른 경험으로 이어지지 않는지 이해하려면, 구글의 디스팅귀시드 엔지니어와 당시 Discourse 창립자(당시 CEO) 사이의 다음 대화가 잘 보여준다. 다음은 Discourse 창립자가 모바일 사이트를 대역폭은 스로틀링하되 CPU는 스로틀링하지 않은 노트북으로 테스트해야 한다고 말한 토론에서 나온 대화다.

• Google: *당신*도 느린 3G를 안 쓰잖아요. 이 두 설정은 함께 가야 합니다. 공감은 터널 속 iPhone XS 사용자 너머로 확장되어야 해요.
• Discourse: 문자 그대로 iPhone 6 이상의 어떤 폰이든 기본적으로 “평균적인” 노트북만큼 빠릅니다. 퀄컴이 자기 일을 얼마나 처참하게 못하는지 이해해야 해요. 믿기지 않으면 찾아보세요.
• Google: 믿을 필요 없어요. 알아요. 신경 쓰는 사람들은 다 아는 사실이에요. 제 요점은 빠른 연결을 가진 사람이 모두는 아니듯 빠른 폰을 가진 사람도 모두가 아니라는 거예요. 확실히 iPhone 6도 실제 웹사이트에서는 자주 CPU 바운드에 걸립니다. 하지만 그게 요점이 아니에요.
• Discourse: 우리는 수십 년 동안 무한한 CPU 속도를 향해 가고 있었고(데스크톱에서는 이미 5년 가까이 점근적으로 도달했죠), 우리가 절대 향하지 않을 것은 무한한 대역폭입니다. 중요한 것에 최적화하세요. 그리고 전 퀄컴에 전혀 공감 안 해요. 퀄컴 좆같아요, 자기 일 진짜 못해요. 망해서 회사가 있던 땅에 소금 뿌려서 아무것도 자라지 못하게 되길 바랍니다.
• Google: 모바일 기기는 대부분의 상황에서 대역폭 제약이 전혀 아닙니다. 지연 시간 제약이죠. 최신 아이폰조차 대역폭 제약에 걸리기 전에 CPU 제약에 걸립니다. MBP에서 4배 느리게 해도 결과가 꽤 괜찮으면 대체로 양호한 겁니다
• ...
• Google: 사용자가 100% iOS인가요?
• Discourse: 돈을 쓰는 영향력 있는 사용자들은 대체로 그렇다고 할 수 있죠... CPU 걱정은 무의미해요, iOS에서는 이미 사실상 무한하고, 퀄컴의 무능함에도 불구하고 그들의 창피한 SoC에서도 4년 안에 그렇게 될 겁니다

누군가 Discourse 창립자에게 “왜 그렇게 싫어하냐”고 묻자, 그는 이 Anandtech 리뷰의 Kraken과 Octane 벤치마크를 인용한 링크로 답한다. 해당 벤치마크에서 퀄컴 칩은 당시 애플 칩 성능의 각각 74%와 85%였다.

당시 Discourse 창립자이자 CEO였던 사람은 퀄컴의 모바일 성능이 창피한 수준이며, 그래서 퀄컴 엔지니어들이 모두 일자리를 잃어야 할 만큼 모욕적이라고 생각한다. 그가 인용한 수치로는 애플 대비 74%~85% 성능이다. 애플은 내가 보기에 역대급 성능 팀을 갖고 있다. 이견이 있을 수 있지만 최소한 세계 최고 수준의 팀이라고 봐야 한다. 그런데 역대급 팀의 74%~85%를 내는 제품이 일자리를 잃을 만큼 창피한 것이 된다. 이는

여기서 드러나는 두 가지 태도가 있는데, 많은 소프트웨어 개발자들에게서 흔히 보인다. 첫째, CPU 속도는 무한하며 CPU 최적화를 걱정할 필요가 없다는 생각. 둘째, 하드웨어에서 엄청난 속도 향상이 당연히 나와야 하며, 그걸 달성하지 못하는 유일한 이유는 하드웨어 엔지니어의 엄청난 무능 때문이라는 생각. 그래서 느린 소프트웨어는 하드웨어 엔지니어 탓이지 소프트웨어 엔지니어 탓이 아니라는 것이다. 도널드 커누스도 다음과 같이 비슷한 심정을 표현했다.

이 기회에 멀티코어 아키텍처라는 최근 흐름에 대한 개인적인 불만을 좀 쏟아내 보자. 내게는 하드웨어 설계자들이 아이디어가 고갈된 것처럼 보이고, 그저 몇몇 핵심 벤치마크에서만 더 빠르게 동작하는 기계를 내놓아 무어의 법칙 붕괴에 대한 책임을 소프트웨어 개발자에게 전가하려는 것처럼 보인다! 멀티스레딩 아이디어 전체가 “아이태니엄” 방식보다 더 형편없는 실패작으로 드러나도 전혀 놀라지 않을 것이다. 그 방식도 컴파일러가 사실상 불가능하다는 게 드러나기 전까지는 그렇게 대단할 것처럼 보였다. 이렇게 말해 보자. 지난 50년간 나는 천 개가 넘는 프로그램을 작성했고 그 중 규모가 상당한 것도 많다. 그 중 병렬성이나 멀티스레딩으로 눈에 띄게 개선됐을 프로그램은 다섯 개도 떠오르지 않는다. 분명 TeX 같은 프로그램에는 다중 프로세서가 아무 도움이 되지 않는다... 병렬성이 중요한 응용 분야가 존재한다는 건 안다. 그래픽 렌더링, 암호 해독, 이미지 스캔, 물리·생물학적 과정 시뮬레이션 등이다. 하지만 이런 응용은 모두 전용 코드와 특수 기법을 필요로 하며, 몇 년마다 크게 바뀌어야 한다. 그런 방법에 대해 TAOCP에 쓸 만큼 안다고 해도 내 시간은 대체로 낭비일 것이다. 곧 그 부분을 읽을 이유가 거의 없어질 테니... 내가 지금 쓰는 기계는 듀얼 프로세서다. 두 개를 동시에 쓰는 건 두 개의 독립적인 작업을 동시에 돌릴 때뿐이다. 그건 좋지만 일주일에 몇 분밖에 일어나지 않는다.

Discourse의 경우 하드웨어 엔지니어는 역대급 성능 팀의 90%를 달성하지 못하면 일자리를 가질 자격도 없는 창피한 존재이지만, 소프트웨어 엔지니어로서 MyBB 같은 그다지 최적화되지 않은 애플리케이션보다 3% 성능을 내는 것은 문제가 되지 않는다. 커누스의 경우 하드웨어 엔지니어들은 프로그래머가 거의 아무 작업도 하지 않아도 수십 년 동안 10년마다 100배 성능 향상을 안겨줬다. 그 속도가 느려지고 프로그래머가 새로운 하드웨어를 활용하기 위해 적응해야 하는 순간, 하드웨어 엔지니어들은 “아이디어가 고갈됐다”는 얘기를 듣고, 현재 하드웨어를 활용하기 위한 몇 가지 “새로운”(1970~80년대) 아이디어를 배우는 것은 시간 낭비라고 치부된다. 그리고 우리는 이전에 앨런 케이가 하드웨어 엔지니어를 “세련되지 못하고” “교육받지 못한” 이들로 치부하며 “진짜 엔지니어링”을 하지 않는다고 하고, 그의 “세련된” 아이디어를 들으면 1000배 빨라질 것이라는 주장을 논한 적이 있다.

프로그래머가 하드웨어가 모든 문제를 해결해 줄 것으로 기대하다가, 그게 일어나지 않으면 문제를 사용자에게 떠넘기며 프로그래머가 사용자를 위해 아무 것도 할 필요가 없다고 설명하는 일은 꽤 흔하다. 한 가지 물어볼 수 있는 질문은 프로그래머가 우리에게 얼마나 성능 향상을 안겨줬는가 하는 것이다. 알고리즘 개선으로 엄청난 속도 향상을 만든 사례도 있지만, 위에서 언급했듯 오늘날 가장 빠르게 성장하는 포럼 소프트웨어인 Discourse는 대략 1000000x의 성능 저하를 안겨준 것으로 보인다.

위에 드러난 또 다른 흔한 태도는 부유하지 않은 사용자는 중요하지 않다는 생각이다. 100% 사용자가 iOS냐는 질문에 Discourse 창립자는 “돈을 쓰는 영향력 있는 사용자들은 대체로 그렇다”고 답한다. Tonsky의 JavaScript Bloat 글 댓글에서도 같은 태도를 곳곳에서 볼 수 있다. 칵테일 파티용 발언처럼 “폰 앱은 수백 메가인데 왜 수 메가짜리 웹 앱을 가지고 호들갑이냐? 아프리카 굶주린 아이들이 안드로이드 앱은 받아도 웹 앱은 못 받는다고? 말도 안 된다”거나 “정말로 gitlab 사용자가 느린 기기를 쓸 정도로 가난할 리는 없지 않나, 진지하게 생각해 보자”(길이를 줄이기 위해 의역) 같은 말들이다.

하지만 아프리카에서 다운로드되는 앱 크기를 보면, 고급 기기를 쓰지 않는 사람들은 Facebook Lite(몇 메가) 같은 앱을 쓰고, 흔히 쓰는 앱 크기는 한 자릿수에서 낮은 두 자릿수 메가바이트 수준이다. 앱 제작자가 앱 크기를 신경 쓰는 이유는 여러 가지다. 하나는 폰의 전체 저장 공간 자체다. 실제 사용자가 앱을 설치하는 모습을 보면 새 앱을 하나 깔려고 이것저것 지우고 삭제하는 일이 흔해서, 크기가 작을수록 설치하기 쉽고 사용자가 공간을 확보하려 할 때 삭제될 가능성도 낮다. 또 하나는 앱 크기와 메모리 사용량에 대한 데이터를 보면(공개된 데이터를 알지 못하니 아는 분은 알려주세요), 큰 앱이 크기와 메모리 사용량을 늘리면 충돌이 늘어나 사용자 유지율, 성장, 참여도가 떨어지고, 반대로 크기와 메모리 사용량을 최적화하면 충돌이 줄고 유지율, 성장, 참여도가 개선된다.

Alex Russell은 iOS가 인도(14억 명 시장)에서 7%, 라틴 아메리카(6억 명 시장)에서 6%의 점유율을 가진다고 지적한다. Discourse 창립자는 이들이 “영향력 있는” 사용자가 아니라 중요하지 않다고 말하지만, 이들은 여전히 실존하는 사람들이다. Alex는 또한 윈도우 텔레메트리에 따르면 데스크톱 사용자의 대다수를 차지하는 사람들 중 대부분이 저사양 기기를 쓰고 있으며, 이는 현대 아이폰보다 느릴 가능성이 높다고 지적한다.

프로그래머 중 아무도 느린 기기를 쓰지 않는다는 얘기에 대해 말하자면, 물려받은 오래되고 느린 기기를 쓰는 사람들을 나는 많이 안다. 그들 중 많은 이는 가난해서 그런 것도 아니다. 그저(예를 들어) 자기 아이에게 초고속 기기가 왜 필요한지 이해하지 못할 뿐이고, 현대 웹의 상당 부분이 느린 기기에서는 얼마나 형편없이 동작하는지 모른다. 결국 “느린” 기기에서도 3D 게임을 할 수 있고(적절한 OS라면) 리눅스나 크로미엄 같은 코드베이스도 컴파일할 수 있는데, 왜 gitlab 같은 사이트와 상호작용하지 못하겠는가.

Discourse 창립자가 몇 년 안에 모든 안드로이드 사용자가 어떤 초고속 안드로이드 기기를 쓰게 될 것이라는 주장과 달리, 그의 발언으로부터 6년이 지난 지금, 전 세계에서 폰을 쓰는 거의 모든 사람이 고속 기기를 갖게 되기까지는 최소 10년, 쉽게는 20년 이상이 걸릴 것이다. Discourse의 시장 점유율을 찾아보면 극도로 성공적이며, 압도적인 차이로 세계에서 가장 빠르게 성장하는 포럼 소프트웨어로 보인다. 세계에서 가장 빠르게 성장하는 포럼 소프트웨어가 당시 리더가 “영향력 있는 돈을 쓰는 사용자”가 아니고 “무한한 CPU 속도”에 접근할 수 없는 사용자에 대해서는 딱히 신경 쓰지 않는다고 말할 의향이 있는 조직에 의해 만들어졌다는 것의 영향은, 이제 많은 포럼이 세계적인 기준으로 부유하지 않으면 살 수 없는 기기가 없는 사람들에게는 접근 불가능하다는 것이다.

만약 Discourse 창립자가 예외적인 경우라면 큰 문제가 아니겠지만, 그는 많은 프로그래머들이 암묵적으로 가정하고 있는 것을 그저 입 밖으로 낸 것뿐이며, 그래서 우리는 오늘날 많은 현대 웹사이트가 저소득 국가에서 최신 아이폰에 준하는 소득 대비 기기를 사면 쓸 수 없을 정도로 형편없는 것을 보게 된다.

Yossi Kreinen, Fabian Giesen, John O’Nolan, Joseph Scott, Loren McIntyre, Daniel Filan, @acidshill, Alex Russell, Chris Adams, Tobias Marschner, Matt Stuchlik, @[email protected], Justin Blank, Andy Kelley, Julian Lam, Matthew Thomas, avarcat, @[email protected], William Ehlhardt, Philip R. Boulain, David Turner에게 의견/교정/토론에 감사드립니다.

부록: LCP 속이기

위에서 LCP*를 쓰고 LCP를 쓰지 않았다고 언급했다. 이는 LCP가 기본적으로 가장 큰 변화가 언제 일어나는지를 측정하기 때문이다. 이 지표가 사용자에게 이득이 되지 않는 방식으로 의도적으로 왜곡되지 않았을 때는 훌륭한 지표였지만, 더 많은 사람이 이를 왜곡하면서 실제 사용자 경험과는 동떨어진 지표가 되었다. 덜 노골적인 경우, 사람들은 LCP는 개선하지만 실제 사용자 경험은 거의 혹은 전혀 개선하지 않는 작은 최적화를 한다.

더 노골적인 경우, 개발자는 가능한 한 빨리 페이지에 매우 큰 변화를 의도적으로 깜빡이게 한다. 대체로 사용자에게 아무 가치가 없는(실제로는 전체 작업량과 전체 로딩 시간을 늘리므로 음수 가치인) 로딩 화면을 띄운 뒤, 이후 어떤 변화도 LCP로 잡히지 않도록 이후 변화를 조심스럽게 작게 만든다.

폭스바겐이 배출가스 수치를 어떻게 조작했는지를 공개적으로 논하지 않았던 것과 같은 이유로 개발자들은 이런 종류의 LCP 최적화를 공개적으로 논하는 것을 꺼린다. 예외는 Discourse인데, 그들이 이런 종류의 LCP 최적화를 “Discourse Splash”라는 새 기능으로 공개적으로 발표했으며, 개발자와 당시 CTO(현 CEO)의 코멘트와 함께 사이트 배포 후 LCP가 크게 줄었다고 언급했다. 그리고 개발자들이 왜 LCP가 높은지 물으면, Discourse 개발자들이 주는 표준 조언은 요소들을 “Discourse Splash”보다 작게 유지하라는 것이다. 그래야 LCP 타임스탬프가 사용자와 관련된 실제 요소가 아니라 쓸모없는 로딩 애니메이션 요소로부터 계산되도록 할 수 있다. Discourse의 전형적이고 공식적인 코멘트는 다음과 같다.

배너가 “Discourse Splash - 사이트 자산이 로드되는 동안 표시되는 시각적 프리로더 소개”에 쓰는 요소보다 크면 LCP에서 곤란을 겪게 될 겁니다.

Discourse의 공식 입장은 콘텐츠가 LCP 측정을 촉발하지 않도록 하고, 대신 로딩 애니메이션 타임스탬프가 LCP 계산에 쓰이도록 해야 한다는 것이다.

유용한 콘텐츠의 LCP와 크롬이 측정한 LCP의 비율이 가장 극단적인 사이트는 다음과 같다.

• Wix
  • M3: 6
  • M1: 12
  • Tecno Spark 8C: 3
  • Itel P32: N/A (FAIL)
• Discourse:
  • M3: 10
  • M1: 12
  • Tecno Spark 8C: 4
  • Itel P32: N/A (FAIL)

다른 지표의 왜곡에 대해서는 다루지 않았지만, 일부 웹사이트는 다른 지표들도 왜곡하고 사용자에겐 이득이 없는데도 “최적화”하는 것으로 보인다.

부록: 사이트를 최적화해야 하는 이기적인 이유

이는 사이트 규모와 성능에 따라 다르겠지만, 내가 일했던 큰 회사들의 데이터를 보면 사이트와 앱 성능을 개선하는 것은 엄청난 돈이 되는 일이다. A/B 테스트에서도 측정 가능하고, 장기 홀드백에서도 성장과 유지율에 상대적으로 큰 영향을 미치는 몇 안 되는 개입 중 하나다(많은 개입이 단기 테스트에서는 좋아 보이지만 장기적으로는 그렇지 않은 반면, 성능 개선은 장기적으로 더 좋아 보이는 경향이 있다).

물론 직접적인 수치에서도 이를 알 수 있지만, 데이터를 볼 때 여러 각도에서 간접적으로도 알 수 있다. 한 가지 예로 (예를 들어) 트위터에서 사용자가 체감하는 p99 지연 시간은 인도와 여러 아프리카 국가(상대적으로 부유한 이집트나 남아공 제외)에서도 약 60s였고 미국에서도 약 60s였다. 물론 전체 인구로 보면 미국의 기기와 연결이 더 빠르지만, 모든 나라에 느린 기기나 연결을 가진 사용자가 충분히 많아서 제한 요소는 실제 기기·연결 분포가 아니라 사용자의 인내심이다. 나이지리아나 인도 사용자에게 관심이 없고 미국의 광고 수익에만 관심이 있더라도, 저사양 기기와 연결을 위한 성능 개선 효과가 글로벌은 물론 미국의 수익에서도 A/B 테스트, 특히 장기 홀드백에서 쉽게 드러날 정도다. 그리고 빠른 기기를 가진 사용자 사이에서도 영향이 보인다. “저사양” 기기 사용자의 지연 시간을 60s에서 50s로 줄이는 변화는 고사양 기기 사용자의 지연 시간을 5s에서 4.5s로 줄일 수 있고, 이 역시 수익, 성장, 유지율 수치에 영향을 미친다.

이 문서의 범위를 넘어서는 여러 가지 이유로, 이런 지루하지만 계량 가능하고 성장과 수익을 견인하는 작업은 내가 일했던 대부분의 큰 회사에서, 장기 홀드백에서 거의 혹은 전혀 영향을 보이지 않는 화려한 제품 작업에 비해 자금을 받기 어려웠다.

부록: 저성능 기기를 위한 설계

느린 기기나 대역폭이 낮고 연결이 좋지 않은 기기를 쓸 때, 단연 최고의 경험은 한 번에 많은 콘텐츠를 정적 페이지로 불러오는 것이다. 이미지에 적절한 width와 height 속성, alt 텍스트가 있으면 매우 도움이 된다. 프로그레시브 이미지(프로그레시브 jpeg 같은)는 별로 도움이 되지 않는다.

대역폭이 높은 느린 기기에서는 가볍고 정적인 페이지는 모두 잘 동작하고, 성능을 고려해 설계된 가벼운 동적 페이지도 잘 동작할 수 있다. 무겁고 동적인 페이지는 페이지 무게 때문에 복잡해지지 않는 한 망한다.

대역폭이 낮거나 연결이 좋지 않은 경우에도 가벼운 페이지는 괜찮다. 무거운 페이지의 경우 내가 경험한 가장 나은 방식은 페이지 로드를 실행한 뒤 다른 일을 하다가(혹은 적어도 HTML과 CSS가 끝나면) 돌아오는 것이다. 그 뒤 읽고 싶은 링크를 각각 새 탭에서 열면, 그들이 로드되는 동안 또 다른 일을 하면 된다.

페이지 아래로 스크롤하면 추가 로딩이 발생하는 부분 로딩 같은 현대 웹사이트의 많은 최적화와, 그에 따른 검색 가로채기(페이지가 완전히 로드되지 않으면 브라우저 내장 검색이 쓸모없기 때문)는 이렇게 동작하는 상호작용 모델을 망가뜨려 페이지를 매우 고통스럽게 만든다.

한 예로, Substack이 부분 페이지 로드를 해서 불편하다는 지적이 많다. @acidshill이 iPhone 8에서 Substack 글을 로드한 뒤 스크롤하는 모습을 찍은 영상은 다음과 같다. 헤더 이후로 스크롤하려면 다음 페이지를 로드하는 데 6s를 기다려야 하고, 다시 스크롤하면 또 1s에서 2s를 기다려야 하는 등, LCP 자체는 꽤 빠르다.

반대 접근법의 예로, 나는 https://danluu.com/diseconomies-scale/ (0.1 MB wire / 0.4 MB raw)나 https://danluu.com/threads-faq/ (0.4 MB wire / 1.1 MB raw) 같은 꽤 큰 순수 HTML 페이지를 불러 봤는데, 느린 기기에서도 여전히 꽤 쓸 만했다. 1.1 MB는 최적보다는 커 보이고 몇 개 페이지로 나누는 게 저사양 기기에서는 더 낫겠지만, 텍스트 1.1 MB짜리 단일 페이지는 느린 기기에서 대부분의 현대 사이트보다 훨씬 잘 동작한다. 브라우저가 감당하지 못할 정도로 HTML 페이지가 거대해지면 문제가 될 수 있지만, 일반적인 콘텐츠 양의 페이지라면 복잡한 CSS 페이로드나 JS가 들어가기 전까지는 느린 기기에 문제를 일으키지 않는다. 아래에서는 비교적 단순하면서 미디어가 꽤 많은(14 MB인 경우도) 페이지들을 테스트해, 단순함을 유지하는 한 괜찮게 동작한다는 것을 확인한다.

Chris Adams는 동적 로딩이 스크린 리더를 쓰는 시각장애인 사용자에게 경험을 훨씬 더 나쁘게 만든다고도 지적했다. 성능 개선을 위한 동적 로딩처럼, 이는 잘 구현할 수도 있지만 종종 잘못 구현되거나 다른 복잡성과 함께 묶여 단순한 페이지보다 결과가 더 나빠진다.

@Qingcharles는 또 다른 접근성 문제를 지적했다. 그가 함께 일하는 (가석방된) 수감자들은 “lifeline” 폰을 받는데, 이는 종종 매우 저사양 기기다. 빠르게 검색해 보면 2024년에도 일부는 iPhone 6나 iPhone 8을 받지만, Itel P32는커녕 Tecno Spark 8C보다도 낮은 기기도 많다. 데이터가 극히 제한된 요금제를 받는데, 다 써버리면 어떤 사람은 “일자리나 복지 신청서를 작성할 수도, 지도로 길을 찾을 수도 없다”고 한다.

저사양 기기에서도 괜찮은 경험을 주는 사전 작업을 하는 사이트의 예로, Andy Kelley는 느린 기기에서도 괜찮게 동작하는 것 같아 보이는(아주 느린 연결에서는 버거워하겠지만) 사전 작업형 사이트의 예로 Zig 표준 라이브러리 문서를 지적했다.

모든 소스 코드를 미리 가져온 뒤 모든 콘텐츠 렌더링을 로컬에서 하는 다소 논란의 여지가 있는 결정을 내렸습니다. 이론적으로는 CPU 집약적이지만 실제로는... 저 오래된 폰들도 CPU가 정말 빠르더라고요!

Tecno Spark 8C에서 이는 4.7s의 CPU를 쓰고 이후에는 비교적 반응이 괜찮다(기기 기준으로 — 물론 아이폰이 훨씬 더 빠르게 반응한다. 탭하면 링크가 꽤 빠르게 열리고 스크롤도 괜찮게 동작한다(조금 끊기지만, 이 기기에서는 거의 아무 것도 정말 부드럽지 않다). 무거운 페이로드를 보내면 성능이 더 좋아진다고 말할 때 사람들이 말하는 것이 이런 종류인 것 같지만, 실제로 저사양 기기에서 성능을 개선하는 예는 많지 않다.

부록: 웹 성능 문제에 관한 글들

• 2015: Maciej Cegłowski: The Website Obesity Crisis
  • 크기: 1.0 MB / 1.1 MB
  • Tecno Spark 8C: 0.9s / 1.4s
    • 스크롤이 약간 끊기지만, 매우 빠르게 스크롤(맨 위에서 페이지 절반쯤으로 점프)할 때만 이미지가 나타나는 데 약간 시간이 걸리고, 일반적인 거리만큼 스크롤할 때는 거의 체감되지 않는 지연이다.
• 2015: Nate Berkopec: Page Weight Doesn't Matter
  • 크기: 80 kB / 0.2 MB
  • Tecno Spark 8C: 0.8s / 0.7s
    • 지연 로딩을 하지만, 페이지 전체를 스크롤하면 650 kB / 1.8 MB를 다운로드한다. 스크롤은 약간만 끊기고 지연 로딩으로 인한 지연이 없다. 느린 기기에서도 경험을 더 좋게 만드는 지연 로딩을 본 유일한 페이지일 것이다. 느린 연결에서는 테스트하지 않았는데, 그 경우엔 오히려 경험을 더 나쁘게 만들 것이다.
  • Itel P32: 1.1s / 1s
    • 스크롤이 사실상 쓸 수 없다. 스크롤이 극도로 끊기고 이동 거리가 불규칙하며, 새로운 텍스트로 스크롤할 때 텍스트 렌더링에만 1s 이상 걸리는 경우가 많다. 지연 로딩되는 이미지에서는 더 심할 수 있다. 내가 야생에서 본 지연 로딩 중 가장 잘 구현된 경우임에도 Itel P32는 여전히 감당하지 못한다.
• 2017: Dan Luu: How web bloat impacts users with slow connections
  • 크기: 14 kB / 57 kB
  • Tecno Spark 8C: 0.5s / 0.3s
    • 스크롤과 상호작용이 문제없이 동작한다.
  • Itel P32:0.7s / 0.5 s
• 2017-2024+: Alex Russell: The Performance Inequality Gap (series)
  • 크기: 82 kB / 0.1 MB
  • Tecno Spark 8C: 0.5s / 0.4s
    • 스크롤과 상호작용이 문제없이 동작한다.
  • Itel P32: 0.7s / 0.4s
    • 스크롤과 상호작용이 문제없이 동작한다.
• 2024: Nikita Prokopov (Tonsky): JavaScript Bloat in 2024
  • 크기: 14 MB / 14 MB
  • Tecno Spark 8C: 0.8s / 1.9s
    • 스크롤할 때 이미지가 나타나는 데 한참(500ms 정도) 걸리고 스크롤이 부드럽지 않지만, 원하는 위치로 스크롤하기 어려울 정도로 끊기지는 않는다.
  • Itel P32: 2.5s / 3s
    • 스크롤이 부드럽지 않다. 정확히 스크롤하기가 다소 어렵지만 매우 조심하면 원하는 곳으로 스크롤할 수 있다. 상당한 거리를 스크롤할 때 새로운 콘텐츠가 나타나는 데 대체로 1s보다 조금 더 걸린다.
• 2024: Dan Luu: This post
  • 크기: 25 kB / 74 kB
  • Tecno Spark 8C: 0.6s / 0.5s
    • 스크롤과 상호작용이 문제없이 동작한다.
  • Itel P32: 1.3s / 1.1s
    • 스크롤과 상호작용이 문제없이 동작하지만, 그러려면 수정이 필요했다. 이 문서는 원래 동영상을 포함하고 있었는데 Itel P32가 제대로 감당하지 못했다.
      • 이 수치는 “Page Weight Doesn't Matter”보다 나쁘지만, 해당 페이지는 폰이 합리적인 시간 안에 처리하기에 너무 복잡한 지연 로딩을 실행하므로 로드 후에는 쓸 수 없는 반면, 이 페이지는 로드 후 쓸 수 있다.
        

부록: 부유하지 않은 사용자에 대한 공감

프로그래밍이 더 명망 높고 수익 좋은 일이 되면서 시간이 지날수록 사람들이 더 부유한 배경에서 오고 다른 소득 수준의 사람들과 접촉할 기회가 줄어드는 경향을 관찰했다. 이전에 논한 예로, 직원 모두가 부유해진, 잘 알려진 명망 높은 스타트업에서 매우 진보적인 성향의 직원들이 모인 곳에서 코로나 지원금에 대한 슬랙 토론 중, 선의의 진보 성향 직원이 “어차피 지원금은 주식 사는 데 쓸 거라 의미 없다”고 말했다. 이 사람은 중산층(하물며 빈곤층) 사람이 돈을 어디에 쓰는지 한 번도 물어본 적도, 누가 주식을 보유하는지에 대한 데이터를 본 적도 없는 듯했다. 그리고 이는 미국의 부만 본 것이다. 전 세계의 부를 보면 일반적인 이해 수준은 훨씬 더 낮다. 사람들은 세계 곳곳의 부와 소득의 편차가 얼마나 큰지 정말 과소평가하는 것 같다. 꽤 많은 사람과 이야기해 본 결과, 많은 사람들이 “미국 기준으로 가난한” (지원금으로 주식을 사는) 사람과 “세계 기준으로 가난한” 사람(어쩌면 주식조차 안 사는) 정도의 구분만 머릿속에 갖고 있는 것 같다. 하지만 세계의 빈곤 범위는 미국의 빈곤 범위를 압도할 정도로 커서, 부유한 프로그래머 중 이를 제대로 인식하는 사람은 많지 않은 것 같다.

가령 내 부모님이 미국에 오게 되어 내가 얼마나 (경제적 기회 측면에서) 운이 좋았는지에 대한 토론에서 누군가 폴란드에서도 훌륭한 경제적 기회가 있었으니 그리 대단한 일이 아니라고 했다. 우선 토론 주제인 고소득 프로그래머(고소득 테크 회사의 시니어 스태프 엔지니어)나 그에 준하는 직업을 얻을 확률로 보면, 내가 태어났을 당시 미국에서 가난하게 태어나는 것이 폴란드에서 꽤 잘 사는 것보다 더 유리했을 것 같고, 데이터를 보여준다면 반대 경우도 믿을 수 있겠지만, 폴란드 대 미국과 베트남 대 미국을 비교한다면, 내가 태어난 해의 이 나라들의 대략적인 부 수치를 15초 정도 찾아본 결과 미국 : 폴란드의 1인당 GDP 비율은 약 8:1이었고, 폴란드 : 베트남은 약 50:1이었다. 폴란드와 베트남 사이의 부의 차이는 미국과 폴란드 사이의 차이의 대략 제곱에 해당하므로, 폴란드 대 베트남은 폴란드 대 미국보다 미국이 폴란드보다 부유한 차이만큼 더 부유한 어떤 가상의 나라와 비교하는 셈이다. 이들은 전혀 비교할 만한 수준이 아니지만, 많은 사람들은 “부유한 나라”와 “부유하지 않은 나라”가 있고 “부유하지 않은 나라”는 모두 대략 같은 범주에 속한다는 식의 사고 모델을 가진 것 같다. 1인당 GDP가 이상적이지는 않지만 백분위 소득 통계보다 찾기 쉬워서 썼다. 빠르게 검색해 보니 당시 베트남의 연간 소득은 1년에 200~300달러 정도였다. 베트남은 당시 기근의 꼬리 끝에 있었는데, 통계가 조작된 것으로 보여 그 영향을 정확히 가늠하기 어렵지만, 사망률 통계를 믿는다면 기근으로 인해 전체 사망률이 정상 대비 두 배로 뛰었다.¹

물론 당시 저소득 국가의 중위 소득자는 컴퓨터는커녕 인터넷 접속도 하지 못했을 것이다. 하지만 오늘날에는 저소득 국가 사람들도 기기를 흔히 가지고 있다. 많은 사람들이 이를 전혀 인식하지 못하거나, 많은 이들이 어떤 기기를 쓰는지 이해하지 못하는 것 같다.

부록: Fabian Giesen의 코멘트

Discourse 창립자의 iOS 대 안드로이드 시장 점유율 발언에 대해 Fabian은 다음과 같이 지적한다.

내가 찾을 수 있는 가장 최근 데이터(2023년)에 따르면, 미국에서 아이폰은 약 60%의 시장 점유율을 가진다. EU에서는 약 33%다. 이는 연쇄적인 영향을 미친다. iOS 사용자는 더 부유한 쪽으로 편중될 뿐만 아니라 미국 쪽으로도 편중된다.

여기서 파생되는 2차 효과도 있다. 예를 들어 미국에서는 iMessage가 단체 채팅 등에서 매우 인기 있고, 안드로이드 기기와는 매우 형편없이 연동되어 안드로이드 사용자 경험을 매우 짜증 나게 만든다(거의 확실히 의도적으로 그렇다).

EU에서는 안드로이드가 훨씬 더 우세하기 때문에 iMessage는 훨씬 덜 인기 있고, anecdote로도 미국이라면 iMessage를 쓸 법한 내 지인 중 아이폰 사용자들도 WhatsApp을 쓰는 경향이 있다.

요점은, 전 세계적으로 볼 때 최신 iOS + 빠른 인터넷은 많은 앱 개발자가 미국에서 인식하는 것보다 훨씬 더 특정 인구 집단에 편중되어 있다는 것이다.

그리고 모바일 앱 대 웹 앱 크기에 대한 코멘트에 대해 Fabian은 이렇게 말했다.

경험에서 덧붙이자면: 앱은 설치할 때 설치하고, 일반적으로 느리거나 종량제 연결에 있거나 아예 데이터가 없을 때 업데이트를 미룰 기회가 있습니다.

내가 처음 미국 폰을 샀을 때, 미국 신용 기록이 없어 선불 요금제를 써야 했습니다. 지금도 여전히 선불 요금제를 쓰는데, 평소에 폰을 쓰는 용도에는 대부분 괜찮지만, 1년에 한 번 독일에 갈 때는 데이터 로밍이 전혀 안 됩니다. (또한 독일에서 전화 한 통에 1.50달러가 듭니다. T-Mobile이 독일에서 가장 큰 이동통신사임에도 불구하고요. 물론 T-Mobile US는 아닙니다.)

요점은, 무료 고속 와이파이는 T-Mobile 핫스팟(예: 주요 기차역, 공항 등)이나 핫스팟이 있는 시외 열차에서는 이용할 수 있지만, 독일에 있을 때는 사실상 데이터 요금제가 전혀 없다는 겁니다.

이는 오프라인에서 동작하고 연결이 될 때 데이터를 동기화하는 모바일 폰 앱으로는 전혀 문제가 되지 않습니다. 하지만 웹 앱은 공용 와이파이 근처에 있지 않으면 쓸 수가 없습니다.

마찬가지로 Gmail 앱으로는 느린 종량제 연결로도 메일을 보내는 데 문제가 없지만, 종량제 연결에서 뭔가를 하려고 압축된 JS 몇 메가를 다운로드해야 하는 웹 메일 클라이언트는 절대 쓰지 않을 겁니다.

네이티브 앱 다운로드는 적어도 인터넷이 좋은 곳에 있을 때 미리 준비해 다운로드할 수 있지요!

Fabian의 또 다른 코멘트(이건 대화에서 나온 것이라 의역이다)는, 사람들이 양적으로 엄청나게 느린 것을 질적으로 느려야 하는 이유가 있다는 이유로 정당화하곤 한다는 것이다. 그가 든 한 예는 화면이 연결을 동기화하는 데 종종 오래 걸리는데, 이는 시간이 걸리는 작업들이 있기 때문이라는 식으로 정당화된다는 것이다. 오랫동안 이런 작업들은 종종 몇 초씩 걸리곤 했다. 최근에는 많은 디스플레이가 훨씬 더 빠르게 동기화하는데, 이는 엔비디아가 “G-Sync” 인증을 위해 이 과정이 얼마나 걸릴 수 있는지를 규정했기 때문에 제조사들이 실제로 이를 합리적인 시간 안에 처리하기 때문이다. 시간이 걸리는 작업들이 있어야 한다는 것은 질적으로는 사실이지만, 그것들이 예전처럼 그렇게 오래 걸려야 할 근본적인 이유는 없다. 그가 든 또 다른 예는 수천 개의 파일을 읽는 데 오래 걸리는 것을 시스템 콜이 많이 필요하고 “시스템 콜은 느리다”는 이유로 정당화한 경우였는데, 이는 질적으로는 맞는 말이지만 실제 시스템 콜 비용을 보면 논의 중인 사례에서 시스템 콜 비용은 그렇게 오래 걸린 이유를 설명하기에는 수 차원이나 부족한 수준이었다.

이 주제와 관련해, 현대 웹사이트가 느리다고 지적하면 대체로 누군가는 현대 웹사이트가 가진 훌륭한 기능들 때문에 그렇고, 오래된 웹사이트에는 그런 기능이 없다는 식으로 질적인 변호를 한다. 그리고 (예를 들어) Discourse가 MyBB에는 없는 기능을 가진 것은 사실이지만, 그 기능이 33x 느려도 될 만큼 정당화된다고 주장하기는 어렵다.

부록: 실험 세부 사항

danluu.com과 논쟁의 여지는 있지만 HN을 제외하고, 각 사이트마다 “가장 기본적인” 경험을 찾으려 했다. 예를 들어 WordPress의 경우 현재 기본 테마인 twentytwentyfour를 쓴 데모 블로그를 의미한다. 일부 경우 이는 오늘날 사람들이 가장 흔히 쓰는 것과는 다를 수 있다. 예컨대 Shopify의 경우 테마를 둘러볼 때 처음 나오는 테마를 봤지만, 가장 많이 쓰이는 테마가 무엇인지 테마 데이터를 찾아보지는 않았다. 이 글에서는 모든 데이터 수집과 분석을 하루짜리 짧은 프로젝트로 하고 싶었기 때문에 이런 식의 지름길이 많았고, 아래에서 설명할 것이다. Shopify에서 가장 먼저 제시되는 테마를 쓰는 것이 틀렸다고 생각하지는 않는다. 상당수 사용자가 아마도 첫 번째 테마를 쓸 테지만, 물론 가장 흔한 테마를 가져와 사람들이 자신의 용도로 테마를 수정했을 때 실제 성능이 어떻게 달라지는지 보기 위해 그 테마를 쓰는 여러 사이트를 테스트하는 것보다는 덜 대표성이 있다. 내가 Shopify에서 일하거나 경쟁사를 대신해 경쟁 분석을 하려 했다면 그렇게 했겠지만, 저사양 기기 사용자가 대형 웹사이트 때문에 겪는 영향에 대한 하루짜리 프로젝트로는 여기서 보여준 Shopify 성능이면 괜찮다고 본다. 사실 이 작업을 처음 한 것은 설문을 돌렸을 때인 2월이며, 한 달 동안 글을 쓸 시간이 없었을 뿐이다.

노트북 테스트에서는 노트북 배터리를 약 60%로, 전원 연결 없이, 그리고 노트북이 20°C 방에서 열 평형 상태로 돌아올 만큼 충분히 유휴 상태인 뒤에 테스트하려 했다. 그래서 페이지가 이전 페이지 로드나 기기에서 진행 중이던 다른 작업의 영향을 받지 않도록 했다.

모바일 테스트에서는 폰을 약 100% 충전 상태로 전원에 연결한 채, 이전에도 100% 충전 상태였으므로 급속 충전으로 인한 발열 효과가 없도록 했다. 위에서 언급했듯이 이 테스트는 1Gbps 와이파이로 진행됐다. 다른 앱은 실행하지 않았고, 브라우저에 다른 탭도 열려 있지 않았으며, 기기에 설치된 앱은 이것뿐이므로 기본적으로 기기가 수행하는 것 외에 추가 백그라운드 작업이 돌아서는 안 된다. 같은 기기를 쓰는 실제 사용자는 크롬 개발자 도구를 폰에서 실행하는 것이 성능을 크게 떨어뜨리지 않는 한 거의 모든 상황에서 우리가 측정한 것보다 더 나쁜 성능을 보게 될 것이다. Itel P32에서는 개발자 도구를 실행한 상태에서의 스크롤이 정상 실행 때보다 다소 더 끊기는 것을 확인했지만, 하루짜리 프로젝트였으므로 이를 정량화하거나 일부 사이트에만 더 큰 영향을 미치는지 시도하지 않았다. 절대적인 측면에서 오버헤드는 그리 크지 않을 것이다. 가장 빠른 사이트들은 개발자 도구를 실행한 상태에서도 여전히 꽤 빠르기 때문이다. 하지만 사이트가 하는 작업량에 대해 초선형적인 어떤 오버헤드가 있다면(간접적으로 어떤 자원 고갈을 일으킨다면) 일부 사이트 측정에서는 문제가 될 수 있다.

크기는 모두 모바일에서 측정했으므로, 모바일과 데스크톱에서 다른 에셋을 불러오는 경우 모바일 에셋 크기를 측정했다. CPU는 메인 스레드에서의 CPU 시간으로 측정했다(다른 스레드를 쓰는 사이트에 대해서는 다른 스레드에서의 시간도 기록했지만 이 수치는 쓰지 않았다. CPU가 사람들이 속이려고 하는 지표라면 다른 스레드에서의 시간도 합산해 사이트가 가능한 한 많은 작업을 다른 스레드로 옮기려 하는 시도를 막아야 하겠지만, 현재로서는 문제가 되지 않으며 메인 스레드 시간이 모든 스레드 합계보다 사용성과 더 직접적인 상관관계가 있고, 속이기를 막는 지표는 지금은 이득 없이 가독성만 떨어뜨린다).

와이파이 속도는 속도 테스트에서 다음과 같은 수치가 나왔다.

• M3 Max
  • Netflix (fast.com)
    • 다운로드: 850 Mbps
    • 업로드: 840 Mbps
    • 지연 시간 (비부하 / 부하): 3ms / 8ms
  • Ookla
    • 다운로드: 900 Mbps
    • 업로드: 840 Mbps
    • 지연 시간 (비부하 / 다운로드 / 업로드): 3ms / 8ms / 13ms
• Tecno Spark 8C
  • Netflix (fast.com)
    • 다운로드: 390 Mbps
    • 업로드: 210 Mbps
    • 지연 시간 (비부하 / 부하): 2ms / 30ms
  • Oookla
    • Ookla 웹 앱이 실패해 결과를 볼 수 없음
• Itel P32
  • Netflix
    • 다운로드: 44 Mbps
    • 업로드: 테스트가 동작하지 않음 (데이터 한 덩어리를 보내고 멈춰 더 이상 데이터를 보내지 않음)
    • 지연 시간 (비부하 / 부하): 4ms / 400ms
  • Okta
    • 다운로드: 45 Mbps
    • 업로드: 테스트가 동작하지 않음
    • 지연 시간: 테스트가 지연 시간을 표시하지 못함

한 가지 짚고 넘어갈 점은 Itel P32가 명목상 가진 대역폭을 실제로 활용할 능력이 없다는 것이다. 상위 구글 리뷰 중 어느 것도 이를 언급하지 않는다. 첫 번째 리뷰는 이렇게 말한다.

성능 면에서 폰은 버벅이지 않는다. 최신 안드로이드 8.1(GO 에디션)로 구동되며... 8GB+1GB ROM과 RAM, 손쉬운 멀티태스킹을 위한 1.3GHz 쿼드코어 프로세서라는 강력한 성능을 갖췄다... P32의 기능에 감명받았다, 특히 가격 때문에. 항상 이동하는 사람들에게 추천한다. 그리고 스마트폰에서 배터리 수명을 최우선으로 여기는 사람이라면 P32가 최고의 선택이다.

두 번째 리뷰는 이렇게 말한다.

Itel 모바일은 대륙 규모로 3위를 차지하는 아프리카의 선두 유통사 중 하나다... 가벼운 운영체제가 기대에 부응해 1GB RAM 기기에서도 느릿함 없이 동작했다... 꽤 빠른 처리 속도... Itel P32 스마트폰은 성능을 넘어 최고의 성능을 제공한다... 무려 UGX 330,000이라는 가격표에 Itel P32는 놀라운 기능이 하나의 패키지에 담긴 중급 플래그를 달 만한 놀라운 저가형 스마트폰 중 하나다.

세 번째 리뷰는 이렇게 말한다.

“단순한 보급형 엔트리 스마트폰 그 이상... 2주 사용 후 전체 리뷰... 앱 간 전환, 무거운 웹 페이지 탐색 시 성능은 최적이었다. 여러 앱이 백그라운드에서 실행되는 동안 게임을 할 때 몇 차례 렉이 있었다. 하지만 전반적인 성능은 대부분의 폰 사용자에게 평균적이며 일반 사용자에게 최적이다 [게임 스크린샷] 게임이 일부 프레임을 건너뛰고 그래픽 디테일을 자동으로 낮췄지만, 폰에서 다른 앱이 실행되지 않으면 훨씬 더 빨랐다.

사이트별 참고 사항:

• Wix
  • www.wix.com/website-template/view/html/3173?originUrl=https%3A%2F%2Fwww.wix.com%2Fwebsite%2Ftemplates%2Fhtml%2Fmost-popular&tpClick=view_button&esi=a30e7086-28db-4e2e-ba22-9d1ecfbb1250: 테마를 얻기 위해 클릭했을 때 첫 번째로 나온 항목이었다.
  • 모든 기기에서 LCP가 잘못됐다.
  • Tecno Spark 8C에서는 스크롤이 사실상 전혀 동작하지 않는다. 매우 끊기고 전혀 안정되지 않는다.
  • Itel P32에서는 페이지가 비결정적으로 실패한다(로드마다 다른 오류). 오류가 나는 데 꽤 오래 걸릴 수 있다. 첫 실행에서는 23s 걸렸고 CPU가 28s 동안 풀로 돌았다.
• Patreon
  • www.patreon.com/danluu: 가능한 경우 내 프로필을 사용했다.
  • Patreon에서 스크롤하고 오래된 글을 찾는 것은 너무 고통스러워서 내 오래된 Patreon 글 인덱스를 직접 유지해 Patreon을 쓰지 않고도 찾을 수 있도록 한다. 표에서 Patreon 수치는 빠른 노트북에서는 초기 로드만 보면 그리 나빠 보이지 않지만, 스크롤하면서의 성능은 오늘날 존재하는 어떤 컴퓨터와 인터넷 연결로도 제대로 된 성능으로 Patreon을 탐색할 수 없을 정도로 나쁘다.
• Threads
  • threads.net/danluu.danluu: 가능한 경우 내 프로필을 사용했다.
  • Itel P32에서는 기술적으로는 제대로 로드되지 않아 FAIL로 표시할 수도 있지만, 거의 비슷하게 로드되므로 카운트했다. 잘못된 점은 프로필 사진에 네모난 박스가 둘러져 있다는 것이다.
    • 하지만 다른 무거운 페이지와 마찬가지로 페이지와 상호작용하는 것은 사실상 동작하지 않고 페이지는 쓸 수 없지만, 이는 페이지가 렌더링에 실패했기 때문이 아니라 일반적인 성능 문제 때문으로 보인다.
• Twitter
  • twitter.com/danluu: 가능한 경우 내 프로필을 사용했다.
• Discourse
  • meta.discourse.org: 공식 포럼을 검색했을 때 나온 곳이다.
  • 위에서 언급했듯이 LCP는 심하게 왜곡되어 사실상 무의미하다. Discourse 사람들이 느린 로드에서는 2s에 거대한 스플래시 화면을 띄워 LCP를 2s로 제한한다고 언급한 글을 링크했다. 또한 주목할 점은 2s보다 빠른 로드에서도 LCP가 심하게 왜곡된다는 것이다. 예를 들어 지연 시간이 낮은 1Gbps 인터넷의 M3 Max에서 LCP는 115ms로 보고됐지만 실제 콘텐츠는 1.1s에 로드된다. 이는 “Discourse Splash”와 근본적으로 같은 트릭을 쓰는데, 화면에 거대한 변화를 칠한 뒤 실제 페이지 콘텐츠가 LCP로 감지되지 않도록 더 작은 요소들을 조심스럽게 로드한다.
  • Tecno Spark 8C에서는 스크롤이 예측 불가능하게 너무 멀리 점프해 무한 스크롤 로딩을 촉발하고 페이지를 3s-10s 멈추게 한다. 또한 이 페이지에 브라우저를 그냥 둔 채로 놔두면 전체 브라우저가 가끔 충돌한다.
  • Itel P32에서는 7.5s 후에 오류 메시지가 표시된다.
• Bluesky
  • bsky.app/profile/danluu.com
  • Itel P32에서 빈 화면을 표시한다.
• Squarespace
  • cedar-fluid-demo.squarespace.com: 테마를 얻기 위해 클릭했을 때 두 번째로 나온 테마였다. 첫 번째는 “Bogart”라는 테마였는데 콘텐츠가 없는 “커밍 순” 단일 페이지 화면이라 두 번째 테마를 썼다.
  • Itel P32에서는 콘솔에 많은 오류와 경고가 있지만 페이지는 로드되고 동작하는 것처럼 보이고, 상호작용은 꽤 느리고 고통스럽다.
  • Tecno Spark 8C에서는 실제 페이지 콘텐츠가 로드되기 훨씬 전에 LCP가 발생했다.
• Tumblr
  • www.tumblr.com/slatestarscratchpad: 이 텀블러가 존재한다는 걸 알기 때문에 사용했다. 텀블러를 많이 보지 않는데(서너 개 정도), 그 중 내 블로그와 가장 가까운 것 같아 이걸 썼다.
  • 이 페이지는 Itel P32에서 실패하지만 FAIL은 아니다. 콘솔에 자바스크립트 오류가 뜨지만 페이지는 여전히 잘 동작한다(스크롤, 링크 클릭 등을 시도했고 모두 동작했다). 그래서 원하는 글로 가서 읽을 수 있다. JS 오류 때문에 이 페이지가 다른 경우보다 훨씬 더 빨리 로드되고 로드 후 상호작용도 꽤 빨라진 것으로 보인다.
• Shopify
  • themes.shopify.com/themes/motion/styles/classic/preview?surface_detail=listing&surface_inter_position=1&surface_intra_position=1&surface_type=all: 테마를 찾을 때 처음 나온 테마였다.
  • 첫 번째 M3/10 실행에서 크롬 개발자 도구가 697s라는 비정상적인 CPU 시간을 보고했다(실행은 정상적인 시간 안에, 697s나 697/10s보다 훨씬 빨리 완료됐다). 이 실행은 결과 계산에서 제외했다.
  • Itel P32에서는 페이지 로드가 절대 완료되지 않고 테마가 의도적으로 로드하는 깜빡이는 커서 같은 이미지만 표시된다. 제대로 로드되는 기기에서는 깜빡이는 커서 이미지가 즉시 다른 이미지로 덮이지만 여기서는 그렇지 않다.
  • 이 예시 테마를 쓰는 것이 공정한지 궁금해 테마 스타일을 전환할 수 있는 요소가 페이지에 있어 실제 테마 사용 예(테마를 홍보하는 페이지에 테마 사용자가 나열된다)를 확인했다. 나열된 실제 예 중 처음 두 개를 시도했는데 둘 다 이 데모 페이지보다 훨씬 더 느렸다.
• Reddit
  • reddit.com
  • 페이지가 쓸 수 있게 되기까지 걸리는 시간에 비해 LCP*가 비정상적으로 낮다. 이 테스트에서는 측정하지 않았지만, 나는 대체로 이 페이지가 역사적인 기준으로도 매우 빠른 컴퓨터인 인텔 맥북에서도 느리고 다소 쓸 수 없다고 느낀다(물론 old.reddit.com을 쓰지 않는 한).
• Mastodon
  • mastodon.social/@danluu: 가능한 경우 내 프로필을 사용했다.
  • Itel P32에서는 로드에 실패해 빈 화면만 나온다. Itel P32에서는 대체로 모든 것이 오래 걸리기 때문에 페이지가 실패한 건지 그냥 느린 건지 한동안 구분하기 어렵다.
• Quora
  • www.quora.com/Ever-felt-like-giving-up-on-your-dreams-How-did-you-come-out-of-it: 메타필터 사용자 중 한 명이 이제 Quora에서 활발히 활동한다고 들어 그 사용자 이름으로 quora를 구글링해 봤다. 프로필 페이지 대신 구글이 이 페이지를 반환했는데, 내가 검색한 사용자와는 전혀 관계없는 내용이었다. 그래서 소셜 미디어 프로필과는 비교할 수 없지만, 구글에서 관련 없는 Quora 결과를 받는 것이 내가 Quora를 쓰는 방식이므로 내 Quora 사용을 대표한다고 할 수 있을 것이다.
  • Itel P32에서는 페이지가 어느 시점에서 스크립트 실행을 멈추고 완전히 로드되지 않는다. 그래서 제대로 표시되지 않는다. 페이지와 상호작용하는 것도 제대로 동작하지 않는다.
• Substack
  • Zvi가 Substack을 운영하고 비슷한 주제에 대해 쓴다는 걸 알기 때문에 thezvi.substack.com을 사용했다.
• vBulletin:
  • forum.vbulletin.com: 공식 포럼을 검색했을 때 나온 곳이다.
• Medium
  • medium.com/swlh: Medium에서 아무 것도 읽지 않으므로 Medium의 프로그래밍 블로그를 구글링했고 이게 최상위 결과였다. 테마를 보면 Medium 블로그 치고 비정상적으로 무겁거나 특별히 커스터마이징된 것으로 보이지 않는다. 널리 읽히고 인기 있는 것 같아 다른 블로그보다 CDN에서 제공될 가능성이 더 높다.
  • 벤치마크 기준 실행이 아닌 실행에서 Itel P32로 페이지 로드 35초 후부터 스크롤을 시도했다. 스크롤 지연은 5s-8s였고 스크롤 이동량이 예측 불가능해 페이지를 전혀 쓸 수 없었다. 표에서는 FAIL로 표시하지 않았지만, 쓸 수 없다는 점에서 FAIL로 봐야 한다고 주장할 수도 있다.
• Ghost
  • source.ghost.io: 현재 기본 Ghost 테마이며 내가 처음 찾은 예시라서 사용했다.
• Wordpress
  • 2024.wordpress.net: 현재 기본 wordpress 테마이며 내가 처음 찾은 예시라서 사용했다.
• XenForo
  • xenforo.com/community/: 공식 포럼을 검색했을 때 나온 곳이다.
  • Itel P32에서는 레이아웃이 심하게 깨지고 페이지 콘텐츠가 서로 겹친다. 이 때문에 원하는 요소와 상호작용할 합리적인 방법이 없고, 텍스트를 읽으려면 여러 번 겹쳐 인쇄된 텍스트를 읽어야 한다.
• Wordpress (old)
  • thezvi.wordpress.com을 사용했는데, Zvi의 substack과 동일한 콘텐츠를 담고 있으며 과거에 매우 흔한 선택이었던 오래된 wordpress 테마를 쓰고 있다.
• phpBB
  • www.phpbb.com/community/index.php: 공식 포럼을 검색했을 때 나온 곳이다.
• MyBB
  • community.mybb.com: 공식 포럼을 검색했을 때 나온 곳이다.
  • 사이트가 모바일 버전을 제공하지 않는다. 대체로 느린 기기에서는 사이트의 데스크톱 버전이 모바일 버전보다 훨씬 낫다고 느끼므로 이는 꽤 잘 동작하지만, 구글에서는 이 때문에 감점을 받을 가능성이 높다.
• HN
  • news.ycombinator.com
  • 원칙적으로 HN은 가장 느린 소셜 미디어나 링크 애그리게이터여야 한다. 최적화가 잘 되지 않은 커스텀 Lisp로 작성됐고, 코드는 원래 간결성과 기교를 염두에 두고 작성되어 대체로 성능이 그리 좋지 않기 때문이다. 하지만 이는 고성능 코드를 작성했을 때와 비교한 것이고, 여기서는 관련 있는 비교가 아니다.
• danluu.com
  • 설명이 필요 없다.
  • 현재는 HN보다 CPU를 약간 덜 쓰지만 메인 페이지가 계속 커지므로 결국 더 많이 쓰게 될 것으로 예상한다. 현재 이 페이지는 HN의 30개 글에 대한 199개 링크 대비 168개 글에 대한 176개 링크를 가지고 있다. 다만 갑작스러운 죽음을 맞지 않는 한 결국 HN보다 링크가 더 많아질 것이다.
    • 위에서 언급했듯이 이런 작은 페이지에 페이지네이션을 하면 느린 기기나 연결이 좋지 않은 환경에서 탐색 경험이 훨씬 더 나빠지므로, 페이지네이션으로 “최적화”하거나 더 나아가 스크롤 시 동적 콘텐츠 로딩 같은 것을 하고 싶지 않다.
• Woo Commerce
  • 원래 Woo Commerce도 측정했지만, 위에서 테스트한 페이지 및 플랫폼과 달리 초기 로드에서의 빠름·느림이 이후 다른 동작의 성능을 반드시 대표하지는 않았으므로 표에 포함하지 않았다. 표에 넣으면 Shopify와의 비교를 요구하는 셈이 되기 때문이다. 특히 내가 찾을 수 있는 “가장 기본적인” Woo 테마는 느린 기기에서 초기 로드 시 “가장 기본적인” Shopify 테마보다 확실히 빨랐지만, 성능이 다차원적이어서 느린 기기에서 Shopify가 Woo보다 빠른 현실적인 시나리오와 그 반대 시나리오를 모두 쉽게 찾을 수 있었고, 이는 Substack·Medium 같은 최신 블로깅 플랫폼과 Wordpress 같은 오래된 플랫폼, 혹은 Discourse 같은 현대 포럼과 오래된 PHP 기반 포럼 비교에서 본 것과는 꽤 달랐다. 카트, 체크아웃 흐름 등이 있는 쇼핑 사이트를 제대로 비교하려면 하루 만에 얻을 수 있는 것보다 실제 사용에 대한 더 깊은 이해가 필요할 것이다.
• NodeBB
  • community.nodebb.org
  • 원래 테스트에는 없었고, NodeBB 창립자 중 한 명이 “우리가 테스트하면 @[email protected]가 더 잘 나오지 않을까 궁금하다. 우리는 수년간 엄청나게 빠르게 만들기 위해 많은 시간을 들였고, 적어도 속도와 초기 페이로드 측면에서는 Discourse보다 현대 포럼 소프트웨어를 더 잘 대표한다고 개인적으로 느낀다”고 제안해서 시도해 봤다.
  • Itel P32를 충전 상태로 유지하지 않아 전체 테스트를 하지는 않았다(배터리가 많이 닳아 플러그를 뽑으면 매우 빠르게 방전되므로 충전 상태로 만드는 데 꽤 오래 기다려야 한다).
  • 내가 한 테스트에서는 M1에서 0.3s/0.4s, Tecno Spark 8C에서 3.4s/7.2s가 나왔다. 이는 vBulletin보다 다소 느리고 더 빠른 php 포럼들보다는 확실히 느리지만 Discourse보다는 훨씬 빠르다. 어떤 이유로든 “현대적인” 포럼이 필요하고 세계적인 기준으로 부유하지 않은 사람들도 쓸 수 있게 하고 싶다면 이 정도는 괜찮아 보인다.
  • 또 하나 주목할 점은 “현대적인” 사이트임에도 초기 로드 후 상호작용이 잘 동작한다는 것이다. 스크롤하고 무언가를 탭하는 것이 기본적으로 잘 동작하고 아무 것도 충돌하지 않았다.
  • 크기는 0.9 MB / 2.2 MB로 “현대적인” 사이트 치고는 꽤 가볍고 느린 연결에서도 쓸 수 있을지도 모르지만, 느린 연결은 여기서 테스트하지 않았다.

또 다른 종류의 테스트는 페이지들을 가능한 한 비슷하게 보이도록 구성하는 것이다. 누군가 그렇게 한다면 결과가 궁금하지만, 그 테스트는 훨씬 더 많은 시간이 든다. 우선 각 사이트를 커스터마이징해야 하고, 또 사이트가 어떻게 보여야 하는지를 결정해야 하기 때문이다. danluu.com 같은 것을 테스트한다면, WordPress나 Ghost처럼 CDN에서 바로 가볍게 제공할 수 있는 모든 플랫폼은 비슷하게 점수가 나와야 하며, 점수는 CDN과 CDN 캐시 히트율에 따라 달라질 것이다. Medium이나 Substack처럼 커스터마이징 여지가 상대적으로 적은 사이트는 여기서와 거의 같은 점수가 나올 것이다. 현실적으로 존재하는 사이트들을 보면, 대부분 사용자는 WordPress나 Ghost의 “가장 기본적인” 테마보다 더 느린 사이트를 만들겠지만, 이 블로그 독자라면 평균적으로는 반대일 가능성도 있으므로 다양한 스타일의 사이트를 테스트하고 싶을 것이다.

부록: 이 사이트와 느린 기기·느린 연결에서 동작하지 않는 사이트들

덧붙이자면, 오래전부터 재미있다고 느낀 점은 이 페이지의 스타일링에 대해 꽤 많은 증오 메일을 받는다는 것이다(비슷한 양의 감사 메일도 받는다). 증오 메일이라고 할 때 정중한 개선 제안을 말하는 게 아니라, 웹 브라우징에서의 로드 레이지 같은 것, 웹 레이지라고 할 수 있는 것을 말한다. 나는 상당수 세계 인구가 쓸 수 없을 정도로 복잡한 사이트를 운영하는 사람들을 안다. 왜 사람들은 이 사이트의 스타일링에는 그토록 분노하면서, 비례적으로는 웹이 그토록 많은 사람에게 쓸 수 없다는 사실에는 전혀 신경 쓰지 않는 걸까?

또 하나 재미있는 점은 스타일을 좋아하는 사람들은 대체로 이 사이트가 어떤 기본 스타일도 덮어쓰지 않아 창 크기를 원하는 대로 조절해 너비를 정확히 원하는 대로 만들 수 있고, 사이트에 적용하는 어떤 기본 스타일도 덮어쓰지 않는 점을 좋아한다는 것이다. 이에 대해 정말 집착하는 사람들은 모두가 자신이 선호하는 어떤 너비 제한, 자신이 선호하는 폰트 등을 갖기를 바라지만, 이는 항상 자신들이 원하는 것이 아니라 대중을 위한 것인 양 포장된다. 웹 레이지를 부리는 사람들의 선호를 맞추면 창 너비를 조절해 텍스트 너비를 조절하기를 선호하는 사람들의 선호와 직접적으로 충돌하는데도 그렇다.

내가 이를 수십 번 지적하기 전까지는, 이런 논쟁이 대체로 웹 레이지를 부리는 사람들이 “연구에 따르면” 더 좁은 텍스트 너비가 객관적으로 더 좋다고 말하는 것으로 시작하곤 했다. 하지만 내가 찾을 수 있는 이 주제에 관한 모든 연구를 읽어보니 그렇지 않았다. 게다가 인용을 요청하면, 이런 말을 하는 사람들이 실제로는 이 주제에 관한 어떤 연구도 읽지 않았고 때로는 대충 구글링해 자신들이 읽지도 않은 듯한 연구를 보내오는 것이 분명했다. 내가 이를 지적하면 사람들은 연구가 실제로 이 문제를 잘 설명하지 못한다는 식으로 말을 바꾸곤 했다(애초에 연구를 인용했던 것이 이상하다). 한 사람은 내게 책까지 인용했는데(나는 읽었고 그 사람은 분명 읽지 않았다. 그 책도 그의 주장을 뒷받침하지 않았다), 그러고는 이것이 모두가 원하는 것이라고 주장하는데, 이는 내가 받은 코멘트나 내가 변화를 줬을 때 얻은 데이터로 봐도 명백히 그렇지 않다.

이런 논리를 가진 웹 레이지들은 자신의 선호가 보편적이지 않다는 정보를 좀처럼 받아들이지 못하고, 사람들이 다른 선호를 가지고 있다고 말해도 상관없이 계속 주장하는 것이 꽤 흥미롭다. 데이터로 보면, Octopress 스타일링(당시 프로그래밍 블로거들에게 가장 인기 있는 스타일링)에서 현재 스타일링으로 바꿨을 때 트래픽과 참여도가 인과적으로 증가한 것으로 보였다. 그러니 스타일에 대해 감사 메일을 보내는 사람들뿐 아니라, 내게 메일을 보내지 않는 전체 사람들의 느낌도 사이트가 괜찮고 표준 프로그래머 블로그 스타일링보다 더 매력적이라고 느끼는 것 같다. 내가 이를 언급하면 사람들은 자신의 선호가 보편적이며 다른 선호를 가졌다고 생각하는 사람들은 틀렸다는 생각에 더욱 몰입해 완전히 말이 안 되는 답변을 하곤 한다.

분명히 말하지만, 나는 이 사이트의 디자인이 최적이라고 주장하려는 것이 아니다. 당시 프로그래머들에게 가장 인기 있는 블로깅 플랫폼의 CSS가 저사양 연결을 쓰는 사람들에게 객관적으로 나빠 보여서 그 CSS를 그냥 제거했을 뿐인데, 부수적으로는 저사양 연결·기기를 쓰는 지역뿐 아니라 전체적으로도 더 많은 트래픽과 참여도를 얻었다. 저사양 연결과 기기를 신경 쓰는 디자이너라면 분명 더 잘할 수 있겠지만, 이 주제에 대한 불성실함과 독설에는 뭔가 상당히 기묘한 구석이 있다.