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