50MB 예산으로 하루 동안 웹을 사용했습니다.

이 기사는 주어진 사용자 인구 통계를 나타내는 다양한 제약 조건에서 웹을 사용하려고 시도하는 시리즈의 일부입니다. 나는 우리가 그들의 필요에 공감하는 방식으로 디자인하고 개발한다면 피할 수 있는 실제 사람들이 직면한 어려움에 대한 프로필을 올리기를 희망합니다.

지난 번에는 Internet Explorer 8을 사용하여 하루 동안 웹을 탐색했습니다. 이번에는 50MB의 예산으로 하루 동안 웹을 탐색했습니다.

왜 50MB인가?

우리 중 많은 사람들은 한 달에 몇 기가바이트의 데이터를 전송할 수 있는 모바일 요금제를 사용할 만큼 충분히 운이 좋습니다. 그렇지 않으면 일반적으로 고속 광대역 연결에 있고 데이터가 무제한인 가정 또는 공용 WiFi 네트워크에 연결할 수 있습니다.

그러나 모바일 데이터가 엄청나게 비싸고 광대역 인프라가 거의 또는 전혀 없는 지역이 있습니다.

사람들은 한 번에 수십 메가바이트의 데이터 패키지를 구매하는 경우가 많으며 기가바이트는 상대적으로 커서 구매 비용이 많이 듭니다.
— Dan Howdle, Cable.co.uk의 소비자 통신 분석가

우리가 말하는 비용은 얼마입니까?

모바일 데이터 비용

cable.co.uk의 2018년 연구에 따르면 짐바브웨는 세계에서 모바일 데이터 비용이 가장 비싼 국가로, 1GB의 비용은 평균 $12.50에서 $138.46 사이인 $75.20입니다. 가격의 엄청난 범위는 더 적은 양의 데이터가 매우 비싸고, 더 많은 데이터 요금제를 약정하면 그에 비례하여 더 저렴해지기 때문입니다. 자세한 내용은 연구 방법론을 읽을 수 있습니다.

짐바브웨는 결코 일회성이 아닙니다. 적도 기니, 세인트 헬레나, 포클랜드 제도가 그 뒤를 이었습니다. 1GB 데이터 비용은 각각 $65.83, $55.47, $47.39입니다. 이러한 국가는 일반적으로 열악한 기술 인프라와 낮은 채택률이 결합되어 있습니다. 즉, 데이터 제공에 비용이 많이 들고 비용을 절감할 규모의 경제가 없습니다.

데이터는 유럽 일부 지역에서도 비쌉니다. 그리스의 기가바이트 데이터는 32.71달러를 절약할 수 있습니다. 스위스에서 $20.22. 비교를 위해 동일한 양의 데이터 비용은 영국에서 $6.66, 미국에서 $12.37입니다. 한편, 인도는 평균 비용이 0.26달러로 세계에서 데이터가 가장 저렴한 곳입니다. 키르기스스탄, 카자흐스탄, 우크라이나는 각각 GB당 $0.27, $0.49, $0.51입니다.

모바일 네트워크의 속도 역시 국가마다 상당히 다릅니다. 아마도 놀랍게도 사용자는 호주와 프랑스를 포함하여 전 세계적으로 최소 30개국에서 모바일 네트워크를 통해 WiFi보다 더 빠른 속도를 경험합니다. 한국은 평균 52.4Mbps의 모바일 다운로드 속도가 가장 빠른 반면 이라크는 평균 다운로드 1.6Mbps, 업로드 0.7Mbps로 가장 느리다. 미국은 약 34Mbps의 모바일 다운로드 속도에서 세계 40위를 차지했으며 세계가 5G로 이동함에 따라 더 뒤처질 위험이 있습니다.

모바일 네트워크 연결 유형은 영국의 사용자 연결 중 84.7%가 4G를 사용하는 데 비해 미국은 93%, 한국은 97.5%입니다. 이는 우즈베키스탄의 50% 미만, 알제리, 에콰도르, 네팔, 이라크의 60% 미만과 비교됩니다.

광대역 데이터 비용

한편, 2018년 광대역 비용에 대한 연구에 따르면 니제르의 광대역 연결 비용은 '메가비트당 월간' 263달러입니다. 이 메트릭은 이해하기가 조금 어렵습니다. 예를 들면 다음과 같습니다. 한 국가에서 광대역 패키지의 평균 비용이 22달러이고 패키지에서 제공하는 평균 다운로드 속도가 10Mbps인 경우 '월 메가비트당' 비용은 다음과 같습니다. $2.20입니다.

이것은 흥미로운 지표이며 광대역 속도가 데이터 한도만큼 중요한 요소임을 인정하는 지표입니다. $263의 비용은 매우 느리고 매우 비싼 광대역의 조합을 의미합니다. 참고로 이 메트릭은 영국에서 $1.19, 미국에서 $1.26입니다.

아마도 이해하기 쉬운 것은 광대역 패키지의 평균 비용입니다. 이 연구는 이러한 패키지에 데이터 한도가 있는지 여부를 무시하고 제공되는 가장 저렴한 광대역 패키지를 찾고 있었기 때문에 데이터 자체의 비용보다는 유용한 수치를 제공합니다.

패키지 비용만으로 모리타니는 평균 $768.16($307.26 ~ $1,368.72 범위)로 세계에서 가장 비싼 광대역을 보유하고 있습니다. 이 막대한 비용에는 부동산에 물리적 라인을 구축하는 것이 포함됩니다. 모리타니에는 이미 거의 없기 때문입니다. 0.7Mbps의 속도로 모리타니는 또한 세계에서 가장 느린 광대역 네트워크 중 하나를 보유하고 있습니다.

대만은 평균 85Mbps의 속도로 세계에서 가장 빠른 광대역을 가지고 있습니다. 예멘은 0.38Mbps로 가장 느립니다. 그러나 잘 구축된 광대역 인프라를 갖춘 국가에서도 소위 '비점수'가 있습니다. 영국은 광대역 속도에서 207개국 중 34위를 차지했지만 2019년 7월에도 여전히 광대역이 없는 학교가 영국에 있었습니다.

영국에서 광대역 패키지의 평균 비용은 $39.58이고 미국에서는 $67.69입니다. 세계에서 가장 저렴한 평균은 우크라이나로 5달러에 불과하지만 가장 저렴한 광대역 거래는 키르기스탄에서 발견되었습니다(1.27달러 - 국가 평균인 108.22달러).

짐바브웨는 모바일 데이터 비용이 가장 많이 드는 국가였으며 평균 비용이 $128.71이고 '메가비트당 월' 비용이 $6.89로 광대역에 대한 통계가 그다지 좋지 않습니다.

절대 비용 대 실제 비용

지금까지 설명한 모든 비용은 연구 당시 환율을 기준으로 한 절대 비용(USD)입니다. 이러한 비용은 생활비에 포함되지 않았으며, 이는 많은 국가에서 비용이 실제로 실질 기준으로 훨씬 더 높다는 것을 의미합니다.

오늘 내 검색을 50MB로 제한하겠습니다. 짐바브웨에서는 모바일 데이터 요금으로 약 3.67달러입니다. 별 것 아닌 것처럼 들릴지 모르지만, 짐바브웨의 교사들은 급여가 하루 2.50달러로 떨어졌기 때문에 올해 파업을 벌였습니다.

비교를 위해 $3.67은 미국 최저 임금 $7.25의 절반 정도입니다. 짐바브웨 사람으로서 나는 이 50MB 데이터를 사기 위해 돈을 벌기 위해 약 하루 반을 일해야 했습니다. 미국에서는 단 30분에 불과합니다. 국가 간의 생활비를 비교하는 것은 쉽지 않지만, 짐바브웨에서 50MB 데이터 비용으로 3.67달러는 최저 임금으로 미국인에게 52달러처럼 느껴질 것입니다.

실험 설정

Chrome을 시작하고 개발 도구를 열어 네트워크를 느린 3G 연결로 조절했습니다. 우즈베키스탄 사용자가 경험하는 것과 같은 느린 연결을 시뮬레이션하여 웹 사이트에서 어떤 경험을 제공하는지 확인하고 싶었습니다. 또한 저가형 장치에서 시뮬레이션하기 위해 CPU를 조절했습니다.

ModHeader를 설치하고 'Save-Data' 헤더를 설정하여 웹사이트에서 데이터 사용량을 최소화하고 싶다는 것을 알렸습니다. 이 헤더는 Android의 '라이트 모드'용 Chrome에서 설정한 헤더이기도 합니다. 이에 대해서는 나중에 자세히 설명하겠습니다.

TripMode를 다운로드했습니다. Mac에서 인터넷에 액세스할 수 있는 앱을 제어할 수 있는 Mac용 응용 프로그램입니다. 다른 모든 응용 프로그램의 인터넷 액세스는 자동으로 차단됩니다.

50MB 예산이 얼마나 소요될 것으로 예상합니까? 웹 페이지의 평균 무게가 거의 1.7MB라는 것은 내 예산에 약 29페이지가 있음을 의미합니다. 동일한 사이트에 머물고 브라우저 캐싱을 활용할 수 있다면 그보다 몇 페이지 더 많을 수도 있습니다.

실험 전반에 걸쳐 나는 첫 번째 콘텐츠가 포함된 페인트와 페이지의 인지된 로딩 시간을 가속화하기 위한 성능 팁을 제안할 것입니다. 이러한 팁 중 일부는 직접 전송되는 데이터의 양에 영향을 미치지 않을 수 있지만 일반적으로 덜 중요한 리소스의 다운로드를 연기하는 것과 관련이 있습니다. 느린 연결에서는 리소스가 다운로드되지 않고 데이터가 저장될 수 있습니다.

실험

더 이상 고민하지 않고 402KB의 예산과 0.03달러(내 짐바브웨 예산의 약 1%)를 사용하여 google.com을 로드했습니다.

전반적으로 나쁜 페이지 크기는 아니지만 24개의 네트워크 요청이 어디에서 오는지, 페이지를 더 가볍게 만들 수 있는지 여부가 궁금했습니다.

구글 홈페이지 — DOM

페이지 마크업을 보면 외부 스타일시트가 없습니다. 모든 CSS는 인라인입니다.

성능 팁 #1: 인라인 크리티컬 CSS

이것은 브라우저가 외부 스타일시트를 가져오기 위해 추가 네트워크 요청을 해야 하는 것을 줄여주기 때문에 성능에 좋습니다. 외부 스타일시트는 캐시할 수 있지만 인라인 스타일시트는 캐시할 수 없기 때문에 여기에서 절충점이 있습니다(자바스크립트를 능숙하게 다루지 않는 한).

일반적인 조언은 중요한 스타일(스크롤 없이 볼 수 있는 모든 것)이 인라인되고 나머지 스타일이 외부에 있고 비동기적으로 로드되도록 하는 것입니다. CSS의 비동기 로딩은 매우 영리한 HTML 라인에서 달성할 수 있습니다.

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

devtools는 DOM의 예쁜 버전을 보여줍니다. 실제로 브라우저에 다운로드된 내용을 보려면 소스 탭으로 전환하여 문서를 찾으십시오.

여기에 많은 인라인 JavaScript가 있음을 알 수 있습니다. 단순히 축소된 것이 아니라 축소되었다는 점은 주목할 가치가 있습니다.

성능 팁 #2: 자산 축소 및 미화

축소는 불필요한 공백과 문자를 제거하지만 실제로는 코드를 더 짧게 '혼합'합니다. 코드에 손대지 않은 소스 코드가 아니라 기계에서 생성된 짧은 변수 이름이 포함되어 있다는 신호입니다. 이것은 스크립트가 더 작고 다운로드가 더 빠르다는 것을 의미하기 때문에 좋습니다.

그럼에도 불구하고 인라인 스크립트는 210KB 페이지 리소스 중 약 120KB로 보입니다(60KB gzip 크기의 약 절반). 또한 다운로드한 402KB 중 291KB에 해당하는 5개의 외부 JavaScript 파일이 있습니다.

즉, JavaScript가 전체 페이지 무게의 약 80%를 차지합니다.

이것은 쓸모없는 JavaScript가 아닙니다. 입력할 때 제안 사항을 표시하려면 Google에 몇 가지가 있어야 합니다. 하지만 대부분은 추적 코드와 광고 설정 때문인 것 같습니다.

비교를 위해 JavaScript를 비활성화하고 페이지를 다시 로드했습니다.

JS 비활성화된 버전의 Google 검색은 402KB가 아닌 102KB에 불과합니다. Google은 이러한 조건에서 자동 제안을 제공할 수 없지만 사이트는 여전히 작동하며 데이터 사용량을 이전의 4분의 1로 줄였습니다. 장기적으로 데이터 사용을 정말 제한해야 한다면 가장 먼저 할 일은 JavaScript를 비활성화하는 것입니다. 소리만큼 나쁘지 않습니다.

성능 팁 #3: 적을수록 좋습니다

에셋을 인라인하고, uglifying하고, 축소하는 것은 모두 훌륭하지만 최고의 성능은 애셋을 먼저 보내지 않는 데서 나옵니다.

• 새로운 기능을 추가하기 전에 성능 예산이 확보되어 있습니까?
• 사이트에 JavaScript를 추가하기 전에 일반 HTML을 사용하여 기능을 수행할 수 있습니까? (예: HTML5 양식 유효성 검사).
• 큰 JavaScript 또는 CSS 라이브러리를 애플리케이션으로 가져오기 전에 bundlephobia.com과 같은 것을 사용하여 크기를 측정하십시오. 편리함은 무게만큼 가치가 있습니까? 훨씬 작은 데이터 크기에서 바닐라 코드를 사용하여 동일한 작업을 수행할 수 있습니까?

리소스 정보 분석

여기에서 풀어야 할 것이 많으니 크래킹을 해보자. 플레이할 수 있는 공간이 50MB뿐이므로 이 페이지 로드의 모든 비트를 우유로 만들 것입니다. 짧은 Chrome Devtools 자습서를 시작하세요.

402KB가 전송되었지만 1.1MB의 리소스: 이것이 실제로 의미하는 바는 무엇입니까?

이는 402KB의 콘텐츠가 실제로 다운로드되었지만 압축된 형식(gzip 또는 brotli와 같은 압축 알고리즘 사용)임을 의미합니다. 그런 다음 브라우저는 의미 있는 것으로 압축을 풀기 위해 몇 가지 작업을 수행해야 했습니다. 압축을 푼 데이터의 총 크기는 1.1MB입니다.

이 압축 풀기는 무료가 아닙니다. 리소스 압축을 푸는 데 몇 밀리초의 오버헤드가 있습니다. 그러나 유선으로 1.1MB를 보내는 것과 비교하면 무시할 수 있는 오버헤드입니다.

성능 팁 #4: 텍스트 기반 자산 압축

일반적으로 gzip과 같은 것을 사용하여 항상 자산을 압축합니다. 그러나 이미지 및 기타 바이너리 파일에 압축을 사용하지 마십시오. 소스에서 미리 최적화해야 합니다. 압축하면 실제로 더 커질 수 있습니다.

그리고 가능하면 1500바이트 이하의 파일을 압축하지 마십시오. 가장 작은 TCP 패킷 크기는 1500바이트이므로, 예를 들어 800바이트로 압축하면 여전히 동일한 바이트 패킷으로 전송되기 때문에 아무것도 절약할 수 없습니다. 다시 말하지만 비용은 무시할 수 있지만 서버에서는 약간의 압축 CPU 시간을 낭비하고 클라이언트에서는 압축 해제 CPU 시간을 낭비합니다.

이제 Chrome의 네트워크 탭으로 돌아가서 우선 순위를 살펴보겠습니다. 리소스의 우선 순위는 "가장 높음"에서 "가장 낮음"입니다. 이것은 다운로드해야 할 더 중요한 리소스에 대한 브라우저의 최선의 추측입니다. 우선 순위가 높을수록 브라우저가 자산 다운로드를 더 빨리 시도합니다.

성능 팁 #5: 브라우저에 리소스 힌트 제공

브라우저는 우선 순위가 가장 높은 자산이 무엇인지 추측하지만 <link rel="preload"> 태그를 사용하여 리소스 힌트를 제공하여 가능한 한 빨리 자산을 다운로드하도록 브라우저에 지시할 수 있습니다. 글꼴, 로고 및 스크롤 없이 볼 수 있는 부분에 표시되는 기타 항목을 미리 로드하는 것이 좋습니다.

캐싱에 대해 알아보겠습니다. ALT 키를 누른 상태에서 마우스 오른쪽 버튼을 클릭하여 열 머리글을 변경하여 더 유용한 정보를 잠금 해제하겠습니다. Cache-Control을 확인하겠습니다.

Cache-Control은 리소스를 캐시할 수 있는지 여부, 캐시할 수 있는 기간 및 재검증에 대해 따라야 하는 규칙을 나타냅니다. 적절한 캐시 값을 설정하는 것은 반복 방문의 데이터 비용을 줄이는 데 중요합니다.

성능 팁 #6: 캐시 가능한 모든 자산에 캐시 제어 헤더 설정

cache-control 값은 public 또는 private 지시문으로 시작하고 그 뒤에 만료 값이 옵니다(예: max-age=31536000 ). 지시문은 무엇을 의미하며 이상하게 구체적인 max-age 값은 무엇입니까?

값 31536000 은 1년에 있는 초 수이며 캐시 제어 사양에서 허용하는 이론상 최대값입니다. 이 값이 모든 정적 자산에 적용되는 것을 보는 것은 일반적이며 사실상 "이 자원은 변경되지 않을 것"을 의미합니다. 실제로 브라우저는 1년 내내 캐시하지 않지만 합리적인 기간 동안 자산을 ​​캐시합니다.

public/private 지시어를 설명하려면 서버 외부에 존재하는 두 가지 주요 캐시를 설명해야 합니다. 첫째, 리소스가 사용자의 컴퓨터('클라이언트')에 저장되는 전통적인 브라우저 캐시가 있습니다. 그리고 클라이언트와 서버 사이에 있는 CDN 캐시가 있습니다. 리소스는 CDN이 원본 서버에서 반복해서 리소스를 요청하는 것을 방지하기 위해 CDN 수준에서 캐시됩니다.

public 의 Cache-Control 지시문을 사용하면 클라이언트와 CDN 모두에서 리소스를 캐시할 수 있습니다. private 값은 클라이언트만 캐시할 수 있음을 의미합니다. CDN은 안됩니다. 이 후자의 값은 일반적으로 인증 뒤에 존재하는 페이지 또는 자산에 사용됩니다. 여기서 클라이언트에 캐시하는 것은 괜찮지만 개인 정보를 CDN에 캐시하고 다른 사용자에게 전달하여 개인 정보를 누출하고 싶지는 않습니다.

내 주의를 끈 한 가지는 Google 로고에 "비공개"의 캐시 제어 기능이 있다는 것입니다. 페이지의 다른 이미지에는 공용 캐시가 있으며 로고가 다르게 취급되는 이유를 모르겠습니다. 아이디어가 있으면 댓글로 알려주세요!

페이지를 새로 고쳤고 페이지 자체를 제외하고 대부분의 리소스가 캐시에서 제공되었습니다. 페이지 자체는 이미 보았듯이 private, max-age=0 )이며, 이는 캐시할 수 없음을 의미합니다. 이것은 사용자가 새로 고칠 때 항상 최신 페이지를 가져오는 것이 중요한 동적 웹 페이지의 경우 정상입니다.

이 시점에서 저는 devtools에서 '설명' URL을 실수로 클릭했는데, 이 URL로 인해 네트워크 분석 참조로 이동하여 예산의 약 5MB를 소비했습니다. 죄송합니다.

Google 개발자 문서

이 새로운 5MB 페이지 중 4.2MB가 이미지로 축소되었습니다. 특히 SVG. 그 중 가장 무거운 것은 186KB로 특별히 크지는 않습니다. 너무 많아서 한 번에 모두 다운로드되었습니다.

그 5MB 페이지 로드는 오늘 내 예산의 10%였습니다. 지금까지 나는 구글 홈페이지의 자바스크립트가 없는 재로드를 포함하여 5.5MB를 사용했고 $0.40를 썼다. 이 페이지를 열 생각은 없었습니다.

여기서 더 나은 사용자 경험은 무엇이었습니까?

성능 팁 #7: 이미지 지연 로드

일반적으로 실수로 링크를 클릭하면 브라우저에서 뒤로 버튼을 눌렀습니다. 나는 그 이미지를 다운로드해도 아무런 이익을 얻지 못했을 것입니다. 4.2MB의 낭비입니다!

일반적으로 자신이 무엇에 빠져 있는지 알고 있는 비디오 외에도 이미지는 웹에서 데이터 사용의 가장 큰 원인입니다. 세계 상위 500개 웹사이트에 대한 연구에 따르면 이미지는 평균 페이지 무게의 최대 53%를 차지합니다. "이는 페이지 로딩 시간과 그에 따른 전반적인 성능에 큰 영향을 미친다는 것을 의미합니다."

페이지 로드 시 모든 이미지를 다운로드하는 대신 페이지에 참여하는 사용자만 다운로드 비용을 지불하도록 이미지를 지연 로드하는 것이 좋습니다. 따라서 스크롤 없이 볼 수 있는 부분 아래로 스크롤하지 않기로 선택한 사용자는 절대 볼 수 없는 이미지를 다운로드하는 데 불필요한 대역폭을 낭비하지 않습니다.

좋은 연결에 있는 이미지, 나쁜 연결에 있는 이미지 및 JavaScript가 비활성화된 이미지 사이에 좋은 균형을 제공하는 이미지 지연 로드 롤아웃에 대한 훌륭한 css-tricks.com 가이드가 있습니다.

이 페이지가 위의 가이드에 따라 지연 로드를 구현했다면 기본적으로 38개의 SVG 각각이 1KB 자리 표시자 이미지로 표시되고 스크롤할 때만 보기에 로드되었을 것입니다.

성능 팁 #8: 이미지에 적합한 형식 사용

PNG에 비해 크기가 26% 작고(품질 손실이 없음) JPEG에 비해 크기가 25-34% 작은 이미지 형식인 WebP를 사용하지 않음으로써 Google이 속임수를 놓쳤다고 생각했습니다. 비슷한 품질). SVG를 WebP로 변환해야 한다고 생각했습니다.

WebP로 변환하면 SVG 중 하나가 186KB에서 65KB로 줄어들었지만 실제로 이미지를 나란히 보면 WebP가 거칠게 나왔습니다.

그런 다음 PNG 중 하나를 WebP로 변환하려고 시도했습니다. WebP는 무손실이어야 하며 더 작아야 합니다. 그러나 WebP 출력은 *더 무겁습니다*(109KB에서 127KB)!

이것은 나를 놀라게 했다. WebP는 우리가 생각하는 은색 총알이 아니며 Google조차도 이 페이지에서 사용하는 것을 소홀히 했습니다.

그래서 제 조언은 가능하면 이미지별로 다양한 이미지 형식을 실험해 보는 것입니다. 가장 작은 크기에 최상의 품질을 유지하는 형식이 예상한 형식이 아닐 수 있습니다.

이제 DOM으로 돌아갑니다. 나는 이것을 발견했다 :

Google 분석 스크립트의 async 키워드가 보이시나요?

문서 헤드의 첫 번째 항목 중 하나임에도 불구하고 async 키워드를 사용하여 차단 요청이 되지 않도록 명시적으로 선택했기 때문에 우선 순위가 낮습니다.

차단 요청은 페이지 렌더링을 중지하는 요청입니다. <script> 호출은 기본적으로 차단되어 스크립트가 다운로드, 컴파일 및 실행될 때까지 HTML 구문 분석을 중지합니다. 이것이 전통적으로 문서 끝에 <script> 호출을 넣는 이유입니다.

성능 팁 #9: 차단 스크립트 호출을 작성하지 마십시오.

async 속성을 <script> 태그에 추가하여 브라우저에 페이지 렌더링을 중지하지 말고 백그라운드에서 스크립트를 다운로드하도록 지시합니다. 스크립트가 다운로드될 때까지 HTML이 여전히 구문 분석 중이면 스크립트가 실행되는 동안 구문 분석이 일시 중지되었다가 다시 시작됩니다. 이것은 <script> 가 발생하자마자 렌더링을 차단하는 것보다 훨씬 낫습니다.

미묘하게 다른 defer 속성도 있습니다. <script defer> 는 스크립트가 백그라운드에서 로드되는 동안 브라우저에 페이지를 렌더링하도록 지시하며, 스크립트가 다운로드될 때까지 HTML이 여전히 구문 분석 중이더라도 스크립트는 실행되기 전에 페이지가 렌더링될 때까지 기다려야 합니다. . 이렇게 하면 스크립트가 완전히 차단되지 않습니다. 자세한 내용은 "지연 및 비동기를 사용하여 JavaScript를 효율적으로 로드"를 참조하세요.

어쨌든 충분한 구글 해부. 다른 사이트를 시도해 볼 시간입니다. 아직 예산이 거의 45MB 남았습니다!

아마존

아마존 홈페이지는 총 무게 약 6MB로 로드되었습니다. 그 중 하나는 페이지에서도 찾을 수 없는 587KB 이미지였습니다. 이것은 PNG로, 아마도 선명한 텍스트를 가지고 있지만 사진 배경에 - 성능에 끔찍한 고전적인 조합입니다.

사실 내 네트워크 탭에는 페이지에서 실제로 볼 수 없는 수백 킬로바이트의 이미지가 몇 개 있었습니다. Amazon 어딘가에서 잘못된 구성이 의심되지만 이러한 보이지 않는 이미지가 결합되어 내 데이터의 최소 1MB를 씹었습니다.

영웅 이미지는 어떻습니까? 페이지의 기본 이미지이며 전송된 크기는 94KB에 불과하지만 텍스트와 축구 선수 주변에서 바로 자르면 크기가 약 15% 줄어들 수 있습니다. 그런 다음 이미지에 있는 것과 동일한 배경색을 CSS에 적용할 수 있습니다. 이것은 텍스트의 가독성을 유지하면서 더 작은 화면으로 크기를 조정할 수 있다는 추가적인 이점이 있습니다.

한 번 말했지만 다시 한 번 말하겠습니다. 이미지를 최적화하고 지연 로드하는 것은 사이트의 페이지 가중치에 대해 얻을 수 있는 가장 큰 이점입니다 .

이미지 최적화는 지금까지 가장 중요한 데이터 감소를 제공했습니다. JavaScript가 전체 성능에 더 큰 영향을 미치지만 데이터 감소가 아닌 경우를 만들 수 있습니다. 이미지를 최적화하거나 제거하는 것은 훨씬 가벼운 경험을 보장하는 안전한 방법이며 Data Saver가 의존하는 기본 최적화입니다.
— Tim Kadlec, Chrome Lite 페이지 이해하기

아마존에 공평하게 브라우저를 모바일 크기로 조정하고 페이지를 새로 고침하면 사이트가 모바일에 최적화되고 총 페이지 무게는 2.1MB에 불과합니다.

그러나 이것은 나를 다음 요점으로 안내합니다 ...

성능 팁 #10: 데이터 연결에 대해 가정하지 마십시오

데스크탑의 누군가가 광대역 연결을 사용 중인지 아니면 데이터가 제한된 동글이나 모바일을 통해 테더링을 하고 있는지 감지하기 어렵습니다. 많은 사람들이 그렇게 기차에서 일하거나 광대역 인프라가 열악하지만 모바일 신호가 강한 지역에 살고 있습니다. Amazon의 경우 데스크톱 사이트에서 빅 데이터를 절약할 수 있는 여지가 있으며 화면 크기가 모바일 장치를 사용하지 않는다는 이유로 안주해서는 안 됩니다.

예, 뷰포트가 '데스크톱 크기'인 경우 이미지가 더 거칠고 모바일보다 화면에 더 잘 최적화되므로 더 많은 페이지 로드를 예상해야 합니다. 그러나 페이지가 수십 배는 커야 합니다.

또한 요청과 함께 Save-Data 헤더를 보내고 있었습니다. 이 헤더는 데이터 사용량 감소에 대한 기본 설정을 명시적으로 나타내며 앞으로 더 많은 웹사이트에서 이를 인식하기 시작하기를 바랍니다.

초기 '데스크톱' 로드는 6MB였을 수 있지만 잠시 앉아서 시청한 후 우선 순위가 낮은 리소스와 이벤트 추적이 실행되면서 8.6MB로 증가했습니다. 이 페이지 무게에는 거의 1.7MB의 축소된 JavaScript가 포함됩니다. 나는 그것을 보기 시작 하고 싶지도 않다.

성능 팁 #11: JavaScript에 웹 작업자 사용

1.7MB의 JavaScript와 1.7MB의 이미지 중 어느 것이 더 나쁠까요? 대답은 JavaScript입니다. 성능 면에서 두 자산은 동일하지 않습니다.

JPEG 이미지는 디코딩, 래스터화 및 화면에 페인팅해야 합니다. JavaScript 번들은 다운로드한 다음 구문 분석, 컴파일, 실행해야 하며 엔진이 완료해야 하는 다른 여러 단계가 있습니다. 이러한 비용은 완전히 동일하지 않습니다.
— Addy Osmani, 2018년 JavaScript 비용

이만큼의 JavaScript를 제공해야 하는 경우 웹 작업자에 넣어 보십시오. 이렇게 하면 메인 스레드에서 JavaScript의 대부분을 유지하고, 이제 UI를 다시 칠할 수 있게 되어 웹 페이지가 저전력 장치에서 응답을 유지할 수 있습니다.

현재 예산은 약 15.5MB이며 짐바브웨 데이터 예산 중 1.14달러를 지출했습니다. 여기까지 오려면 돈을 벌기 위해 교사로 반나절을 일해야 했습니다.

핀터레스트

Pinterest의 성능에 대해 좋은 소식을 듣고 테스트하기로 결정했습니다.

아마도 이것은 가장 공정한 테스트가 아닐 것입니다. 비동기 프로세스가 있는 로그인 페이지로 이동하여 Facebook에 로그인하고 자동으로 로그인했습니다. 페이지는 상대적으로 빠르게 로드되었지만 점점 더 많은 콘텐츠가 미리 로드되면서 요청이 급증했습니다.

그러나 후속 페이지 로드에서 서비스 워커가 콘텐츠의 많은 부분을 노출시키는 것을 확인하여 페이지 무게의 약 절반을 절약했습니다.

Pinterest 사이트는 프로그레시브 웹 앱입니다. CSS와 JS의 캐싱을 수동으로 처리하기 위해 서비스 워커를 설치했습니다. 이제 WiFi를 끄고 사이트를 계속 사용할 수 있습니다(매우 유용하지는 않지만).

성능 팁 #12: 서비스 워커를 사용하여 오프라인 지원 제공

네트워크를 통해 웹사이트를 한 번만 로드하면 오프라인 상태에서도 필요한 모든 정보를 얻을 수 있다면 좋지 않을까요?

한 주의 일기 예보를 보여주는 웹사이트가 좋은 예입니다. 해당 페이지를 한 번만 다운로드하면 됩니다. 모바일 데이터를 끄고 나중에 어느 시점에서 페이지로 돌아가면 마지막으로 알려진 콘텐츠를 나에게 제공할 수 있어야 합니다. 인터넷에 다시 연결하고 페이지를 로드하면 더 최신 예측을 얻을 수 있지만 CSS 및 이미지와 같은 정적 자산은 여전히 ​​서비스 워커에서 로컬로 제공되어야 합니다.

이는 캐시된 페이지에 오프라인으로 다시 액세스할 수 있도록 우수한 캐시 전략으로 서비스 작업자를 설정하여 가능합니다. lodash 문서 웹사이트는 서비스 워커의 좋은 예입니다.

거의 업데이트되지 않고 매우 정기적으로 사용될 가능성이 있는 콘텐츠는 서비스 작업자 치료를 위한 완벽한 후보입니다. 끊임없이 변화하는 뉴스 피드가 있는 동적 사이트는 오프라인 경험에 그다지 적합하지 않지만 여전히 이점이 있습니다.

서비스 작업자는 데이터 예산이 빠듯할 때 진정으로 하루를 절약할 수 있습니다. Pinterest 경험이 데이터 사용 측면에서 가장 최적이라고 확신할 수 없습니다. 이후 페이지는 이미지가 거의 없는 페이지에서도 약 0.5MB 표시되었습니다. 그러나 JavaScript가 페이지 요청을 처리하고 동일한 탐색 요소를 제자리에 유지하도록 합니다. 매우 성능이 좋을 수 있습니다. BBC는 단일 페이지 애플리케이션을 통해 렌더링할 수 있는 기사에 대한 재방문을 위해 단 3.1KB의 전송 크기를 관리합니다.

지금까지 Pinterest만으로도 14MB를 씹어 먹었습니다. 즉, 예산의 약 30MB 또는 짐바브웨 예산의 2.20달러(거의 하루 급여)를 날렸습니다.

나는 나의 마지막 20MB를 조심하는 것이 더 좋을 것입니다… 그러나 거기에 재미가 어디 있습니까?

게임스팟

과거에 모바일에서 눈에 띄게 느려지는 느낌이 들었고 그 이유를 파헤치고 싶었기 때문에 이것을 선택했습니다. 물론 홈페이지를 로드하는 데 8.5MB의 데이터가 소모됩니다.

이 중 6.5MB는 페이지 중간에 자동 재생되는 비디오에 사용되었으며, 공정하게 말해서 스크롤을 시작할 때까지 다운로드되지 않은 것으로 나타났습니다. 그럼에도 불구하고…

내 뷰포트에서 비디오의 절반만 볼 수 있었습니다. 오른쪽이 잘렸습니다. 그것은 또한 30초 길이였고, 나는 대부분의 사람들이 앉아서 전체를 보지 않을 것이라고 장담할 것입니다. 이 단일 자산은 페이지 크기를 3배 이상 늘렸습니다.

성능 팁 #13: 비디오를 미리 로드하지 마십시오

일반적으로 사이트의 기본 통신 모드가 비디오가 아닌 경우 사전 로드하지 마십시오.

YouTube 또는 Netflix인 경우 페이지를 방문하는 누군가가 비디오가 자동 로드 및 자동 재생되기를 원할 것이라고 가정하는 것이 합리적입니다. 비디오가 일부 데이터를 씹을 것이라는 기대가 있지만 콘텐츠에 대한 공정한 교환입니다. 그러나 기본 매체가 텍스트와 이미지인 사이트에서 우연히 추가 비디오 콘텐츠를 제공하는 경우 비디오를 미리 로드하지 마십시오.

비디오가 포함된 뉴스 기사를 생각해 보십시오. 많은 사용자는 다음 항목으로 넘어가기 전에 기사 헤드라인만 훑어보고 싶어합니다. 다른 사람들은 기사를 읽지만 삽입은 무시합니다. 그리고 다른 사람들은 각 임베디드 비디오를 부지런히 클릭하고 볼 것입니다. 우리는 모든 사용자가 이 비디오를 보고 싶어 한다는 가정 하에 대역폭을 낭비해서는 안 됩니다.

다시 말하지만 사용자는 비디오 자동 재생을 좋아하지 않습니다. 개발자로서 우리는 관리자가 하라고 했을 때만 하고 가장 멋진 앱은 모두 하고 있기 때문에 하라고 하고 가장 멋진 앱은 비디오 광고가 기존보다 20~50배 더 ​​많은 수익을 창출하기 때문에 그렇게 합니다. 광고. Google 크롬은 개인 취향에 따라 일부 사이트에 대한 자동 재생 동영상을 차단하기 시작했습니다. 따라서 사이트를 동영상 자동 재생 기능으로 개발하더라도 사용자에게 이러한 경험이 제공된다는 보장은 없습니다.

동영상을 옵트인 경험(클릭하여 재생)으로 만드는 것이 좋다는 데 동의하는 경우 한 단계 더 나아가 클릭하여 로드하도록 할 수 있습니다. 즉, 재생 버튼이 있는 비디오 자리 표시자 이미지를 조롱하고 재생 버튼을 클릭할 때만 비디오를 다운로드합니다. 빠른 연결을 사용하는 사람들은 버퍼 속도의 차이를 느끼지 못할 것이며 느린 연결을 사용하는 사람들은 대용량 비디오 파일을 미리 로드할 필요가 없기 때문에 나머지 사이트가 얼마나 빨리 로드되는지 이해할 것입니다.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

그게 다야 That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

라이트 모드는 HTTPS URL을 Google과 공유하므로 시크릿 모드에서는 이 모드를 사용할 수 없습니다. 그러나 쿠키, 로그인 정보 및 개인화된 페이지 콘텐츠와 같은 기타 정보는 ghack.net에 따르면 Google과 공유 되지 않으며 "Chrome과 웹사이트 간의 보안 연결을 절대 끊지 않습니다". 이러한 데이터 절약 서비스 중 어떤 것도 iOS에서 허용되지 않는 것처럼 보이는 이유가 궁금합니다(그리고 iOS에서 라이트 모드를 사용할 수 있는지 여부에 대한 뉴스는 없습니다).

데이터 세이버 프록시에는 상당한 신뢰가 필요합니다. 귀하의 검색 활동, 쿠키 및 기타 민감한 정보는 종종 다른 국가의 일부 서버에 위탁됩니다. 많은 사이트가 HTTPS로 이동했기 때문에 많은 프록시가 더 이상 작동하지 않습니다. 즉, 터보 모드와 같은 이니셔티브는 대부분 "쓸모 없는 기능"이 되었습니다. HTTPS는 이러한 종류의 중간자(man-in-middle) 동작을 방지합니다. 이는 이러한 프록시 서비스 중 일부의 소멸을 의미하고 연결 상태가 좋지 않은 사용자가 사이트에 덜 액세스할 수 있게 했음에도 불구하고 좋은 일입니다.

나는 Firefox용 Bandwidth Hero(자신의 데이터 압축 서비스를 설정해야 함 - 대부분의 사용자의 기술 능력을 훨씬 능가합니다!) 및 skyZIP Proxy(최종 업데이트에서 2017과 오타로 가득 차서 나는 나를 믿을 수 없었습니다).

결론

웹 사이트의 데이터 공간을 줄이는 것은 프론트엔드 성능을 향상시키는 것과 밀접한 관련이 있습니다. 사이트 속도를 높이기 위해 할 수 있는 가장 신뢰할 수 있는 방법입니다.

데이터 비용 외에도 GOV.UK 블로그 게시물에 설명된 것처럼 성능에 집중해야 하는 좋은 이유가 많이 있습니다.

• 사용자의 53%는 로드하는 데 3초 이상 걸리면 모바일 사이트를 포기합니다.
• 사람들은 느린 연결을 사용하여 웹사이트에서 간단한 작업을 완료하려고 할 때 50% 더 집중해야 합니다.
• 성능이 좋은 웹 페이지는 사용자 장치의 배터리 수명에 더 좋으며 일반적으로 전달하는 데 필요한 서버 전력이 더 적습니다. 성능 사이트는 환경에 좋습니다.

우리는 데이터 불평등의 글로벌 비용을 변경할 힘이 없습니다. 그러나 우리는 그 영향을 줄이고 그 과정에 있는 모든 사람의 경험을 개선할 수 있는 힘이 있습니다.