Google Chrome의 최고의 속도 향상 팁은 개발자 플래그에 숨겨져 있습니다

웹사이트는 예전과 같지 않습니다. 이제는 훨씬 더 많은 스크립트가 사용되며, 브라우저 내에서 직접 실행되는 완전한 웹 앱들로 인해 웹은 20년 전과는 완전히 다른 공간이 되었습니다. 당연한 이야기죠.

하지만 이 모든 것에는 대가가 따릅니다. 바로 속도입니다. 웹 페이지는 더 무거워졌고, 웹 브라우징을 원래 의도했던 것처럼 즉각적으로 느끼게 하려면 네트워크 속도, 브라우저, 서버 모두가 더 열심히 일해야 합니다.

물론 이를 위해 많은 노력이 이루어지고 있지만, 대부분은 "웹사이트를 운영체제만큼 무겁게 만드는 것을 멈추자"는 쪽보다는 "로딩을 더 빠르게 만들자"는 쪽에 치우쳐 있는 것 같습니다. 캐싱, CDN, 압축, 지연 로딩(lazy loading), 더 스마트한 JavaScript 전달, 그리고 이제는… 사전 렌더링(prerendering)까지 등장했습니다.

관련 기사

Google의 8.8.8.8조차 이 DNS 테스트에서 상위 2위 안에 들지 못했습니다

가장 빠른 DNS를 찾는 유일한 방법은 직접 테스트하는 것입니다.

클릭하기 전에 웹사이트를 로드하는 Chrome 플래그

웹 브라우징을 즉각적으로 느끼게 할 수 있습니다

자, ‘Speculation Rules API’라는 비교적 새로운 웹 기술이 있습니다. 이 기술은 추측(speculation)을 기반으로 하기 때문에 이런 이름이 붙었습니다. 기본적인 개념은 이렇습니다. 사용자가 웹사이트를 읽고 있을 때, 웹사이트가 브라우저에 다음에 클릭할 가능성이 높은 페이지를 알려주면, Chrome이 사용자가 실제로 클릭하기 전에 백그라운드에서 해당 페이지를 로드하기 시작하는 것입니다.

장점은 분명합니다. 사용자가 실제로 페이지를 클릭했을 때, 작업의 일부 또는 전부가 이미 완료된 상태가 됩니다. 페이지가 훨씬 빠르게 나타나며, 최상의 경우 거의 즉각적으로 느껴질 수 있습니다.

Chrome의 플래그를 통해 이를 직접 실험해 볼 수 있습니다. chrome://flags로 이동한 다음 ‘prerender’를 검색하세요. Chrome 버전에 따라 하나 이상의 사전 렌더링 관련 플래그가 보일 수 있습니다. Chrome 플래그는 실험적인 기능이므로 정확한 플래그 이름은 변경될 수 있지만, 일반적인 개념은 동일합니다. 빌드에서 사용 가능한 사전 렌더링 관련 옵션을 활성화하고 Chrome을 다시 시작하면, 웹사이트가 지원할 때 Chrome이 이 새로운 추측성 로딩 동작을 더 적극적으로 사용하게 됩니다.

첫 번째 플래그(prerender)가 핵심입니다. 이 기능이 작동하려면 반드시 켜져 있어야 합니다. 두 번째 플래그는 범위를 확장하는 향상된 기능입니다. 기본적으로 Chrome은 헤더에 스크립트가 포함된 사이트는 로드하지 않습니다. 방문하지도 않은 웹 페이지의 스크립트가 잘못 실행될 수 있기 때문입니다. 하지만 두 번째 플래그를 켜면, Chrome은 스크립트를 실행해야 하는 시점 직전까지 웹 페이지를 로드합니다. 거기서 일시 중지하고, 사용자가 실제로 클릭하여 웹 페이지를 방문할 때를 위해 스크립트를 보관합니다. 꽤 영리한 방식이죠.

예를 들어, 다단계 양식을 작성 중이라면 웹사이트는 사용자가 현재 페이지를 완료한 후 ‘다음’을 클릭할 것이라고 합리적으로 추측할 수 있습니다. 따라서 Chrome에 다음 페이지를 미리 준비하도록 요청할 수 있습니다. 그러면 실제로 ‘다음’을 클릭했을 때, 브라우저가 처음부터 모든 작업을 수행하는 것을 기다릴 필요가 없습니다. 바로 페이지로 이동하게 되죠. 정말 훌륭하게 들립니다.

이제 단점과 주의 사항에 대해 이야기하고, 이것이 얼마나 큰 차이를 만드는지, 그리고 어떻게 직접 테스트할 수 있는지 보여드리겠습니다.

모든 곳에서 사용할 수는 없습니다

분명한 이유가 있습니다

이제 가장 중요한 문제를 다뤄보겠습니다. Chrome에서 이 기능을 켰는데도 전후 차이를 전혀 느끼지 못했다면, 아마 두 가지 이유 때문일 것입니다. 1. 네트워크가 이미 빠르거나, 2. 웹사이트가 추측 규칙(speculation rules)을 지원하지 않기 때문입니다.

테스트에서 두 가지 모두 다루겠지만, 먼저 두 번째 이유부터 이야기해 보겠습니다.

분명히 Speculation Rules API는 어느 정도 지능적이어야 합니다. 웹 페이지는 링크로 가득 차 있습니다. 만약 모든 웹사이트와 그 안의 모든 링크에서 자동으로 작동한다면 재앙이 될 것입니다. 지금 읽고 계신 이 페이지에도 수백 개의 링크가 있을 것입니다. 브라우저가 그 모든 것을 사전 렌더링하기 시작한다면 컴퓨터는 작은 정신적 붕괴를 겪을 것입니다. 또한 방문하지도 않을 페이지들을 로드하느라 데이터를 낭비하게 되겠죠.

이 추측이 작동하는 주된 방식은 마우스 움직임을 통한 것입니다. 여기에는 여러 유형이 있습니다. 예를 들어, 일부 웹사이트는 링크 위에 마우스를 올리면(hover) 페이지를 사전 렌더링하기 시작합니다. 링크 위에 마우스를 올렸다는 것은 클릭할 가능성이 높다는 추측이므로, 페이지를 미리 준비해 두는 것입니다.

또한 ‘열의(eagerness)’ 수준도 다릅니다. 웹사이트는 Chrome에 즉시 페이지를 준비하도록 요청할 수도 있고, 링크 위에 마우스를 올렸을 때만, 혹은 클릭을 시작할 때만 준비하도록 요청할 수도 있습니다. 규칙이 공격적일수록 탐색 속도는 더 빠르게 느껴질 수 있지만, 사용자가 실제로 클릭하지 않으면 더 많은 리소스가 낭비될 수 있습니다.

일부 웹사이트에서는 링크 위에 마우스를 올리면 추측성 로딩이 시작됩니다. 추측은 간단합니다. 마우스가 링크 위에 있다면 클릭할 가능성이 꽤 높다는 것입니다. 따라서 사용자가 손가락으로 결정을 내리는 동안 Chrome이 페이지를 준비하기 시작할 수 있습니다. 다른 웹사이트에서는 마우스 버튼을 누르는 순간에만 시작됩니다. 일반적으로 탐색은 전체 클릭이 완료된 후(누르고, 떼고, 브라우저가 이동)에 발생합니다. 보수적인 추측성 로딩을 사용하면, Chrome은 버튼을 떼기 전, 누르는 즉시 아주 약간의 시작 시간을 벌 수 있습니다. 별것 아닌 것처럼 들릴 수 있지만, 브라우저가 네트워크 요청을 일찍 시작할 수 있다면 몇 밀리초라도 도움이 됩니다.

관련 기사

왜 모든 웹사이트에서 작동하지 않나요?

그렇다면 왜 모든 웹사이트와 모든 링크에 대해 이 기능을 활성화하고 링크 위에 마우스를 올릴 때만 트리거하지 않을까요? 음, 어떤 경우에는 작동하겠지만, 이런 상황을 고려해 보세요. 웹사이트에 로그인한 상태에서 커서가 ‘로그아웃’ 버튼 위를 지나갑니다. 클릭은 하지 않고 그냥 마우스를 올리기만 합니다. 브라우저가 이를 방문하려는 페이지로 간주한다면 어떻게 될까요? 이상적인 상황은 아닐 것입니다.

물론 사전 렌더링 메커니즘은 똑똑합니다. 한 번에 두 페이지 이상을 사전 렌더링하지 않으므로, 세 번째 페이지를 사전 렌더링해야 할 때는 메모리가 부풀지 않도록 이전 페이지 중 하나를 삭제합니다. 제가 테스트했을 때 확인한 내용입니다.

USB-C는 이제 최대 240W까지 전력을 전달할 수 있습니다. 가능은 하지만, 실제로 그렇게 될까요? 아닙니다. 충전기는 케이블과 장치가 그만큼의 전력을 감당할 수 있다는 확신이 필요합니다. 충전기가 지원하고, 장치가 지원하고, 케이블이 물리적으로 충분히 튼튼해 보여도 충전기는 여전히 케이블로부터 확인을 원합니다. 그 확인은 E-Marker 칩에서 옵니다. 케이블이 "네, 감당할 수 있습니다"라고 말하는 것이죠. 케이블이 그런 확인을 하지 않으면 충전기는 더 안전한 전력 수준으로 돌아갑니다. 케이블은 E-Marker 칩 없이도 괜찮을지 모르지만, 케이블이 녹을 위험을 감수하시겠습니까? 돌다리도 두들겨 보고 건너는 게 낫죠!

여기서도 마찬가지입니다. Chrome은 웹사이트가 "이 URL을 프리페치(prefetch)하거나 사전 렌더링해도 괜찮습니다"라고 선제적으로 말해주기를 원합니다. 그렇지 않으면 Chrome은 플래그 페이지에서의 여러분의 열의와 상관없이 일반적으로 ‘아니오’를 기본값으로 설정합니다. 웹사이트는 준비하려는 URL에 대한 규칙을 정의해야 합니다. 화이트리스트 모델인 셈입니다.

그리고 결국 클릭하지 않으면 Chrome은 추측성 페이지를 버립니다. 메모리, 배터리, 리소스 제약에 대해 꽤 영리하게 대처합니다. 제한이 있어서 RAM이 가득 찰 때까지 무한정 페이지를 사전 렌더링하지 않습니다. 제가 테스트했을 때 Chrome은 한 번에 두 개 이상의 사전 렌더링된 페이지를 유지하지 않았습니다. 다른 페이지를 준비해야 할 때, 공간을 확보하기 위해 오래된 사전 렌더링 페이지를 삭제했습니다. 올바른 동작입니다. 하지만 되돌릴 수 없는 한 가지는 네트워크 트래픽입니다. Chrome이 백그라운드에서 페이지를 가져왔는데 사용자가 열지 않았다면, 그 데이터는 이미 사용된 것입니다.

사전 렌더링 테스트

정면 대결

이제 테스트를 통해 이것이 실제로 차이를 만든다는 것을 보여드리겠습니다. 의미 있는 공정한 테스트를 위해서는 세 가지 요소가 필요합니다.

1. Chrome 사전 렌더링 활성화.
2. 추측 규칙을 지원하는 웹사이트.
3. 느린 네트워크 (그렇지 않으면 차이가 미미할 수 있기 때문입니다). 저는 300Mbps 연결을 사용합니다. 2Gbps가 아니라고 놀리셔도 되지만, 웹 브라우징에는 충분히 빠릅니다. 일반적인 연결에서는 대부분의 일반 페이지가 이미 충분히 빠르게 로드되어 이 기능이 극적으로 느껴지지 않을 수 있습니다. 다행히 Chrome 개발자 도구(DevTools)는 테스트를 더 정확하게 만드는 데 필요한 모든 것을 제공합니다.

추측을 지원하는 웹사이트

아직 많은 독립형 웹사이트가 추측 규칙을 지원하지 않습니다. All Things N이 한 예인데, 아직 구현하지 않았습니다. 이 테스트를 위해 DebugBear 웹사이트를 사용했는데, 이 사이트는 훌륭하게 구현되어 있습니다. 그들의 블로그에서 Speculation API에 대해 읽은 후 이 웹사이트를 알게 되었습니다.

사전 렌더링 플래그를 활성화한 상태에서 웹사이트를 열고 F12를 눌러 개발자 도구를 불러왔습니다. 그런 다음 ‘Application’ 탭으로 이동하여 ‘Speculative loads’ 섹션을 열었습니다. 이곳에서 Chrome은 웹사이트가 제공한 추측 규칙과 그중 실행 중, 준비 완료, 실패 또는 무시된 항목이 있는지 보여줍니다.

DebugBear는 가입 링크 위에 마우스를 올리면 가입 페이지를 준비하는 규칙을 포함하여 간단한 규칙들을 적용해 두었습니다. 가입 버튼 위에 마우스를 올리자 규칙 상태가 ‘idle’에서 ‘running’으로, 그리고 ‘ready’로 변경되었습니다.

우리가 보고 싶었던 것이 바로 이것입니다. 브라우저가 규칙을 수신하고, 그에 따라 행동하며, 제가 클릭하기 전에 페이지를 준비했습니다.

느린 네트워크

느린 네트워크를 어떻게 시뮬레이션할까요? 느린 네트워크를 가지고 있더라도 항상 일정하게 느리지는 않을 것입니다. 따라서 인위적으로 속도를 제한(throttle)해야 합니다. 다시 한번 개발자 도구가 해결사입니다.

‘Network’ 탭에 ‘Throttling’ 드롭다운이 있습니다. 저는 이를 ‘3G’로 설정했습니다. 이렇게 하면 브라우징 속도가 구형 모바일 연결과 비슷하게 제한됩니다. 사용자 지정 스로틀 프로필을 만들 수도 있지만, 3G는 너무 오래 걸리지 않으면서도 차이를 분명하게 보여주기 때문에 이 테스트에 충분합니다.

결과

테스트를 위해 두 개의 Chrome 인스턴스를 사용했으며, 모두 시크릿 모드였습니다. 시크릿 모드가 개인정보 보호에 큰 도움이 되는 것은 아니지만, 기존 캐시와 쿠키가 결과에 간섭하는 것을 방지하는 데 유용하기 때문에 여기서 사용했습니다.

두 인스턴스 모두 3G 속도로 제한되었습니다. 하나는 사전 렌더링을 활성화했고, 다른 하나는 비활성화했습니다. 그런 다음 웹사이트를 로드하고, 로드가 완료될 때까지 기다린 후, 가입 버튼 위에 1초 동안 마우스를 올리고, 클릭하여 가입 페이지가 로드되는 데 걸리는 시간을 비교했습니다. 결과는 다음과 같습니다.

이 테스트에서 페이지의 LCP(Largest Contentful Paint)가 거의 10초나 단축되었습니다. 상당한 차이입니다. 6초도 여전히 너무 길지만, 3G 환경이라는 점을 감안해야겠죠. 스크립트가 있기 때문에 사전 렌더링이 완전히 완료되지는 않았습니다. 사전 렌더링 상태에서 페이지를 클릭하면 제목과 구조는 즉시 로드되지만, 나머지 부분은 스크립트와 스크립트에 의해 그려지는 요소들이 로드될 때까지 기다려야 한다는 것을 알 수 있습니다. 느린 네트워크에서 이 기능은 구세주와 같습니다.

어떤 웹사이트가 이를 지원하나요?

소수이지만, 많은 것을 가져옵니다

지금까지 두 가지 요구 사항에 대해 이야기했습니다. Chrome이 사전 렌더링을 지원하고 허용해야 하며, 웹사이트가 추측 규칙을 구현해야 한다는 것입니다. 이는 당연한 질문을 불러일으킵니다. 어떤 웹사이트가 실제로 이를 지원할까요?

가장 큰 곳은 Google 검색입니다. Google은 검색 결과에 추측 규칙을 구현했지만, 주로 전체 사전 렌더링보다는 프리페칭(prefetching)을 위해 사용합니다. 검색 결과 위에 마우스를 올리면 Google은 Chrome에 대상 페이지를 미리 가져오도록 요청할 수 있으며, 이는 실제로 클릭했을 때 다음 페이지가 더 빨리 열리도록 돕습니다.

프리페칭과 사전 렌더링은 같은 것이 아닙니다. 프리페칭은 페이지나 일부 리소스를 미리 다운로드하는 것입니다. 사전 렌더링은 한 걸음 더 나아가 숨겨진 브라우징 컨텍스트에서 페이지를 준비하여 탐색 시 바로 교체될 수 있도록 합니다. 프리페칭은 더 저렴하고 안전합니다. 사전 렌더링은 더 강력하지만 비용이 더 많이 들고 페이지의 동작에 더 민감합니다.

또 다른 큰 곳은 WordPress입니다. WordPress 6.8은 핵심 기능에 추측성 로딩을 추가했는데, 이는 WordPress가 웹의 거대한 부분을 차지하고 있기 때문에 매우 중요한 일입니다. 하지만 기본 구현은 보수적입니다. 전체 사전 렌더링이 아닌 프리페칭을 사용하며, 신중한 열의를 가지고 수행합니다. 일반적인 언어로 말하자면, WordPress 사이트는 사용자가 클릭하기 직전에 다음 페이지를 준비하기 시작할 수 있지만, 반드시 백그라운드에서 미래의 페이지 전체를 렌더링하는 것은 아니라는 뜻입니다.

마지막으로 Shopify도 추측 규칙을 활용하고 있습니다. WordPress와 마찬가지로 Shopify는 수많은 웹사이트를 구동하기 때문에 중요합니다. 대형 플랫폼이 플랫폼 수준에서 웹 성능 기능을 구현하면, 모든 소규모 사이트 소유자가 API를 배우고, 결정을 내리고, 테스트하고, 그 과정에서 무언가를 망가뜨리지 않도록 노력하는 것보다 훨씬 빠르게 효과가 퍼질 수 있습니다.

더 많은 웹사이트가 이를 지원해야 합니다

이것은 여전히 실험적인 영역입니다. Chrome 플래그는 영구적인 설정이 아니며, 정확한 구현은 변경될 수 있습니다. 그럼에도 불구하고 방향성은 유망합니다. 이렇게 좋은데 왜 모든 웹사이트가 지원하지 않을까요? 제 추측(하하)으로는 몇 가지 이유가 있습니다.

사전 렌더링은 게으르게 처리하면 위험할 정도로 강력합니다. 일부 페이지는 사전 렌더링되어서는 안 됩니다. 계정 페이지, 로그아웃 링크, 쇼핑 카트, 결제 흐름, 분석이 많은 페이지, 개인화된 대시보드 등은 모두 주의가 필요합니다. Chrome이 위험한 동작을 차단하거나 지연시키더라도 웹사이트는 브라우저에 무엇을 준비하라고 요청할지 고민해야 합니다.

둘째, 리소스를 낭비할 수 있습니다. 사이트가 추측을 잘못하면 사용자가 열지 않는 페이지에 대해 대역폭, 메모리, 배터리, 서버 용량을 낭비할 수 있습니다.

물론 모든 성능 기능과 마찬가지로 이것이 좋은지 나쁜지는 구현 방식에 달려 있습니다. 하지만 신중하게 사용한다면 정말 훌륭한 기술입니다. 당분간 저는 이 기능을 켜둘 생각입니다.