수백만 개의 사이트의 웹사이트 로드 성능을 개선하여 우수한 PageSpeed Insights 및 코어 웹 바이탈 점수를 얻기 위한 경로를 개선하기 위해 Wix에서 도입된 몇 가지 주요 변경사항에 관한 우수사례입니다.
CrUX 및 HTTPArchive의 데이터에 따르면 업계 표준, 클라우드 제공업체, CDN 기능을 주요 웹사이트 런타임 재작성과 함께 활용하여 모든 Core Web Vitals 측정항목에서 양호한 75번째 백분위수 점수를 얻은 Wix 사이트의 비율이 전년 대비 3배 이상 증가했습니다.
Wix는 성능 중심 문화를 채택했으며 추가 개선사항을 사용자에게 계속 출시할 예정입니다. 성능 KPI에 집중함에 따라 코어 웹 바이탈 기준점을 통과하는 사이트 수가 증가할 것으로 예상됩니다.
개요
성능 세계는 많은 변수와 복잡성으로 인해 아름답게 복잡합니다. 연구에 따르면 사이트 속도는 비즈니스의 전환율과 수익에 직접적인 영향을 미칩니다. 최근 몇 년 동안 업계는 성능 가시성과 웹의 속도를 향상시키는 데 더욱 중점을 두었습니다. 2021년 5월부터 페이지 경험 신호가 Google 검색 순위에 포함됩니다.
Wix는 수백만 개의 사이트를 지원해야 한다는 고유한 과제를 갖고 있으며, 그중 일부는 수년 전에 구축되었으며 현재까지 업데이트되지 않았습니다. Google에서는 사용자가 사이트의 성능을 분석하고 개선하기 위해 어떤 조치를 취할 수 있는지 지원하기 위한 다양한 도구와 도움말을 제공하고 있습니다.
Wix는 관리되는 환경이며 모든 것이 사용자가 소유하는 것은 아닙니다. 공통 인프라를 공유하면 이러한 모든 사이트에 많은 어려움이 있지만, 규모의 경제를 활용하는 등 전반적으로 큰 개선의 기회가 열리기도 합니다.
공통 언어로 말하기
성능과 관련된 주요 어려움 중 하나는 기술적 성능과 인지된 성능을 모두 고려하면서 사용자 환경의 다양한 측면을 설명하는 공통 용어를 찾는 것입니다. 조직 내에서 잘 정의되고 공통된 언어를 사용하여 다양한 기술적 부분과 장단점을 쉽게 논의하고 분류할 수 있었고, 성능 보고서를 명확히 했으며, 먼저 개선해야 할 측면을 파악하는 데 큰 도움이 되었습니다.
웹 바이탈과 같은 업계 표준 측정항목을 포함하도록 모든 모니터링 및 내부 논의를 조정했으며, 여기에는 다음이 포함됩니다.
사이트 복잡성 및 성능 점수
HTML만 사용하여 매우 간단하게 만들고 CDN을 통해 제공하면 즉시 로드되는 사이트를 쉽게 만들 수 있습니다.
그러나 실제로 사이트가 점점 더 복잡하고 정교해지고, 문서가 아닌 애플리케이션처럼 작동하며, 블로그, 전자상거래 솔루션, 맞춤 코드 등의 기능을 지원하고 있습니다.
Wix는 매우 큰 다양한 템플릿을 제공하므로 사용자는 다양한 비즈니스 기능이 포함된 사이트를 쉽게 구축할 수 있습니다. 이러한 추가 기능에는 약간의 성능 비용이 발생하는 경우가 많습니다.
여정
초기에는 HTML이 있었고
웹페이지는 로드될 때마다 HTML 문서를 검색하기 위해 URL을 처음 요청하는 것으로 시작됩니다. 이 HTML 응답은 사이트를 실행하고 렌더링하기 위해 모든 추가 클라이언트 요청과 브라우저 로직을 트리거합니다. 이는 페이지 로드에서 가장 중요한 부분입니다. 응답의 시작 부분 (TTFB, 첫 바이트까지의 시간)이 도착할 때까지 아무 일도 일어나지 않기 때문입니다.
이전: 클라이언트 측 렌더링 (CSR)
대규모 시스템을 운영할 때는 항상 성능, 안정성, 비용 등의 장단점을 고려해야 합니다. 몇 년 전만 해도 Wix는 클라이언트 측 렌더링 (CSR)을 사용했습니다. 이 CSR은 클라이언트 측 (즉, 브라우저)에서 JavaScript를 통해 실제 HTML 콘텐츠를 생성하여 큰 백엔드 운영 비용 없이 대규모 사이트를 지원할 수 있었습니다.
CSR을 통해 기본적으로 비어 있는 공통 HTML 문서를 사용할 수 있었습니다. 그 것은 필요한 코드와 데이터의 다운로드를 트리거한 다음 클라이언트 기기에서 전체 HTML을 생성하는 데 사용되었습니다.
현재: 서버 측 렌더링 (SSR)
몇 년 전 Google은 서버 측 렌더링 (SSR)으로 전환했습니다. 이는 검색엔진 최적화와 성능 모두에 유용하며, 초기 페이지 표시 시간을 개선하고, 자바스크립트 실행을 완전히 지원하지 않는 검색엔진의 색인 생성을 개선할 수 있기 때문입니다.
이 접근 방식은 특히 기기/연결 속도가 느릴 때 가시성 환경을 개선하고 성능을 더욱 최적화할 수 있는 가능성을 열어주었습니다. 하지만 이는 웹페이지 요청마다 고유한 HTML 응답이 즉석에서 생성되었다는 의미이기도 하며, 특히 조회수가 많은 사이트의 경우 최적이 아닙니다.
여러 위치의 캐싱 소개
각 사이트의 HTML은 대부분 정적이지만 몇 가지 주의사항이 있었습니다.
- 자주 변경됩니다. 사용자가 사이트를 수정하거나 웹사이트 스토어 인벤토리와 같은 사이트 데이터를 변경할 때마다 기록됩니다.
- 방문자별 특정 데이터와 쿠키가 있어 동일한 사이트를 방문하는 두 사람이 약간 다른 HTML을 보게 됩니다. 예를 들어 방문자가 장바구니에 담은 항목 또는 방문자가 이전에 비즈니스에 시작한 채팅을 기억하는 등의 제품 기능을 지원할 수 있습니다.
- 일부 페이지는 캐시할 수 없습니다. 예를 들어 커스텀 사용자 코드가 있고 문서의 일부로 현재 시간을 표시하는 페이지는 캐싱할 수 없습니다.
처음에는 방문자 데이터 없이 HTML을 캐시한 다음 캐시 적중마다 각 방문자에 대해 즉석에서 HTML 응답의 특정 부분만 수정했습니다.
사내 CDN 솔루션
이를 위해 자체 솔루션을 배포했습니다. 프록시 및 캐싱에 Varnish HTTP 캐시를 사용하고, 무효화 메시지에 Kafka를 사용하고, 이러한 HTML 응답을 프록시하지만 HTML을 변형하고 방문자별 데이터와 쿠키를 캐시된 응답에 추가하는 Scala/Netty 기반 서비스를 배포했습니다.
이 솔루션 덕분에 Google은 이러한 슬림 구성요소를 전 세계에 분산된 여러 지리적 위치와 여러 클라우드 제공업체 리전에 배포할 수 있었습니다. 2019년에 Google은 15개 이상의 새로운 리전을 도입했으며 캐싱할 수 있는 페이지 뷰의 90% 이상에 캐싱을 점진적으로 사용 설정했습니다. 추가 위치에서 사이트를 제공하면 클라이언트와 HTML 응답을 제공하는 서버 간의 네트워크 지연 시간이 줄어 콘텐츠를 웹사이트 방문자에게 더 가깝게 제공할 수 있습니다.
또한 동일한 솔루션을 사용하고 사이트 콘텐츠가 변경될 경우 캐시를 무효화하여 특정 읽기 전용 API 응답을 캐시하기 시작했습니다. 예를 들어 사이트의 블로그 게시물 목록은 게시물이 게시/수정될 때 캐시되고 무효화됩니다.
복잡성 감소
캐싱을 구현한 후 주로 TTFB 및 FCP 단계에서 성능이 크게 향상되었으며 최종 사용자에게 더 가까운 위치에서 콘텐츠를 제공하여 안정성이 개선되었습니다.
하지만 각 응답의 HTML을 수정해야 하는 필요성으로 인해 불필요한 복잡성이 생겼습니다. 이를 삭제하면 성능을 더욱 개선할 수 있습니다.
브라우저 캐싱 (및 CDN 준비)
약 13%
브라우저 캐시에서 직접 제공되는 HTML 요청으로 대역폭을 많이 절약하고 반복 보기의 로드 시간을 단축합니다.
다음 단계는 실제로 이 방문자별 데이터를 HTML에서 완전히 삭제한 후, HTML이 도착한 후 이 목적으로 클라이언트에서 호출하는 별도의 엔드포인트에서 검색하는 것이었습니다.
Google에서는 이 데이터와 쿠키를 새 엔드포인트로 신중하게 이전했습니다. 새 엔드포인트는 페이지를 로드할 때마다 호출되는 것이지만 전체 페이지 상호작용에 도달하기 위해 하이드레이션 프로세스에만 필요한 슬림한 JSON을 반환합니다.
이를 통해 HTML의 브라우저 캐싱을 사용 설정할 수 있었습니다. 즉, 이제 브라우저는 반복 방문에 대한 HTML 응답을 저장하고 콘텐츠가 변경되지 않았는지 검증하기 위해 서버만 호출합니다. 이 작업은 기본적으로 특정 버전의 HTML 리소스에 할당되는 식별자인 HTTP ETag를 사용하여 수행됩니다. 콘텐츠가 여전히 동일하면 서버에서 본문 없이 304 Not Modified 응답을 클라이언트로 전송합니다.
또한 이러한 변경으로 인해 HTML은 더 이상 방문자와 관련이 없으며 쿠키를 포함하지 않습니다. 즉, 기본적으로 어디에나 캐시될 수 있으므로 전 세계 수백 곳의 위치에서 훨씬 더 나은 지리적 위치를 보유한 CDN 제공업체를 사용할 수 있는 기회가 열립니다.
DNS, SSL, HTTP/2
캐싱을 사용 설정하자 대기 시간이 단축되고 초기 연결의 다른 중요한 부분이 더 많아졌습니다. 네트워킹 인프라와 모니터링을 개선하여 DNS, 연결, SSL 시간을 개선할 수 있었습니다.
모든 사용자 도메인에 HTTP/2가 사용 설정되었으므로, 필요한 연결 수와 새로 연결할 때마다 발생하는 오버헤드가 모두 줄어들었습니다. HTTP/2의 성능 및 복원력 이점을 활용하면서 배포하기가 상대적으로 쉬웠습니다.
Brotli 압축 (gzip과 비교)
21~25%
파일 전송 크기 중앙값 감소
전통적으로 모든 파일은 웹에서 가장 널리 사용되는 HTML 압축 옵션인 gzip 압축을 사용하여 압축되었습니다. 이 압축 프로토콜은 약 30년 전에 처음 구현되었습니다!
최신 Brotli 압축은 단점이 거의 없는 압축 개선사항을 제공하며 연간 웹 연감 압축 챕터에 설명된 대로 서서히 인기를 얻고 있습니다. 한동안 모든 주요 브라우저에서 지원되었습니다.
이를 지원하는 모든 클라이언트를 위해 에지의 nginx 프록시에서 Brotli 지원을 사용 설정했습니다.
Brotli 압축을 사용하면서 파일 전송 크기 중앙값이 21% 에서 25%로 감소하여 대역폭 사용량이 줄었고 로드 시간이 향상되었습니다.
콘텐츠 전송 네트워크 (CDN)
동적 CDN 선택
Wix에서는 항상 CDN을 사용하여 사용자 웹사이트에 모든 JavaScript 코드와 이미지를 제공합니다.
최근에는 클라이언트의 네트워크와 원본에 따라 최고 성능의 CDN을 자동으로 선택하기 위해 DNS 제공업체의 솔루션과 통합했습니다. 이를 통해 각 방문자에게 가장 적합한 위치에서 정적 파일을 제공하고 특정 CDN의 가용성 문제를 방지할 수 있습니다.
제공 예정... CDN에서 제공하는 사용자 도메인
마지막으로, 가장 중요한 부분인 CDN을 통해 사용자 도메인의 HTML을 제공해야 합니다.
위에서 설명한 것처럼 Google은 사이트별 HTML 및 API 결과를 캐시하고 제공하기 위한 자체 자체 솔루션을 만들었습니다. 여러 새로운 리전에서 이 솔루션을 유지관리하는 것도 운영 비용이 발생하며 새 위치를 추가하는 것은 관리 및 지속적으로 최적화해야 하는 프로세스가 됩니다.
Google은 현재 여러 CDN 제공업체와 통합하여 CDN 위치에서 직접 전체 Wix 사이트를 제공하여 전 세계 서버의 배포를 개선하고 응답 시간을 더욱 개선하고 있습니다. Google에서 제공하는 도메인이 많아서 에지에서 SSL 종료가 필요하기 때문에 문제가 발생합니다.
CDN과 통합하면 Wix 웹사이트가 그 어느 때보다도 고객에게 가깝게 제공되고 HTTP/3과 같은 최신 기술을 포함하여 Google의 추가적인 노력 없이도 로드 환경이 더 향상됩니다.
성능 모니터링에 관한 간략한 소개
Wix 사이트를 운영하는 경우 Wix 사이트 성능 결과에 어떤 영향을 미치는지, 다른 웹사이트 플랫폼과 비교하면 어떤지 궁금할 것입니다.
위에서 수행한 대부분의 작업은 지난해에 배포되었으며 일부는 아직 출시 중입니다.
HTTPArchive의 Web Almanac은 최근 CMS 사용자 환경에 관한 훌륭한 챕터가 포함된 2020 버전을 게시했습니다. 이 문서에서 설명하는 많은 수치는 2020년 중반의 수치입니다.
Google은 2021년 업데이트된 보고서를 기대하고 있으며 사이트의 CrUX 보고서와 내부 성능 측정항목을 적극적으로 모니터링하고 있습니다.
Google은 지속적으로 로드 시간을 개선하고 성능 저하 없이 원하는 대로 사이트를 빌드할 수 있는 플랫폼을 사용자에게 제공하기 위해 노력하고 있습니다.
DebugBear는 최근에 위에서 언급한 일부 영역을 다루고 각 플랫폼에 구축된 매우 간단한 사이트의 성능을 살펴보는 매우 흥미로운 웹사이트 작성 도구 성능 리뷰를 발표했습니다. 이 사이트는 거의 2년 전에 구축되었으며 그 이후로 수정되지 않았지만 플랫폼은 지속적으로 개선되고 있으며 이와 함께 사이트 성능도 지난 1년 반 동안 데이터를 확인하여 확인할 수 있습니다.
결론
Google의 경험이 조직에 성과 중심 문화를 채택하는 데 영감을 얻고 위의 세부정보가 도움이 되고 플랫폼 또는 사이트에 적용되기를 바랍니다.
요약:
- 업계에서 인증한 도구를 사용하여 지속적으로 추적할 수 있는 측정항목 집합을 선택하세요. 코어 웹 바이탈을 사용하는 것이 좋습니다.
- 브라우저 캐싱 및 CDN 활용
- HTTP/2 (또는 가능한 경우 HTTP/3)로 마이그레이션합니다.
- Brotli 압축을 사용합니다.
스토리를 전해 주셔서 감사합니다. 궁금한 점을 질문하고, Twitter 및 GitHub에서 아이디어를 공유하고, 즐겨 찾는 채널에서 웹 성능 관련 대화에 참여하세요.