해리 로버츠와 함께하는 스매싱 팟캐스트 에피소드 34: 웹 성능의 상태는?

게시 됨: 2022-03-10

빠른 요약 ↬ 이 에피소드에서는 웹 성능에 대해 이야기합니다. 2021년 실적 전망은? Drew McLellan이 전문가인 Harry Roberts와 대화하여 알아봅니다.

이 에피소드에서는 웹 성능에 대해 이야기합니다. 2021년 실적 전망은? 나는 그것을 알아보기 위해 전문가인 해리 로버츠와 이야기를 나눴다.

메모 표시

Harry는 2021년 5월에 Smashing과 함께 Web Performance Masterclass 워크숍을 운영하고 있습니다. 출판 당시에는 큰 얼리버드 할인이 여전히 가능합니다.

트위터의 해리
해리의 컨설팅 사이트 CSS Wizardry
비디오 과정 15% 할인 을 포함하여 CSS Wizardry를 빠르게 만들기 위해 내가 한 모든 것
15% 할인 을 포함한 컨설턴트 eBook을 위한 질문
Web Vitals에 대한 Web.dev 가이드
Drew가 가장 좋아하는 OXO GoodGrips 에그 비터

주간 업데이트

웹 디자인 트렌드 2021: Suzanne Scacca가 작성한 보고서
Fortune Ikechi가 작성한 React 애플리케이션에서 Grommet 사용
John Agbanusi가 작성한 Ethereum Blockchain용 Node.js API를 빌드하는 방법
Vitaly Friedman이 작성한 SmashingMag 성능 개선 방법
베카 케네디가 작성한 프리랜서 프로젝트를 거부할 때

성적 증명서

찰리 제라드의 사진 Drew McLellan: 그는 영국 리즈의 독립 컨설턴트 웹 성능 엔지니어입니다. 그의 역할에서 그는 세계에서 가장 크고 가장 존경받는 일부 조직이 고객에게 더 빠르고 안정적인 경험을 제공하도록 돕습니다. 그는 초대된 Google 개발자 전문가, Cloudinary Media 개발자 전문가, 수상 경력에 빛나는 개발자이자 국제 연사입니다. 그래서 우리는 그가 웹 성능에 관해서 자신의 것을 알고 있다는 것을 알고 있지만 그가 14개의 팔과 7개의 다리를 가지고 있다는 것을 알고 계셨습니까? 내 스매싱 친구들이여, 해리 로버츠를 환영하십시오. 해리, 안녕하십니까?

해리 로버츠: 헤이, 정말 감사합니다. 분명히 14개의 팔, 7개의 다리... 여전히 일반적인 문제를 제기하고 있습니다. 바지 구매가 불가능합니다.

드류: 그리고 자전거도요.

해리: 네. 글쎄, 나는 세 대 반의 자전거를 가지고 있습니다.

Drew: 그래서 저는 불행하게도 그 자체로 재미있겠지만 자전거에 대한 이야기가 아니라 오늘 당신과 이야기하고 싶었습니다. 웹 성능에 대해 이야기하고 싶었습니다. 개인적으로 정말 열광하는 주제인데 공에서 눈을 떼고 다른 일에 몰두했다가 다시 약간의 퍼포먼스 작업을 할 때, 걱정되는 부분 중 하나입니다. 내가 작업하고 있는 지식이 정말 빨리 구식이 되지 않을까 걱정이 됩니다. 요즘 웹 성능이 내가 인식하는 것처럼 빠르게 변화하고 있습니까?

Harry: 이것은… 단지 당신에게 좋은 말을 하려는 것이 아닙니다. 제가 최근에 이것에 대해 꽤 많이 생각해 보았기 때문에 그것은 좋은 질문입니다. 내가 시도하고 고객에게 말하고 싶은 한 가지는 실제로는 그렇게 빨리 움직이지 않는다는 것입니다. 내가 항상 사용하는 사운드 바이트이기 때문에 주로 브라우저에 내기를 걸 수 있습니다. 브라우저는 기본적으로 작동 방식을 변경할 수 없습니다. 물론 브라우저가 유지해야 하는 20년의 유산이 있기 때문입니다. 따라서 일반적으로 브라우저에 내기를 걸고 이러한 내부 구조와 TCP/IP가 변경되지 않는 방식을 알고 있다면… 기본과 관련된 모범 사례.

Harry: 더 흥미로워지는 부분은... 제가 점점 더 많이 보고 있는 것은 사이트 속도 문제와 관련하여 우리 스스로를 궁지에 몰아넣고 있다는 것입니다. 그래서 우리는 실제로 우리 자신을 위해 많은 문제를 만듭니다. 이것이 현실적으로 의미하는 바는 성능입니다. 움직이는 골대라고 생각합니다. 웹의 지형이나 지형이 변화할수록 웹이 구축되는 방식과 작업 방식이 변경될수록 우리는 새로운 도전에 직면하게 됩니다. 따라서 클라이언트에서 더 많은 작업을 수행하는 출현은 5년 전에 해결했던 것과는 다른 성능 문제를 제기하지만 이러한 성능 문제는 여전히 5년 동안 대체로 변경되지 않은 브라우저 내부와 관련이 있습니다. 많은 부분이 달려 있습니다... 그리고 분명히 두 가지 측면이 있다고 말씀드리고 싶습니다... 저는 고객이 브라우저에 의존하고 표준에 의존하도록 권장합니다. . 그러나 물론 이는 보다 현대적이고 아마도 약간 더 흥미로운 개발 관행과 융합되어야 합니다. 그래서 당신은 당신의…

Drew: 기본은 바뀌지 않고 TCP/IP와 같은 것은 바뀌지 않는다고 말씀하셨습니다. 에서 변경된 사항 중 하나는... "최근"이라고 합니다. 이것은 실제로 이제 약간 뒤로 돌아가고 있지만 클라이언트와 서버 간의 통신을 위해 이 프로토콜 HTTP를 설정했다는 점에서 HTTP입니다. 우리는 모두 바이너리이고 다른 H2를 얻었습니다. 그리고 그것은 많은 것을 바꿨습니다. 그것은 성능상의 이유로 기존 제한 사항 중 일부를 없애는 것이 었습니다. 그러나 그것은 변경이었고 해당 프로토콜에 대해 최적화해야 하는 방식이 변경되었습니다. 이제 안정적인가요? 아니면 또 바뀔지, 아니면...

Harry: 그래서 제가 더 배우고 싶은 것은 질문의 후반부, 다시 변경하는 것입니다. QUIC 및 H3에 대해 더 살펴봐야 하지만 내 고객에게 유용하기에는 너무 먼 이야기입니다. H2에 관해서는 상황이 많이 바뀌었지만 진심으로 H2는 많은 거짓 약속이라고 생각하고 선을 넘었다고 생각합니다. H1이 출시 된 것을 고려하면 놀라운 일입니다. 그리고 1.1이 1997 년이었고, 그래서 우리는 H2에서 작업할 시간이 많습니다.

Harry: 나는 그것을 이해하거나 현재 비행 요청에서 무제한이라고 인식하는 웹 개발자가 주요 이점이라고 생각합니다. 따라서 한 번에 6개의 디스패치 및/또는 6개의 진행 중 요청이 아니라 잠재적으로 무제한입니다. 하지만 정말 흥미로운 문제가 있습니다. 왜냐하면… 시각 보조 장치 없이는 설명하기가 매우 어렵지만 H1을 실행하든 H2를 실행하든 간에 여전히 동일한 양의 대역폭을 사용할 수 있기 때문입니다. 프로토콜은 연결을 더 빠르게 만들지 않습니다. 따라서 한 번에 24개의 파일을 요청하여 네트워크를 플러딩할 수 있지만 이에 대한 충분한 대역폭이 없습니다. 따라서 한 번에 그 중 일부만 관리할 수 있기 때문에 실제로 더 빨라지는 것은 아닙니다.

Harry: 또한 파일이 응답하는 방식도 고려해야 합니다. 그리고 이것은 내가 클라이언트 워크숍 등에서 진행하는 또 다른 프로 팁입니다. 사람들은 H2 워터폴을 보고 전통적인 6개의 디스패치 요청 대신 24개의 요청을 볼 수 있음을 알게 될 것입니다. 24개의 요청을 디스패칭하는 것은 실제로 그렇게 유용하지 않습니다. 유용한 것은 이러한 응답이 반환될 때입니다. 그리고 24개의 요청을 보낼 수 있으므로 폭포의 왼쪽이 정말 멋지고 가파르게 보이지만 대역폭의 양을 제한해야 하기 때문에 모두 상당히 시차를 두고 순차적으로 반환됩니다. 모든 응답을 동시에 수행할 수는 없습니다.

Harry: 글쎄요, 다른 점은 모든 응답을 동시에 수행하는 경우 응답을 인터리브 처리해야 한다는 것입니다. 그래서 밤에 각 파일의 처음 10%를 얻고 다음 20%를 가져옵니다. JavaScript 파일의 20%는 쓸모가 없습니다. JavaScript는 100% 도착할 때까지 사용할 수 없습니다. 따라서 실제로 보게 될 것은 응답을 볼 때 H2 폭포가 나타나는 방식입니다... 어쨌든 H1과 훨씬 더 비슷하게 보이지만 훨씬 더 비틀거립니다. 그래서 H2는 너무 많이 팔렸거나 엔지니어들이 그것이 얼마나 효과적일 수 있는지에 대한 제한이 있다고 믿게 만들지 않았나 생각합니다. 자산을 과도하게 분할하는 사람들을 볼 수 있기 때문에 자산이 20개일 수 있습니다. 24개를 유지하겠습니다. 두 개의 큰 JS 파일 대신 24개의 작은 번들을 가질 수 있습니다. 그들은 여전히 상당히 순차적으로 돌아올 것입니다. 더 많은 대역폭을 마법처럼 사용하지 않았기 때문에 모두 동시에 도착하지 않습니다.

Harry: 그리고 다른 문제는 각 요청에 일정한 지연 시간이 있다는 것입니다. 따라서 두 개의 큰 파일을 요청하고 왕복 100밀리초와 다운로드 250밀리초, 즉 250밀리초의 두 배라고 가정해 보겠습니다. 최대 24개의 요청을 곱해도 지연 시간이 일정하므로 100밀리초로 결정했으므로 이제 2400밀리초의 지연 시간과 24배… 250밀리초 다운로드 대신 25밀리초 다운로드, 대기 시간이 일정하게 유지되고 더 많은 요청에 대해 대기 시간을 곱하기 때문에 실제로 더 오래 걸립니다. 그래서 나는 H2가 이 마법의 총알이라는 것을 읽었을 고객들을 보게 될 것입니다. 그들은 파편을 만들 것입니다 ... 오! 그들은 개발 프로세스를 단순화할 수 없었고 우리는 번들링이나 연결 등을 할 필요가 없습니다. 그리고 궁극적으로는 요청을 분산시킬 수 있었기 때문에 결국 느려질 것입니다. 이는 약속이었지만 대기 시간은 일정하게 유지되어 실제로 브라우저에서 n배 더 많은 대기 시간을 갖게 됩니다. 내가 말했듯이, 시각적으로 그것을 설명하는 것은 정말 힘들고 아마 무의미할 것입니다. 하지만 사람들이 기대하는 것과 비교하여 H2가 어떻게 스스로를 드러내는지는 놀랍습니다.

Drew: 전체 로트를 얻는 데 여전히 같은 시간이 걸리지만 24일 후 첫 번째 로트의 100%를 얻을 때까지 작업을 시작할 수 있고 할 수 있다는 점에서 샤딩 프로세스에 여전히 이점이 있습니까? 24일이 끝나기 전에 실행을 시작하십시오.

해리: 아, 또 좋은 질문이군요. 따라서 일이 제대로 진행되고 더 H1처럼 보이는 응답으로 나타난다면 아이디어는 파일 1이 먼저 반환되고, 2, 3, 4가 반환된 다음 도착하는 순서대로 실행할 수 있다는 것입니다. 따라서 실제로 동시에 도착하도록 하여 집계 시간을 단축할 수 있습니다. 워터폴 대신 웹 페이지를 살펴보고 요청이 인터리브 처리된 것을 발견했다면 이는 좋지 않은 소식입니다. 왜냐하면 내가 말했듯이 JavaScript 파일의 10%는 쓸모가 없기 때문입니다.

Harry: 서버가 제대로 작업을 수행하고 전송, 전송, 전송, 전송, 전송, 그러면 더 빨라질 것입니다. 그러면 캐싱 전략이 더 세분화될 수 있는 연쇄적인 이점을 얻게 됩니다. 날짜 선택 위젯에서 글꼴 크기를 업데이트하는 것은 정말 짜증나는 일입니다. H1 세계에서는 사이트의 넓은 CSS의 200킬로와트 정도를 캐시해야 합니다. 반면에 지금은 bust datepicker.css를 캐시하기만 하면 됩니다. 따라서 우리는 이와 같은 파생 혜택을 얻었으며, 이는 확실히 매우 가치가 있습니다.

Drew: 내 생각에, 마술처럼 모든 요청을 한 번에 돌려받는 시나리오에서 클라이언트를 잠재적으로 방해할 가능성이 있지 않습니까?

해리: 네, 잠재적으로요. 그러면 실제로 일어날 일은 클라이언트가 많은 리소스 스케줄링을 수행해야 하므로 결국 모든 응답이 동시에 반환되는 폭포수와 같은 결과를 얻게 됩니다. 그러면 도착한 마지막 응답과 실행 능력. 따라서 이상적으로는 JavaScript에 대해 이야기할 때 브라우저가 요청 순서, 기본적으로 정의한 순서대로 모두 요청하고 서버가 올바른 순서로 모두 반환하여 브라우저가 실행할 수 있기를 원할 것입니다. 올바른 순서로. 왜냐하면 당신이 말했듯이 그것들이 모두 동시에 반환된다면 당신은 한 번에 실행할 방대한 JavaScript를 갖게 되지만 여전히 일정을 잡아야 하기 때문입니다. 따라서 파일이 도착한 후 유용하게 사용되는 사이에 의심의 여지가 있을 수 있습니다. 그래서, 실제로, H1… 제 생각에는 이상적으로는 H2 요청 스케줄링, H1 스타일 응답이 필요한 것 같습니다. 그러면 도착할 때 유용하게 사용할 수 있습니다.

Drew: 그래서 당신은 기본적으로 당신이 그것을 아래로 스키를 탈 수 있는 것처럼 보이는 응답 폭포를 찾고 있습니다.

해리: 네, 맞습니다.

Drew: 하지만 낙하산은 필요하지 않을 겁니다.

해리: 네. 그리고 그것은 정말 어렵습니다... 큰 소리로 말하는 것이 정말 사소한 것처럼 들리지만 H2가 판매된 방식을 고려할 때 꽤... 어렵지 않다고 생각합니다. 그렇게 하면 내 고객이... 멍청하게 들리기 때문입니다... 하지만 설명하기에는 꽤 많은 일입니다. 그들에게 ... H1이 어떻게 작동하는지 생각하면 그렇게 나쁘지 않았습니다. 그리고 "오 예, 이제 알겠습니다"와 같은 응답을 받으면. 나는 전에 성능 엔지니어들에게 이것을 가르쳐야 했습니다. 내가 하는 일을 하는 사람들. 나는 성능 엔지니어들에게 우리는 요청이 있을 때 별로 신경 쓰지 않고 응답이 유용할 때 정말 중요하다는 것을 가르쳐야 했습니다.

Drew: 특히 지난 5년 동안 상황이 매우 빠르게 진행되는 것처럼 보이는 이유 중 하나는 성능이 Google의 큰 주제이기 때문입니다. 그리고 Google이 이와 같은 것 뒤에 무게를 두면 견인력을 얻습니다. 기본적으로 성능은 사용자 경험의 한 측면입니다. 그렇지 않습니까?

Harry: 오, 내 말은... 이것은 정말 좋은 팟캐스트입니다. 나는 30분 전에 이것에 대해 생각하고 있었습니다. 약속합니다. 30분 전에 이것에 대해 생각하고 있었습니다. 성능은 접근성이 적용됩니다. 당신은 누군가가 당신의 콘텐츠에 접근할 수 있는 기회를 보장하거나 늘리고 있습니다. 그리고 나는 접근성이 항상 그냥… 눈이 없는 사람들입니다. 앱이 아니라 웹사이트를 구축하기로 한 결정은… 더 많은 청중이 액세스할 수 있도록 결정했습니다. 예, 성능은 접근성이 적용되므로 사용자 경험입니다. 그리고 그 사용자 경험은 "누군가 귀하의 사이트를 경험할 수 있습니까?"로 귀결될 수 있습니다. 또는 "그 경험이 즐거웠습니까? 버튼을 클릭했을 때 적시에 응답했는가?” 그래서 저는 100% 동의하고 그것이 Google이 그것에 무게를 두는 많은 이유라고 생각합니다. 그것이 사용자 경험에 영향을 미치기 때문입니다. 누군가가 검색 결과를 신뢰하게 된다면 우리는 그 사람에게 그들은 미워하지 않을 것입니다.

Drew: 그리고 그것은... 당신이 생각하는 모든 것, 당신이 생각하는 모든 이점, 사용자 경험, 참여 증가와 같은 것, 그것은 확실히 사실이지 않습니까? 느린 경험보다 더 빨리 사용자를 사이트에서 멀어지게 하는 것은 없습니다. 너무 답답하지 않나요? 탐색이 명확하지 않을 수 있다는 것을 알고 있는 사이트를 사용하고 링크를 클릭하여 "이것이 내가 원하는 것입니까? 그렇지 않습니까?” 클릭을 하는 데 드는 비용은 그저 기다리기만 하면 됩니다. 그런 다음 뒤로 버튼을 클릭하고 기다려야 하며, 그냥... 포기합니다.

해리: 네, 이해가 됩니다. 슈퍼마켓에 갔을 때 사람들로 가득 차 있다는 것을 알면 최소한의 조치를 취하게 될 것입니다. 당신은 거기에 많은 돈을 쓰지 않을 것입니다. 그것은 안팎으로 "오, 우유가 필요합니다."와 같습니다. 반면에 좋은 경험이라면 "오, 글쎄, 내가 여기에 있는 동안 나는 만약… 나는 여전히 웹에 30년이 지나고 있다고 생각합니다. 웹을 위해 구축하는 사람들조차도 그것이 무형이기 때문에 고군분투하고 있습니다. 그들은 실제 상점에서 당신을 짜증나게 하는 것이 온라인에서 당신을 짜증나게 할 것이라고 정말로 생각하기 위해 고군분투합니다. 그리고 그것은 그렇습니다. 그리고 통계에 따르면 그렇습니다.

Drew: 아주 초기에는 90년대 후반을 생각하고 있습니다. 여기서 제 나이를 보여주고 있습니다. 우리가 웹사이트를 구축할 때 우리는 성능에 대해 많이 생각했지만 사람들과의 연결이라는 관점에서 성능을 생각했습니다. 사용이 너무 느렸습니다. 우리는 전화 접속, 모뎀, 전화선을 통한 28K, 56K 모뎀에 대해 이야기하고 있습니다. 이미지 스타일을 지정하는 한 지점에서는 이미지의 다른 모든 줄이 이를 제공하기 위해 단색으로 비어 있는 경향이 있었습니다… 베네치안 블라인드를 통해 이미지를 보는 것처럼 상상할 수 있습니다. 압축에 도움이 되었기 때문에 그렇게 했습니다. 다른 모든 라인 압축 알고리즘은-

해리: 한 포인터로 축소.

드류: 네. 따라서 이미지 크기를 크게 줄이면서 여전히 다음을 얻을 수 있습니다. 그리고 그것은 디자인 요소가 되었습니다. 모두가 하고 있었다. 제 생각에는 아마도 Jeffrey Zeldman이 그 접근 방식을 개척한 최초의 사람 중 한 명일 것입니다. 그러나 우리가 거기에서 생각한 것은 주로 우리가 전선을 얼마나 빨리 끝낼 수 있느냐 하는 것이었습니다. 우리가 생각하지 않았기 때문에 사용자 경험을 위한 것이 아닙니다. 본질적으로 사람들이 우리 사이트를 떠나는 것을 원하지 않았기 때문에 그것이 사용자 경험이었다고 생각합니다. 그러나 우리는 최적화가 정말 빠르도록 하는 것이 아니라 정말 느린 것을 피하려고 노력하는 것에 대해 생각하고 있었습니다.

해리: 네, 네.

Drew: 그리고 ADSL 라인과 같은 속도가 더 보편화되면서 우리는 그런 용어에 대한 생각을 멈추고 전혀 생각하지 않기 시작했다고 생각합니다. 그리고 이제 우리는 모바일 장치를 사용하고 있으며 연결이 제한되고 CPU가 느려지고 다시 생각해야 하는 상황에 처해 있습니다. 하지만 이번에는 이점을 얻는 측면에서 말입니다. 사물의 사용자 경험 측면뿐만 아니라 비용 및 수익 창출 능력 측면에서 실질적인 비즈니스 이점을 가질 수 있습니다. 안 그래?

해리: 네, 엄청나게요. 어떻게 말해야 할지 모르겠다는 뜻입니다. 여기에서 제 자신을 쏘는 것이 아니라 제가 시도하고 고객에게 강조하는 한 가지는 사이트 속도가 경쟁 우위를 제공하지만 경쟁 우위를 제공할 수 있는 단 하나의 요소라는 것입니다. 아무도 사고 싶어하지 않는 제품이 있다면 사이트 속도는 중요하지 않습니다. 마찬가지로 누군가가 진정으로 세계에서 가장 빠른 웹사이트를 원한다면 이미지를 삭제하고 CSS를 삭제하고 JavaScript를 삭제한 다음 얼마나 많은 제품을 말하는지 확인해야 합니다. 그러나 연구에 따르면 수백만 달러에 달하는 빠른 속도의 엄청난 이점이 있습니다. 나는 우리가 말하는 동안 클라이언트와 함께 일하고 있습니다. 우리는 그들이 주어진 페이지를 1초 더 빨리 렌더링할 수 있거나 오히려 가장 큰 페인트 콘텐츠가 1초 더 빠르다면 연간 180만 달러의 가치가 있다는 것을 알아냈습니다.

드류: 그렇게 하면 거의 수수료를 지불할 것입니다.

해리: 이봐! 예, 거의. 나는 그들에게 이렇게 말했습니다. 당신은 짝을 깨고있을 것입니다." 나는 원한다. 하지만 예, 클라이언트 대면 측면은 ... 죄송합니다. E-Com 사이트가 있는 경우 고객 대면 측면에서 더 많은 돈을 쓸 것입니다. 당신이 발행인이라면 그들은 더 많은 기사를 읽거나 더 많은 분량의 콘텐츠를 보게 될 것입니다. 당신이 하는 모든 것은 당신이 측정하는 KPI입니다. Smashing 사이트에 있을 수도 있고 반송되지 않을 수도 있습니다. 우리가 정말 쉽고 빠르게 만들었기 때문에 실제로 몇 가지 더 많은 기사를 클릭했습니다. 그리고 더 빠른 사이트는 더 저렴하게 운영할 수 있습니다. 캐싱 전략이 정렬되어 있으면 사람들이 서버에서 멀어지는 것을 막을 수 있습니다. 자산을 최적화하면 서버에서 가져와야 하는 모든 항목의 가중치가 훨씬 낮아집니다. 실행하는 것이 훨씬 저렴합니다.

Harry: 문제는 거기에 가는 데 비용이 든다는 것입니다. Scott Jehl이 아마도 가장 많이 말한 것 중 하나라고 생각합니다. 그리고 나는 그에게 먼저 들어서 그가 생각해 낸 것이라고 생각하지만 "빠른 웹 사이트를 만드는 것은 쉽지만 웹 사이트를 만드는 것은 어렵다"라는 말이 있습니다. 빠른". 그리고 그것은 아주 간단합니다. 웹 성능이 해야 할 일 목록에서 밀려나는 이유는 고객에게 "내가 귀하의 사이트를 1초 더 빠르게 만들면 연간 180만 달러를 추가로 벌게 될 것입니다"라고 말할 수 있기 때문입니다. "체크아웃에 Apple Pay를 추가했다면 추가로 500만 달러를 벌게 될 것입니다." 따라서 웹 성능이 전부가 아니며 결정적인 요소도 아닙니다. 특히 E-Com 온라인의 경우 훨씬 더 큰 전략의 일부입니다. 그러나 증거는 내가 내 소매 고객인 E-Com 고객과 직접 측정했다는 것입니다. 그 경우가 바로 거기에 있습니다. 당신이 절대적으로 옳습니다. 그것은 경쟁 우위이며 더 많은 돈을 벌 것입니다.

Drew: 다시 예전으로 돌아가고 싶지만 Steve Souders와 같은 사람들은 웹 성능에 대해 글을 쓰고 말하기 시작한 최초의 사람들이었습니다. 그리고 Steve와 같은 사람들은 기본적으로 "모든 이점이 브라우저에 있는 백엔드 인프라는 잊어버리세요. 프론트엔드에서 모든 것이 느려지는 곳입니다."라고 말했습니다. 15년이 지난 지금도 그럴까요?

해리: 네, 네. 그는 그 당시와 지금 사이에 테스트를 다시 실행했는데 그 격차가 실제로 넓어졌기 때문에 실제로는 유선보다 비용이 더 많이 듭니다. 그러나 이에 대한 반대가 있습니다. 백엔드 성능이 정말 좋지 않은 경우, 천천히 게이트를 빠져나가면 프론트 엔드에서 뒤로 물러날 수 있는 것이 너무 많습니다. 나는 현재 클라이언트를 가지고 있으며 첫 번째 바이트까지의 시간은 1.5초입니다. 따라서 1.5초보다 빠르게 렌더링할 수 없으므로 제한이 됩니다. 우리는 여전히 프론트 엔드에서 시간을 되돌릴 수 있지만 첫 번째 바이트에 대한 시간이 정말 정말 나쁘다면 백엔드 속도가 느려지고 프론트 엔드 성능 노력으로 얻을 수 있는 속도에는 한계가 있습니다. 하지만 절대적으로.

Harry: 그러나 그것은 변화하고 있기 때문에… 우리는 클라이언트에게 더 많은 것을 밀고 있습니다. "귀하의 서버는 지금만큼 빠르지만 그 후에는 많은 물음표가 표시됩니다."의 경우였습니다. "모든 사용자는 WiFi에서 실행됩니다. 그들은 모두 우리 사무실에서 일하기 때문에 데스크탑 컴퓨터를 가지고 있습니다.” 글쎄요, 아니요, 지금 그들은 모두 집에서 일하고 있습니다. 당신은 선택할 수 없습니다. 그래서 모든 물음표는 속도 저하가 발생하는 곳이며 실제로 제어할 수 없는 곳입니다. 그 후, 이제 우리는 클라이언트에 더 많은 것을 두는 경향이 있습니다. 즉, 클라이언트의 전체 실행 시간입니다. 어쨌든 모든 응용 프로그램 논리를 서버에서 이동했으므로 첫 번째 바이트에 대한 시간은 매우, 매우 최소화되어야 합니다. 그것은 CDM에서 내 서버로 일부 번들을 보내는 경우여야 합니다. 하지만 당신은 당신 자신의 서버에 사양을 지정할 수 있는 것에서 누군가가 당신의 웹사이트를 보려고 하는 동일한 시스템에서 Netflix를 실행하지 않기를 바라는 것으로 바뀌었습니다. .

Drew: 그것은 우리가 사이트를 디자인하는 방식에 대한 정말 좋은 점입니다. 그리고 제 생각에 전통적인 모범 사례는 항상 모든 종류의 브라우저, 모든 종류의 연결 속도, 모든 종류의 화면 크기를 위해 노력하고 수용해야 한다는 것이었습니다. 사용자가 무엇을 기대하는지 모릅니다. 그리고 당신이 말했듯이 사람들이 "아, 우리는 모든 사용자가 업무용 데스크탑 컴퓨터에 있다는 것을 알고 있습니다. 그들은 이 브라우저를 실행하고 있으며 최신 버전이며 LAN에 유선으로 연결되어 있습니다"라고 말하는 시나리오가 있습니다. 그러나 일이 일어납니다. 웹 앱을 사용하는 것의 가장 큰 이점 중 하나는 인력을 갑자기 집으로 돌려보내고 계속 일할 수 있다는 것과 같은 일을 할 수 있다는 것입니다. IE11이 설치되어 있거나 무엇이든 간에, 작업 품질이 실제로 존재하는지 여부는 웹이 진정으로 액세스 가능한 매체가 될 수 있는 잠재력을 실현한다는 것을 의미합니다.

Drew: 당신이 말했듯이, 점점 더 많은 것을 브라우저로 옮기는 경향이 있습니다. 물론, 브라우저가 느리다면, 거기에서 속도가 느려집니다. "이것이 좋은 추세인가? 우리가 이것을해야합니까?” 내가 특히 생각하는 한 사이트가 있는데 거의 100% 서버 렌더링된 것으로 나타났습니다. JavaScript가 거의 없으며 매우 빠릅니다. 갈 때마다 "아 이거 빠르네 누가 썼어?" 라는 생각이 듭니다. 그러면서 “아, 나였구나”라는 걸 깨닫는다.

Harry: 그것은 당신이 localhost에 있기 때문입니다. 그것이 빠르게 느껴지는 것은 당연합니다. 당신의 개발 사이트입니다.

Drew: 그런 다음, 제 하루 일과는 단일 페이지 애플리케이션을 구축하고 서버의 병목 현상 때문에 서버에서 다른 곳으로 이동합니다. 브라우저에 있는 것이 더 성능이 좋다고 말할 수 있습니까? 아니면 서버에서 더 성능이 좋습니까? 케이스 바이 케이스로 측정하고 취하는 경우입니까?

Harry: 내 생각에 당신은 당신의 맥락을 아주, 아주, 아주 잘 알고 있어야 하고… 진심으로 제 생각에 오류는… 사람들이 “오, 내 블로그는 누군가의 브라우저에서 렌더링될 자격이 있는 나르시시즘”이라고 생각합니다. 이탈률이 89%인 내 블로그는 브라우저에서 자체 런타임이 필요합니다. 빠른 탐색이 필요하기 때문에 기본적으로 데이터의 차이를 가져오고 싶을 뿐입니다." 어쨌든 다음 기사를 클릭하는 사람은 아무도 없습니다. 런타임을 파이프로 밀어넣지 마세요. 따라서 상황을 잘 알고 있어야 합니다.

Harry: 그리고 저는… Jeremy Keith가 이 말을 듣고 있으면 아마 저를 공격할 것입니다. 하지만 웹사이트와 웹 앱 간에는 차이가 있으며 그 정의는 매우, 매우 어둡다. 그러나 읽기 및 쓰기가 많은 응용 프로그램이 있는 경우 데이터를 입력하고 데이터를 조작하는 등의 작업을 수행해야 합니다. 기본적으로 내 사이트는 웹 응용 프로그램이 아니라 웹 사이트이며 읽기 전용이므로 웹 사이트 캠프에 확고하게 넣을 것입니다. 제 회계 소프트웨어와 같은 것은 웹 앱입니다. 웹 앱이라고 하고 부팅 시간 비용을 조금 들 준비가 되어 있습니다. 왜냐하면 제가 거기에 20분, 1시간 동안 있을 것이라는 것을 알고 있기 때문입니다. 따라서 약간의 맥락이 필요합니다. 다시 말하지만 나르시시즘은 약간 거칠지만 "이 신문을 클라이언트 측 응용 프로그램으로 만들 필요가 있습니까?"가 필요합니다. 아니, 당신은하지 않습니다. 아니, 당신은하지 않습니다. 사람들은 광고 차단기를 사용하고 있습니다. 사람들은 어쨌든 통근 신문 사이트를 좋아하지 않습니다. 그들은 아마도 페이스북에서 기사를 읽고 그것에 대해 호언장담하지 않을 것입니다. 클라이언트 렌더링 응용 프로그램과 같은 것을 구축하지 마십시오. 적합하지 않습니다.

Harry: 따라서 고객에게 더 많이 다가가는 것이 도움이 되는 지점이 분명히 있다고 생각합니다. 그때가 바로 고객 이탈에 대한 민감도가 낮아질 때입니다. 예를 들어 어떤 유형의 통신이든 저는 잠시 동안 다음과 같은 사이트에 대한 감사를 수행하고 있습니다. E-Com 사이트라고 생각하지만 100% 클라이언트에 있습니다. JavaScript를 비활성화하면 아무것도 표시되지 않고 빈 div id="app"만 표시됩니다. E-Com은... 당신은 모든 문제에 매우 민감합니다. 결제 흐름이 미묘하게 잘못되었습니다. 다른 곳으로 이동했습니다. 너무 느려요, 다른 곳으로 가겠습니다. 누군가가 잠시 동안 해당 앱에 잠을 자고 싶어하는 상황이 없습니다.

해리: 포토샵. 저는 Photoshop을 열고 시작 화면에 45초가 걸릴 것이라는 사실을 알게 되어 매우 기쁩니다. 왜냐하면 저는... 기본적으로 45초는 45분의 가치가 있기 때문입니다. 그리고 정의하기가 너무 어렵습니다. 그래서 저는 고객에게 "제발 이것을 하지 마십시오"라고 설득하는 데 정말 어려움을 겪고 있습니다. 왜냐하면 저는 "귀하의 사용자가 그곳에 얼마나 오래 있을 것 같습니까?"라고 말할 수 없기 때문입니다. 이탈률이 89%인 경우 두 번째 페이지 보기에 최적화되지 않은 경우... 먼저 이탈률을 낮추십시오. 나는 분명히 분열이 있다고 생각하지만 내가 말하고 싶은 것은 대부분의 사람들이 그 선의 잘못된 편에 빠진다는 것입니다. 대부분의 사람들은 거기에 있어서는 안 되는 것들을 클라이언트에 넣습니다. 예를 들어 CNN은 JavaScript 애플리케이션이 완전히 부팅될 때까지 CNN 웹사이트에서 단일 헤드라인을 읽을 수 없습니다. 서버에서 렌더링되는 유일한 것은 머리글과 바닥글이며 사람들이 신경 쓰지 않는 유일한 것입니다.

Harry: 그리고 제 생각에는 단지... 우리가 그 시점에 어떻게 도달했는지 모르겠습니다. 결코 더 나은 선택이 될 수 없습니다. 실제로 쓸모가 없는 페이지를 전달한 다음 "멋져요. 웹 앱이었을 것을 가져오겠습니다. 하지만 브라우저에서 실행한 다음 헤드라인을 요청하겠습니다. , 당신은 시작할 수 있습니다 ... 오, 당신은 가버렸습니다.” 정말 짜증나네요.

Harry: 그리고 그것은 누구의 잘못도 아닙니다. 제 생각에는 이런 종류의 JavaScript 생태계의 초기 단계라고 생각합니다. 주변에 과대 광고가 발생합니다. 또한 이것은 정말 가혹하게 들릴 것입니다. 하지만... 기본적으로 순진한 구현입니다. 물론 Facebook은 React를 발명했으며 무엇이든 잘 작동합니다. 10 중 9는 Facebook 규모에서 일하지 않고, 100 중 95는 아마도 가장 똑똑한 Facebook 엔지니어가 아닐 것입니다. 정말 잔인하고 끔찍한 말처럼 들리지만 얻을 수 있는 것은… 이러한 것들은 기본적으로 빠릅니다. 그것들을 올바르게 만들기 위해서는 이러한 것들을 매우 우아하게 구현해야 합니다.

Harry: 나는 10년 전 Sky에서 내가 속했던 팀의 수석 엔지니어였습니다. 나는 요전에 이것에 대해 그와 이야기하고 있었고 그는 클라이언트 렌더링 앱을 빠르게 만들기 위해 매우 열심히 일해야 했지만 서버 렌더링 앱을 빠르게 만들면 아무 것도 할 필요가 없습니다. 다시 느려지지 않도록 하면 됩니다. 그리고 장미빛 도는 안경, 순진함, 마케팅이 많은 것 같은 느낌이 듭니다. 너무 우울하게 들립니다. 여기서 사람들을 정말로 잃기 시작하기 전에 계속 진행해야 합니다.

Drew: 산업으로서 때때로 사용자 경험보다 개발자 경험에 더 중점을 두는 경향이 있다고 생각하십니까?

Harry: 전체적으로는 아니지만 예상했던 위치에서 문제가 발생한다고 생각합니다. 그 격차를 보면… 당신이 이것을 보았는지 모르겠지만 나는 당신이 가지고 있다고 가정 할 것입니다. 당신은 맥박, 어떤 프레임 워크에 대한 HTTP 아카이브의 데이터 사이의 격차와 JavaScript 라이브러리는 JavaScript 조사 상태와 비교하여 야생에서 사용됩니다. JavaScript 조사 상태를 따르면 "오 예, 개발자의 75%가 React를 사용하고 있습니다."라고 표시되는 반면 사이트의 5% 미만은 React를 사용합니다. 그래서 제 생각에는 전체적으로 문제가 있다고 생각하지 않습니다. 하지만 예상하는 영역에서 개발자 경험과 같은 한 프레임워크에 대한 충성도는 아마도 사용자보다 먼저 전파될 것입니다. 개발자 경험을 간과해서는 안 된다고 생각합니다. 모든 일에는 유지 관리 비용이 따릅니다. 너의 차. "글쎄, 우리가 이 키, 그 기능을 정비사에게 숨기면 그 정비사가 그것을 고치는 데 훨씬 더 오래 걸릴 것이므로 우리는 그런 일을 하지 않는다"는 결정이 설계되었을 때 있었습니다. 따라서 인체 공학과 사용성의 균형이 필요하고 그것이 중요하다고 생각합니다. 개발자 경험에 주로 초점을 맞추는 것은 나에게 당혹스러울 뿐입니다. 당신을 위해 최적화하지 말고, 당신의 고객을 위해 최적화하세요, 당신의 고객은 당신에게 비용을 지불합니다. 그 반대는 아닙니다.

Drew: 따라서 온라인 에코 챔버는 모든 사람들이 "오 이것을 사용해야 하고, 그렇게 해야 합니다"라고 말하는 것을 볼 때 현실을 정확히 대표하지 않습니다. 그러면 실제로는 아주 적은 비율의 사람들입니다.

Harry: 맞습니다. 그리고 그것은 좋은 일입니다. 안심이 됩니다. 반향실… 그런 종류의 단일 재배를 하는 것은 건강에 좋지 않습니다. 그러나 또한 저는… 많은 개발자들과 제 자신의 작업에서 그것을 보았습니다. 컨설턴트로서 저는 많은 다른 회사와 함께 일하고 있습니다. 많은 사람들이 워드프레스에서 놀라운 일을 하고 있습니다. 그리고 WordPress는 웹의 24%를 차지합니다. 그리고 백엔드에서 WordPress나 PHP와 같은 작업을 하는 개발자가 커스텀 코드가 무엇이든 간에 "오, 모든 사람들이 React를 사용하고 있고 우리는 그렇지 않습니다. "하지만 실제로는 그렇지 않습니다. 모두가 React에 대해 이야기하고 있지만 여전히 흐름을 따르고 있고 여전히 대다수와 함께하고 있습니다. 침묵하는 다수를 찾는 것은 꽤 안심이 됩니다.

Drew: 정적 사이트 생성기를 사용한 다음 완전히 CDN에서 사이트를 호스팅하는 경향, 일종의 JAMstack 접근 방식, 제 생각에는 소프트웨어 유형 사이트가 아닌 이러한 종류의 게시 유형 사이트에 대해 이야기할 때 정말 건전한 경향이라고 생각합니다. , 생각하시겠습니까?

해리: 정말 좋아해요. 우리가 SSG를 "플랩 파일"이라고 불렀을 때를 기억합니까?

드류: 네.

Harry: 그래서 저는 Jekyll이 플랩 파일 웹사이트라고 불렸을 때 Jekyll에 CSS Wizardry를 구축했습니다. 그러나 이제 우리는 발전기에 서비스를 제공합니다. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

드류: 네.

Harry: … diminishing returns, that's exactly it. 예 바로 그 거예요.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? 이거 정말 좋다. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: 그는 존경을 받았지만 그는 소년 중 하나였습니다. 우리 모두는 그를 정말 좋아했습니다. 그러나 그는 모든 차원에서 거대했습니다. 키는 6피트가 훨씬 넘지만 덩치만 큰 녀석입니다. 큰, 큰, 큰, 큰 사람. 그리고 그는 우리에게 "당신이 출입구를 디자인한다면 평범한 사람을 위해 디자인하시겠습니까?"라고 말했습니다. 그리고 15세의 두뇌는 "글쎄요, 모든 사람이 대략 5'9이면 예"라고 말했습니다. 그는 "글쎄, 즉시, 해리는 그 문을 사용할 수 없습니다." 당신은 평범한 사람을 위해 디자인하는 것이 아니라 대부분의 사람들에게 유용하기를 원하기 때문에 말단을 위해 디자인합니다. 당신이 평범한 사람을 위한 의자를 디자인했다면, Mr. Brocklesby는 거기에 맞지 않을 것입니다. 그래서 그는 나에게 정말, 정말 나이부터 디자인을 배웠습니다.

Harry: 그리고 웹 성능에서 그게 정말 흥미로워지는 부분은... 사다리를 상상하고 봇 옆에서 사다리를 집어 든다면... 좋아요. 방금 제 비유가 가능하다는 것을 깨달았습니다. 나는 그것을 고수하고 당신은 웃을 수 있습니다. 나중에 나. 사다리를 상상하고 사다리를 맨 아래 가로대로 들어 올립니다. 그리고 그것은 당신의 최악의 경험입니다. 사다리에서 아래쪽 가로대를 선택하여 들어 올립니다. 밀물이 모든 배를 띄우듯 사닥다리 전체가 그와 함께 옵니다. 은유가 작동하지 않는 이유는 사다리를 맨 위 가로대 위로 집어 올리면 모두 들어 올려지는 사다리입니다. 그리고 은유는 내가 그것을 밧줄 사다리로 바꿔도 작동하지 않습니다. 왜냐하면 밧줄 사다리가 맨 아래 가로대를 들어 올려도 아무 일도 일어나지 않기 때문입니다. 하지만... 제 요점은, 90번째 백분위수에 대한 경험을 향상시킬 수 있다면 당신의 10번째 백분위수를 위해 그것을 얻으십시오, 맞습니까?

Harry: 그래서 제가 고객에게 "오, 우리 사용자 대부분은 iPhone에서 4G를 사용하고 있습니다."와 같은 말을 할 것이라고 말하는 이유입니다. 아니요, 대부분의 사용자는 iPhone입니다.” 좋습니다... 즉, 일반 사용자는 더 나은 경험을 할 수 있지만 아직 50번째 백분위수에 들지 않은 사용자는 더 뒤처지게 됩니다. 따라서 기대치를 매우 낮게 설정하여 자신에 대한 기준을 상당히 높게 설정하십시오.

Harry: 죄송합니다, 저는 짧은 질문에 정말 긴 대답을 하는 나쁜 버릇이 있습니다. 하지만 그것은 환상적인 질문이었고, 끝내려고 하면 100% 확실히 당신이 그 롱테일을 보고 싶어한다는 것에 동의합니다. 당신은 그것을 보고 싶어합니다... 당신의 80번째 백분위수는 모든 경험을 취한다면 사이트에서 중앙값을 보고 중앙값을 개선합니다. 즉, 이미 상당히 만족한 사람들을 위해 더 좋게 만들었습니다. 50%의 사람들이 효과적으로 무시당하는 것은 올바른 접근 방식이 아닙니다. 그리고 예, 항상 Mr Brocklesby가 저에게 "보통 사람을 위해 디자인하지 마십시오. 그러면 Harry는 문을 사용할 수 없습니다."라고 말했습니다. 아, 누가 들어도 키가 193cm라서 꽤 마른 편이다.

Drew: 그리고 그 모든 팔과 다리.

해리: 네. 여기 또 하나의 좋은 점이 있습니다. 제 여자친구는 최근 iOS에서 접근성 설정을 발견했습니다... 그래서 다들 휴대폰을 무음으로 하고 있죠? 실제로 전화가 울리는 사람은 아무도 없으며 모두 무음으로 설정되어 있습니다. 그녀는 "아, 알다시피, 당신은 당신이 메시지를받을 때 플래시가 깜박이도록 설정할 수 있습니다. 그리고 휴대폰 뒷면을 두 번 두드리면 스크린샷이 찍힙니다.” 그리고 이것들은 접근성 설정이며 95번째 백분위수를 위해 설계되었습니다. 그러나 그녀는 "오, 이것은 정말 유용합니다"라고 말합니다.

Harry: OXO Good Grips도 마찬가지입니다. OXO 굿그립스, 주방용품. 나는 부엌에 그것들을 잔뜩 가지고 있다. 창업자의 아내가 관절염을 앓고 있어 보다 편안한 식기를 만들고 싶어 설계되었습니다. 그는 99번째 백분위수를 위해 설계했으며 대부분의 사람들은 관절염이 없습니다. 그러나 99번째 백분위수를 위해 설계함으로써 다른 사람들은 무심코 "맙소사, 왜 모든 감자 껍질 벗기는 사람이 이렇게 편할 수 없습니까?"라고 생각합니다. 그리고 저는 그것이 정말로, 정말로… 저는 이런 종류의 시나리오에서 이야기하고 싶은 기분 좋은 일화나 일화를 좋아합니다. 그러나 네, 만약 당신이 그들을 위해 최적화한다면… 글쎄요, 밀물은 모든 배를 띄우고 따라서 사람들의 꼬리 끝을 최적화하고 당신은 그보다 더 행복한 많은 고객을 포착하게 될 것입니다.

Drew: OXO Good Grips 수동 손 털기가 있습니까?

해리: 안 해요. 안 그래요?

드류: 자세히 보세요. 정말 좋아요.

Harry: 저는 지난 주에 제 손가락 끝을 잘라낸 OXO Good Grips 만돌린 슬라이서를 가지고 있습니다.

Drew: 네, 저는 그 중 하나에 가까이 가지 않을 것입니다.

해리: 네, 제 어리석은 잘못입니다.

Drew: 롱테일 케이터링에 대한 제 경험의 또 다른 예는 제가 현재 작업하고 있는 프로젝트에서 롱테일이 바로 마지막에 있으며 성능이 가장 느린 사람들이 있다는 것입니다. 그러나 그 고객이 누구인지를 보면 그들이 비즈니스에 가장 가치 있는 고객입니다.

해리: 알았어.

Drew: ... 가장 많은 양의 데이터를 보유한 가장 큰 조직이기 때문입니다.

해리: 맞아.

Drew: 페이지에 표시할 데이터가 너무 많고 해당 사용 사례를 돕기 위해 해당 페이지를 약간 리팩토링해야 하기 때문에 병목 현상이 발생합니다. 그래서 그들은 가장 느린 경험을 하고 있고, 그것에 관해서는 가장 많은 돈을 지불하고 정말 빠른 경험을 가진 모든 사람들보다 훨씬 더 많은 차이를 만들고 있습니다. 왜냐하면 그들은 무료 사용자이기 때문에 적은 양의 데이터와 모든 것이 잘 작동하고 빠릅니다.

Harry: 정말 매력적인 차원이죠, 그렇죠? 사실, 저도 비슷한 경험을 했습니다. 방금 말씀하신 것과 같은 비즈니스 영향은 거의 없었지만 몇 년 전에 고객과 함께 일했는데 사이트 속도가 느리기 때문에 해당 고객의 CEO가 연락을 취했습니다. 천천히, 천천히, 천천히. 정말 좋은 사람이기도 하고, 정말 착할 뿐 아니라 진정한 부자처럼 멘토링을 받고 있습니다. 그리고 그는 최신 iPhone을 가지고 있습니다. 그는 그것을 감당할 수 있습니다. 그는 백만장자이며, 자신의 출신지인 호주와 현재 그가 위치한 에스토니아를 오가며 많은 시간을 보냅니다.

Harry: 그리고 그는 일등석을 타고 있습니다. 물론 그렇습니다. 그러나 그것은 그의 멋지고 빛나는 iPhone 12 Pro Max에서 대부분의 시간을 비행기 Wi-Fi를 통해 사용한다는 것을 의미합니다. 이것은 끔찍합니다. 그리고 그가 사이트를 소유하고 있고 그가 그것을 많이 사용하는 것은 이 정말 놀라운 병치였습니다. 그가 사용하는 사이트입니다. 그리고 그는 그것을 추진하고 있었습니다... 제 말은 쉽게 그들의 가장 부유한 고객은 그들의 CEO였습니다. 그리고 그는 조 퍼블릭보다 더 나쁜 관계에 있는 이 이상한 특권을 가진 위치에 있습니다. 왜냐하면 그가 콴타스 비행기를 타고 목에 샴페인을 붓고 있는 싱가포르 위 어딘가에 있기 때문에 그는 고군분투하고 있습니다. 그리고 그것은 정말 매혹적인 통찰력이었습니다... 오, 당신은 95번째 백분위수를 가지고 있기 때문에 기본적으로 어느 방향으로든 갈 수 있습니다.

Drew: 예, 한 손에 샴페인 한 잔을 들고 사이트 사용을 최적화하기 시작할 때 "어쩌면 우리가 길을 잃기 시작하고 있을지도 몰라"라고 생각합니다.

해리: 네, 맞습니다.

Drew: 우리는 성과 측정에 대해 조금 이야기했습니다. 성과 작업에 대한 제 경험에 따르면 A를 모두 측정하는 것이 정말 중요합니다. 그러면 문제가 있는 곳이 B가 아니라 어디에 있는지 식별할 수 있으므로 실제로 문제를 해결하기 시작할 때 당신은 다른 것을 만들고 있고 얼마나 많은 차이를 만들고 있는지. 사이트의 성능을 측정하려면 어떻게 해야 합니까? 어떤 도구를 사용할 수 있으며 어디에서 시작해야 합니까?

해리: 이런, 또 다른 좋은 질문입니다. 따라서 사이트 속도를 수정하는 데 얼마나 많은 시간, 리소스, 성향이 있는지에 따라 다양한 답변이 있습니다. 그래서 내가 클라이언트와 함께 시도하고 수행할 작업은... 특정 기성품 측정항목이 정말 좋습니다. 로드 시간, 더 이상 신경 쓰지 마십시오. 그것은 매우, 매우, 아주… 제 말은, 로드 시간이 120초라면 좋은 프록시입니다. 저는 당신이 매우 빠른 웹사이트를 가지고 있지 않다고 추측할 것입니다. 그러나 그것은 너무 불분명하고 실제로 고객을 대하는 것이 아닙니다. 저는 실제로 vitals가 사용자 경험을 측정하지만 기술적 입력을 기반으로 하기 때문에 올바른 방향으로 가는 정말 좋은 단계라고 생각합니다. 가장 큰 콘텐츠가 포함된 페인트는 시각적으로 정말 좋은 것이지만 기술적인 요소는 중요한 경로를 차단하고 영웅 이미지가 빨리 도착하도록 하고 웹 글꼴 전략이 적절한지 확인합니다. 이러한 측정항목에는 기술적인 저전류가 있습니다. 정말 좋은 제품들입니다.

Harry: 하지만 클라이언트에게 시간이 있는 경우 일반적으로 시간이 됩니다. 데이터를 캡처하고 싶지만 실제로 데이터를 캡처하는 데 시간이 필요하기 때문입니다. 그래서 제가 고객과 함께 하려고 하는 것은 “이봐, 예약이 꽉 차서 앞으로 3개월 동안 함께 일할 수 없어. 따라서 우리가 할 수 있는 일은 Speedcurve의 무료 평가판을 정말 빠르게 설정하고 몇 가지 사용자 지정 측정항목을 설정하는 것입니다. 기사 렌더링? 기사의 리드 이미지가 얼마나 빨리 렌더링되었습니까?” 전자 상거래 클라이언트의 경우 수동적으로 렌더링 시작과 같은 항목을 측정하고 있기 때문에 측정하고 싶습니다. 성능 모니터링 소프트웨어를 사용하기 시작하자마자 실제 성능 메트릭을 무료로 캡처하게 됩니다. 따라서 첫 번째 Contentful Paint, Largest Contentful 등입니다. 제가 정말로 캡처하고 싶은 것은 비즈니스로서 그들에게 중요한 것입니다.

Harry: 그래서, 우리가 상관 관계를 맺을 수 있는 순간에 E-Com 클라이언트와 함께 일하고 있습니다… 렌더 시작이 빠를수록 장바구니에 추가될 확률은 얼마입니까? 제품을 더 빨리 보여줄 수 있다면 구매 가능성이 더 높아집니다. 그리고 이것은 설정하는 데 많은 노력이 필요합니다. 이것은 진정한 야망을 가진 고객을 위한 일종의 확장 목표입니다. 그러나 실제로 측정하고 싶은 모든 것입니다. 왜냐하면 제가 말했듯이 당신은 가장 큰 것을 측정하고 싶지 않기 때문입니다. Contentful Paint는 수익을 측정하고 싶고 Large Contentful Paint의 영향을 받았습니까? 따라서 확장 목표, 궁극적인 것은 해당 비즈니스의 KPI로 볼 수 있는 모든 것입니다. 신문에서 누군가가 기사를 얼마나 아래로 스크롤했는지 알 수 있습니다. 그리고 그것은 어떤 식으로든 첫 번째 입력 지연과 상관 관계가 있습니까? CLS가 낮으면 사람들이 더 많은 기사를 읽었습니까? 그러나 우리가 사용자 지정, 사용자 지정 메트릭을 시작하기 전에 솔직히 web vitals가 시작하기에 정말 좋은 장소이며 상당히 정규화되었다고 생각합니다. 그것은… 가 됩니다. 나는 그 단어가 무엇인지 모릅니다. 업계의 모든 사람들이 이제 이 공평한 경쟁의 장에서 성과에 대해 논의할 수 있는 가장 낮은 공통 분모라고 생각합니다.

Harry: 내가 가지고 있고 실제로 Vitals 팀과의 회의를 설정해야 하는 한 가지 문제는 Lighthouse도 훌륭하다고 생각하지만 CLS는 Web Vitals의 33%입니다. LCP, FID, CLS가 있습니다. CLS는 활력소의 33%입니다. Vitals는 일반적으로 마케팅 팀, 분석 부서 앞에서 진행되는 것입니다. 검색 콘솔에 표시되기 때문에 검색 결과 페이지의 컨텍스트에서 언급되는 반면, Vitals는 중요하므로 33%, vitals 중 CLS는 Lighthouse 점수의 5%에 불과합니다. 따라서 Lighthouse를 기반으로 구축하는 개발자를 얻게 될 것입니다. Lighthouse는 도구에 통합될 수 있고 실험실 측정 기준이기 때문입니다. Vitals는 현장 데이터이고 럼주입니다.

Harry: 마케팅 팀이 "CLS는 정말 나쁘다"고 말하고 개발자는 "DevTools에서 제공하는 Lighthouse 점수의 5%입니다. 점수의 5%입니다. Lighthouse CLI가 CircleCI에서 우리에게 제공하는 것” 또는 귀하가 사용하는 모든 것, 그러나 마케팅 팀은 관심의 33%를 중요하게 생각합니다. 그래서 문제는 Lighthouse가 매우 가치 있다고 생각하기 때문에 약간의 연결이 끊긴 것입니다. 그러나 어떻게 그들이 얼마나 상당한 차이를 조화시키는지 모르겠습니다. CLS가 점수의 33%라는 점에서... 글쎄요, 당신이 점수를 매길 수 없기 때문입니다. 실제로는 없고 Lighthouse는 5%에 불과하며 이 논의를 원활하게 만들기 전에 여전히 수정이 필요한 부분입니다.

해리: 하지만 다시, 짧은 질문에 대한 긴 대답입니다. 바이탈 정말 좋습니다. LCP는 CLS와 마찬가지로 기술 솔루션으로 요약할 수 있는 우수한 사용자 경험 메트릭입니다. 그래서 정말 좋은 출발점이라고 생각합니다. 그 외에도 맞춤 측정항목입니다. 내가 시도하고 내 고객에게 도달하게 하는 지점은 사이트가 얼마나 빠른지 정말 신경 쓰지 않고 어제보다 더 많은 돈을 버는 데 관심이 있습니다. 그렇다면 빠르게 실행되고 있기 때문입니까? 덜 만들었다면 속도가 느려졌기 때문일까요? 나는 그들이 신비한 2초 LCP를 쫓는 것을 원하지 않고 최적의 LCP를 쫓기를 원합니다. 그리고 그것이 실제로 당신이 생각하는 것보다 느린 것으로 판명된다면, 무엇이든 괜찮습니다.

Drew: 따라서... Speedcurve와 같은 도구에 지출할 예산이 없는 웹 개발자의 경우 브라우저 내에서 Lighthouse와 같은 도구를 실행하여 적절한 측정을 얻을 수 있습니다. 해당 수준에 유용한 분석?

Harry: 더 유용하게 사용할 수 있습니다. 분석은 수년 동안 기본적인 성능 정보를 캡처했습니다. 그리고 그것은 DNS 시간, TCP 및 TLS, 첫 번째 바이트까지의 시간, 프록시인 페이지 다운로드 시간이 될 것입니다. 글쎄요, 그냥 페이지 다운로드 시간과 로드 시간입니다. 상당히 투박한 메트릭입니다. 그러나 그것은 좋은 출발점이며 일반적으로 내가 클라이언트와 함께 시작하는 모든 프로젝트에 New Relic이나 Speedcurve 등이 없는 경우에는 "당신의 분석을 살펴보겠습니다"라고 말할 것입니다. 왜냐하면 최소한 거기에서 상황을 대리하십시오. 그리고 Speedcurve나 New Relic, Dynatrace 같은 것들만큼 좋은 것은 절대 없을 것입니다. 사용자 지정 메트릭을 분석에 정말, 정말, 정말 쉽게 보낼 수 있습니다. 듣고 있는 사람이 보낼 수 있기를 원하는 경우… 내 사이트를 예로 들 수 있습니다. "내 기사 중 하나의 제목을 얼마나 빨리 읽을 수 있습니까? 정보 페이지 이미지가 렌더링된 시점은 무엇입니까? 어떤 시점에서 저를 고용하도록 촉구하는 행동 촉구가 있었습니까? 얼마나 빨리 화면에 렌더링됩니까?” 이 데이터를 캡처하는 것은 정말 간단하고 분석에 보내는 것만큼 간단합니다. 따라서 누군가가 내 사이트의 소스를 보고 닫는 본문 태그까지 아래로 스크롤하여 분석 스니펫을 찾으면 사용자 지정 데이터를 캡처하여 분석에 보내는 것이 얼마나 쉬운지 알 수 있습니다. 그리고 분석 UI에서는 아무 것도 할 필요가 없습니다. 일반적으로 사용자 정의 보고서를 설정하고 데이터를 마이닝하여 표시 가능하게 만들어야 합니다. 이들은 Google Analytics의 일등 시민입니다. 따라서 사용자 지정 분석을 캡처하기 시작하는 순간 대시보드의 전체 섹션이 이에 전용됩니다. GA 자체에는 설정이나 무거운 작업이 없으므로 매우 간단합니다. 고객이 실제 예산을 사용하고 있거나 고객에게 맞춤형 모니터링의 힘을 보여주고 싶을 때 "오 예, 약속합니다. 정말 좋습니다. Speedcurve에 24,000,000만 있으면 될까요?” "이봐, 이건 기초적인 거야. 여기에서 가능성을 살펴보겠습니다. 이제 Speedcurve와 같은 제품으로 업그레이드하도록 설득할 수 있습니다.”

Drew: 나는 어떤 것이 얼마나 빨라야 하는지, 또는 변화가 어떤 영향을 미쳐야 하는지에 대한 내 직감이 틀릴 수 있다는 것을 종종 발견했습니다. 나는 변화를 일으키고 일을 더 빠르게 만들고 있다고 생각하고 그것을 측정하고 실제로 일을 더 느리게 만들었습니다. 저만 web perf에서 쓰레기입니까?

해리: 전혀. 이것에 대한 정말 적절한 예가 있습니다. 사전 로드… 사전 로드에 대해 들어본 적이 없는 사람을 위한 빠른 소개, 웹에서 특정 자산을 로드하는 것은 본질적으로 매우 느리고 여기에서 두 가지 주요 후보는 CSS 및 웹 글꼴의 배경 이미지입니다. HTML을 다운로드하고 CSS를 다운로드하면 CSS에서 "아, 홈페이지의 이 div에는 이 배경 이미지가 필요합니다."라고 말합니다. 따라서 그 사이에 CSS 시간의 전체 덩어리가 있기 때문에 본질적으로 매우 느립니다. 사전 로드를 사용하면 "이봐, 당신은 아직 그것을 알지 못하지만, 나를 믿으세요. 당신은 이 이미지가 정말로, 정말로, 정말로 곧 필요하게 될 것입니다."라는 헤드 태그의 HTML에 한 줄을 넣을 수 있습니다. 따라서 이 다운로드를 미리 실행하는 HTML에 미리 로드할 수 있습니다. CSS가 배경 이미지를 필요로 할 때쯤이면 "아, 우리는 이미 그것을 얻었습니다. 빠르군요." 그리고 이것은 웹 퍼프 메시아로 선전되고 있습니다. 여기 일이 있습니다. 그리고 약속합니다. 저는 지난 주에 이것을 트윗했고 그 이후로 두 번이나 옳았다는 것이 증명되었습니다. 사람들은 사전 로드와 사전 로드가 제공하는 약속에 대해 듣고 또한 이론적으로 Lighthouse에 의해 매우 강력하게 추진되어 사이트를 더 빠르게 만듭니다. 사람들은 사전 로드의 개념에 너무 집착하여 내가 작동하지 않는다는 것을 증명할 수 있어도 다시 제거하지 않을 것입니다. "아니요, 하지만 Lighthouse가 말했습니다." 이제 이것은 이론이 타당한 것들 중 하나입니다. 웹 글꼴을 기다려야 하는 경우 이전에 다운로드하는 것보다 더 빨리 볼 수 있습니다. 문제는 웹이 실제로 어떻게 작동하는지 생각할 때, 처음 방문하는 페이지, 방문하는 완전히 새로운 도메인에 대해 제한된 양의 대역폭을 갖게 되며 브라우저는 해당 대역폭을 올바르게 사용하는 매우 스마트한 것입니다. HTML을 정말 빠르게 살펴보고 쇼핑 목록을 만듭니다. 가장 중요한 것은 CSS, 그 다음은 jQuery, 다음은… 미리 로드된 HTML을 로드하기 시작하자마자 브라우저에 "아니, 아니, 아니, 이것은 더 이상 쇼핑 목록이 아닙니다. 친구, 이것은 내 것입니다. 가서 이것들을 가져와야 합니다.” 그 유한한 양의 대역폭은 여전히 유한하지만 더 많은 자산에 사용되지 않으므로 모든 것이 약간 느려집니다. 그리고 나는 지난 주에 이것을 두 번 야유해야했고 여전히 사람들은 "예, 그러나 더 빨리 다운로드되기 때문입니다."라고 말합니다. 아니요, 더 빨리 요청되고 있지만 CSS에서 대역폭을 훔치고 있습니다. 말 그대로 웹 글꼴이 CSS에서 대역폭을 훔치는 것을 볼 수 있습니다. 그래서 그것은 당신이 숫자를 따라야 하고, 따라야 하는 것들 중 하나입니다. 이전에 대규모 클라이언트에서 수행한 적이 있습니다. 당신이 이것을 듣고 있다면, 당신은 이 클라이언트에 대해 들어본 적이 있을 것이고 나는 “아니요, 당신의 머리 태그가 잘못된 순서로 되어 있고 이것이 있어야 하고 여기에 있어야 하기 때문에 왜냐하면 이론적으로 그것이 단서가 되기 때문입니다…” 내가 클라이언트에게 있었던 것에서도 나는 내가 스스로를 바보로 만들고 있다는 것을 알았습니다. 브라우저가 작동하는 방식 때문에 더 빨라야 합니다. 그래서 저는 이 변화를 수백만 명의 사람들에게 꾀하고 있습니다. 그리고 그 속도는 더 느려졌습니다. 느려졌다. 그리고 나는 거기에 앉아 "아니요, 하지만 브라우저는 이렇게 작동합니다"라고 분개하며 작동하지 않기 때문에 쓸모가 없습니다. 그리고 우리는 그것을 되돌려 놓았고 나는 "죄송합니다! 아직도 당신에게 청구할 것입니다!” 그래서 당신은 전혀 당신이 아닙니다.

Drew: 이 숫자를 따르십시오.

해리: 네, 맞습니다. "사실 되돌리는 데 시간이 걸리고 더 오래 걸리기 때문에 실제로 더 많은 비용을 청구해야 합니다." 하지만 네, 당신이 절대적으로 옳습니다. 그건 당신이 아닙니다. 그것은 그런 일 중 하나입니다... 훨씬 더 작은 규모로 여러 번 그것을 했고, 여기서 저는 "음, 이것은 이론적으로 작동해야 합니다"라고 말할 것입니다. '티. 현실 세계에서 일어나는 일을 따라가기만 하면 됩니다. 모니터링이 정말 중요한 이유입니다.

Drew: 환경이 변화하고 기술이 발전함에 따라 Google은 작업 속도를 높이는 데 도움이 되는 새로운 기술을 출시합니다. 이러한 변화를 따라잡을 수 있는 좋은 방법이 있습니까? 웹 성능과 관련하여 최신 기술을 유지해야 하는 리소스가 있습니까?

Harry: 전체 "Google 제작"에 대해 신속하게 설명하기 위해... 약간 혀를 내두를 수 있지만 여기에 초점을 맞추겠습니다. 브라우저에 베팅하는 것이 시작될 즈음인 것 같습니다. 예를 들어, AMP와 같은 것들은 기껏해야 솔루션에 대한 사후 파악에 불과합니다. 빠른 사이트 구축을 대체할 수 있는 것은 없으며 AMP와 같은 것을 사용하기 시작하는 순간 이러한 비표준 표준을 고수해야 하며 AMP 팀의 자비가 마음을 바꿉니다. 클라이언트가 AMP 허용 목록에 있는 글꼴 제공업체로부터 글꼴 라이선스를 받는 데 막대한 비용을 지출하게 했고, 어느 시점에서 AMP는 "아, 아니요, 제공한 글꼴을 지금 차단할 것입니다."라고 결정했습니다. 그래서 저는 클라이언트가 AMP와 이 글꼴 제공업체에 막대한 투자를 했고 "음, 우리가 모든 AMP 작업을 취소할까요 아니면 웹 글꼴에 이 매우 큰 숫자를 1년에 낭비할까요?"를 선택해야 했습니다. 그래서 저는 어떤 사람을 매우 조심할 것입니다… 저는 Google 개발자 전문가이지만 어떤 개그 순서도 모릅니다… 저는 비판적일 수 있습니다. 그리고 저는… - AMP와 같은 모든 솔루션에 적합합니다.

Harry: 그리고 잠시 다른 사람을 무시하기 위해 Cloudflare에는 Rocket Loader라는 것이 있습니다. 이것은 AMP와 유사한 노력입니다. "아 CDN에서 이 기능을 켜면 사이트 속도가 빨라집니다."와 같이 설계되었습니다. 그리고 실제로는 처음부터 사이트를 적절하게 구축하기 위한 대체품에 불과합니다. 그래서... 그 측면을 다루기 위해 가능한 한 독립적인 상태를 유지하려고 노력하고 브라우저가 작동하는 방식을 알아야 합니다. 즉, Chrome 단일 문화는 즉시 Google의 무릎으로 돌아가지만 브라우저가 작동하는 방식을 알고 몇 가지 기본적인 이념을 고수한다는 것을 의미합니다. 사이트를 구축할 때 페이지를 보십시오. 그것이 Figma이든 Sketch이든, 어디에 있든 디자인을보고 "글쎄, 그것은 사용자가 먼저보고 싶어하는 것이므로 방해가되지 않습니다. 이 기본 이미지를 게으르게 로드하지 않을 것입니다. 왜냐하면 그것은 어리석은 일이기 때문입니다. 왜 그렇게 합니까?” 따라서 "사용자가 무엇을 1순위로 하고 싶습니까?"에 대해 생각해 보십시오. E-Com 사이트에서는 그 상품 이미지가 아마 동시에 nav일 텐데, 상품평, 상품 Q&A 등이 게으른 로딩을 하고 있다. JavaScript 뒤에 그것을 집어 넣으십시오.

Harry: 어떤 기술을 읽고 있든 상관없이 올바른 작업을 수행할 수 있는 기본적인 작업 방식이 있습니다. 바로 "고객의 우선 순위를 정하는 것"입니다. 더 많은 작업을 하면 더 빨라지므로 방해하지 말고 사람들이 인지하고, 따라갈 수 있도록 더 많은 전술적 작업을 해야 합니다. 다시 Google로 바로 돌아가지만 web.dev 프레임워크에 구애받지 않고 스택에 구애받지 않는 통찰력을 위한 경이적인 리소스임이 증명되고 있습니다... 따라서 vitals에 대해 배우고 싶다면 PWA에 대해 배우고 싶을 것이므로 web.dev는 정말 좋습니다.

Harry: 실제로 성능 중심 출판물은 거의 없습니다. Calibre의 이메일은 격주로 제공되는 성능 이메일이 정말 경이롭다고 생각합니다. 정말 좋은 요약입니다. 일반적으로 웹 플랫폼을 주시하십시오. 따라서 Performance Working Group이 있으며 GitHub 제안에 대한 많은 내용을 가지고 있습니다. 다시 Google로 돌아가지만 아무도 이 웹사이트와 그 놀라운 웹사이트인 chromestatus.com에 대해 알지 못합니다. Chrome이 무엇을 하고 있는지, 다른 브라우저에서 보내는 신호가 무엇인지 정확히 알려줍니다. 따라서 우선순위 힌트에 대한 작업이 무엇인지 알고 싶다면 모든 관련 버그 추적기에 대한 링크를 얻을 수 있습니다. Chrome 상태는 각각에 대한 이정표를 보여줍니다... "이것은 MAT8에 출시되었습니다. 이것은 '67에 출시되었습니다." 또는 무엇이든 간에, 이는 상당히 기술적인 통찰력을 얻기에 정말 좋은 것입니다.

Harry: 하지만 계속해서 이 얘기를 하고 있어요. 그리고 제가 "노인이 클라우드에게 외치는 소리"처럼 들릴 수도 있다는 걸 압니다. 하지만 기본에 충실합니다. 내가 번 거의 모든 파운드 또는 1달러, 유로는 고객에게 가르쳐 왔습니다. "브라우저가 이미 이 작업을 수행한다는 것을 알잖아요." 또는 "이보다 더 빠를 수 없다는 것을 알고 있습니다."라는 말은 정말 옳게 들립니다. 저는 추가 기술을 판매하는 데 한 푼도 벌지 못했습니다. 내가 버는 모든 돈은 제거하고 빼는 것입니다. 사이트를 더 빠르게 만들기 위해 무언가를 추가하고 있다면 잘못된 방향으로 가고 있는 것입니다.

Harry: 예를 들면... 큰 광고/검색 엔진/브라우저 회사의 이름을 지정하지 않을 것입니다. 이름도 지정하지 않을 것입니다. JavaScript 프레임워크의 이름도 지정하지 않겠지만 현재 적극적으로 해를 끼치는 것을 제거하거나 선택적으로 수많은 웹사이트의 성능에 해를 끼칠 수 있는 것을 제거하는 것에 대해 매우 크고 매우 인기 있는 JavaScript 프레임워크와 논의합니다. 그리고 그들은 "오, 우리는 반복할 것입니다… 여기에서 이 사이트가 느려지고 있습니다.” 그리고 그들의 해결책은 "아, 하지만 이것도 하면 건너뛸 수 있습니다."와 같이 더 추가하는 것이었으며 "아니요, 아니요, 사이트를 더 빠르게 만들기 위해 더 추가하는 것은 잘못된 솔루션임에 틀림없습니다. 더 빠른 사이트를 만들기 위해 더 많은 코드가 필요하다면 확실히 잘못된 방향으로 가고 있다는 것을 알 수 있습니다.”

Harry: 처음에는 빨랐고 추가하는 모든 것이 속도를 느리게 만들기 때문입니다. 그리고 더 빠르게 만들기 위해 더 많은 것을 추가하는 아이디어는... 더 빠른 웹사이트에서 나타날 수 있지만 잘못된 방식입니다. 바닥을 향한 경주입니다. 미안 해요, 정말 화가 나고 있어요, 당신은 내가 한동안 소리 지르지 않았다는 것을 알 수 있습니다. 사이트를 더 빠르게 만들기 위해 기능을 추가하고 있다면 아마도 잘못된 방향으로 가고 있을 것입니다. 추가하는 것보다 제거하여 더 빠르게 만드는 것이 훨씬 더 효과적입니다.

Drew: "CSS Wizardry를 빠르게 만들기 위해 내가 한 모든 작업"이라는 비디오 과정을 만들었습니다.

해리: 네!

Drew: 기존의 온라인 비디오 코스와는 조금 다릅니다. 그렇죠?

해리: 그렇지 . 솔직히 말해서, 그것은 부분적으로... 저는 게으름을 말하고 싶지 않습니다. 그러나 매우 엄격해야 하고 당신을 0에서 영웅으로 데려가야 하는 커리큘럼을 디자인하고 싶지 않았습니다. 왜냐하면 그렇게 하는 데 소요되는 시간 때문에 엄청난 시간이고 내가 가질 수 있을지 몰랐습니다. 그래서 제가 원했던 것은 바로 사용할 수 있는 자료입니다. "여기에 브라우저가 있고 작동 방식이 있습니다"로 시작하지 않도록 화면 캐스트를 통해 직접 이야기하십시오. 따라서 최소한 다음 사항을 알고 있어야 합니다. 웹 성능의 기본이지만 해킹 및 전문가 팁 및 실제 사례입니다.

Harry: 그리고 전체 커리큘럼을 수행할 필요가 없었기 때문에 가격을 대폭 낮출 수 있었습니다. 따라서 0에서 영웅으로 당신을 데려가는 10시간의 큰 코스가 아니라 당신이 적합하다고 생각하는 대로 조금씩 들어가게 됩니다. 그것은 기본적으로 불안정한 것들에 대한 훌륭한 놀이터인 내 사이트를 보는 것입니다. 또는... 그곳에서 실험하는 것은 제가 위험이 매우 낮습니다. 그래서 그냥 비디오 시리즈를 만들었습니다. 녹음하는 것은 정말 재미있었습니다. 내 사이트를 허물고 "이것이 작동하는 방식이며 사용 방법이 있습니다"에 대해 이야기하기만 하면 됩니다.

Drew: 서로 다른 문제를 해결하기 위해 분할된 방식이 정말 훌륭하다고 생각합니다. 이미지 최적화 등에 대해 더 알고 싶다면 "맞아, 내 친구 해리가 이에 대해 뭐라고 말해야 하지?"라고 생각하고 이미지에 대한 비디오를 보고 바로 갑니다. 그런 식으로 액세스할 수 있습니다. 여러 시간 동안 앉아 있을 필요가 없습니다. 원하는 부분으로 이동하여 배워야 할 내용을 배운 다음 나갈 수 있습니다.

Harry: 더 유지하려고 노력한 것 같아요... 엄격한 커리큘럼을 하지 않는 것의 이점은 특정 비디오를 먼저 볼 필요가 없고 소개가 없고 "가서 둘러보고 흥미로운 것을 찾아보세요"라는 것입니다. 이는 LTP 문제로 고통받는 누군가가 "아, 여기 이 폴더로 들어가야 합니다."라고 말하거나 CSS 문제로 고통받고 있는 경우 해당 폴더로 뛰어들 수 있음을 의미합니다. 분명히 나는 통계가 없지만 코스 포기율이 높다고 생각합니다. 순전히 무언가를 놓칠 경우를 대비하여 3시간 동안 소개를 서두르셔야 하기 때문입니다. 이것을 매일 계속하십시오.” 그러면 사람들은 많은 과정을 포기할 수 있습니다. 그래서 제 생각은 그냥 뛰어들었습니다. 앞의 세 시간을 볼 필요가 없습니다. 그냥 가서 원하는 것을 찾을 수 있습니다. 그리고 피드백은 정말, 정말... 사실, 내가 할 일은 아직 존재하지 않지만 전화를 걸고 바로 할 것입니다. 할인 코드 SMASHING15를 사용하는 사람은 15% 할인을 받을 것입니다. 그것의.

Drew: 따라서 코스 자체에서 성능이 최적화된 것과 같습니다. 원하는 부분으로 바로 이동할 수 있고 모든 협상을 할 필요가 없기 때문입니다.

Harry: 네, 의도하지 않았지만 그 점을 인정하겠습니다.

Drew: 그래서 저는 웹 성능에 대한 모든 것을 배웠습니다. 해리, 최근에 무엇을 배웠습니까?

Harry: 기술적인 문제는… 그렇지 않습니다. 저는 "배울 것" 목록에 많은 것이 있으므로 QUIC, H3 종류의 것들에 대해 좀 더 실무 지식을 얻고 싶지만 영국의 첫 번째 잠금 기간 동안 E-Book을 작성하여 E-Book을 만드는 방법은 HTML과 CSS일 뿐이기 때문에 정말 재미있었고 그 방법을 알고 있었기 때문에 정말 재미있었습니다. 나는 그 과정을 위해 아주 기초적인 비디오 편집을 배웠고 그것에 대해 내가 좋아했던 것은 그 어떤 개념적 작업도 아닙니다. 분명히 프로그래밍 언어를 배우려면 개념과 씨름해야 하는 반면 E-Book을 배우는 것은 단지 워크플로이고… 전에 한 번도 해본 적이 없었기 때문에 배우는 것은 흥미로웠지만 직업을 바꿀 필요는 없었습니다. , 그래서 꽤 좋았습니다.

Harry: 그리고 나서, 비기술적인 것들... 저는 많은 자전거를 타고, 많은 자전거에서 넘어집니다... 그리고 저는 지난 3월, 거의 1년 동안 여행을 전혀 하지 않았기 때문에 훨씬 더 많은 일을 하고 있습니다. 사이클링과 더 많은 것에 집중하는 것... 개선. 그래서 저는 전력 출력과 기능적 역치 전력에 대해 많은 연구를 하고 있습니다. 현재 훈련 프로그램을 하고 있습니다. 그래서 끊임없이, 끊임없이 다리를 지치지만 사이클링과 관련된 생리학에 대해 많은 것을 배우고 있습니다. 계속 타는 것 외에는 아무것도 할 계획이 없기 때문에 이유를 모르겠습니다. 정말 매력적입니다. 나는 폐쇄 기간 동안 매우 운이 좋았다고 생각하지만, 나는 그럭저럭 활동을 유지할 수 있었습니다. 많은 사람들이 매일 출근하는 사무실, 다리를 뻗을 수 있는 좋은 기회와 같은 간단한 일을 놓치게 될 것입니다. 아시겠지만 영국에서는 사이클링이 많은 지지를 받았습니다. 그래서 저는 좀 더 생리학적인 측면에서 자전거 타기에 대해 더 많이 배우기 위해 더 많은 노력을 기울였습니다. 변경을 위한 다른 것.

Drew: 웹에서의 성능 최적화와 사이클링에서의 성능 최적화 사이에 별 차이가 없을 수도 있습니다. 모두 미미한 이득일 뿐입니다. 그렇죠?

해리: 네, 맞습니다. 그리고 제가 자전거에서 보고 있던 그래프의 양은... 저는 자전거에서 전력 데이터를 얻었습니다. 나는 자전거를 타고 나가서 "아, 여기에 5와트가 더 있었지만 10을 절약했다면 거기에 와트, 나는 이것, 이것, 그리고 이것이 사상 가장 빠른 것을 할 수 있습니다.” 그리고… 하지만 네 말이 맞아요. 거기에서 정말 흥미로운 것을 발견한 것 같아요. 나는 그런 종류의 것이 약간 강박 관념이 있고 숫자를 쫓는 것을 좋아하는 사람에게 좋은 스포츠/여가 활동이라고 생각합니다. 이것에 대해 알고 계시겠지만 Strava, KOM이 있습니다. 나는 작년에 그 중 19개를 가방에 넣었는데, 이는 나에게 경이로운 양입니다. 그리고 그것은 거의 모든 사용 가능한 데이터에 집착하고 "내가 이기려고 하는 이 사람, 그는 이 시점에서 700와트를 하고 있었습니다. 내가 1000까지 올라갔다가 끝낼 수 있다면" 그리고 ㅋ, blah, blah ... 집착하는 것입니다. 못생겼다. 하지만 당신 말이 맞아요, 비슷한 종류의 것 같아요, 그렇죠? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

해리: 네. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.