AI뉴스 · AI·소프트웨어

Cloudflare BEACON 공개, 46개국에서 WebKit 속도가 Blink보다 10% 이상 느렸다

0 회three-line
Cloudflare BEACON 공개 데이터셋 소개 이미지
Cloudflare BEACON 데이터셋 소개 — 출처: Cloudflare 블로그 (press material)

Cloudflare가 9월 28일 상위 1만 개 웹사이트의 실사용 속도 측정치를 'BEACON'이라는 공개 데이터셋으로 내놓았다. Google BigQuery에서 매일 갱신되는 이 데이터의 첫 분석에서, WebKit 비중이 10%를 넘는 국가 가운데 46개국은 로딩(LCP)이나 반응(INP) 속도가 Blink 계열 브라우저보다 10% 이상 나빴다. 웹 성능을 손보는 개발자는 자기 사이트 수치를 업계 분포와 견줄 기준을 얻은 셈이다.

BEACON은 무엇이고 어디서 볼 수 있나

BEACON은 Cloudflare 네트워크에서 가장 큰 1만 개 웹사이트에서 모은 실제 방문 측정치를 익명으로 공개한 데이터셋이다. 사이트 운영자가 아니어도 연구자·개발자·브라우저 제작사가 같은 자료를 쓸 수 있다.

항목내용
공개 주체·일자Cloudflare, 9월 28일
규모상위 1만 개 사이트에서 모은 수십억 건의 측정
갱신매일 Google BigQuery에 반영
지표LCP(로딩), CLS(화면 안정성), INP(반응성) 전체 분포
규격커뮤니티가 만든 RUM Archive 규격을 100배 규모로 확장
접근BigQuery 공개 데이터, 예제 쿼리 함께 제공

BigQuery는 Google이 제공하는 서버리스 데이터 웨어하우스로, SQL 계열 언어로 대용량 데이터를 분석한다.

평균이 아니라 분포를 준다는 것은 무엇이 다른가

BEACON은 세 지표를 단일 평균이 아니라 전체 히스토그램으로 공개한다. 그래서 원하는 백분위를 직접 뽑을 수 있고, 75번째 백분위(P75)에서 멈추지 않고 가장 느린 꼬리까지 들여다볼 수 있다.

Cloudflare 샌프란시스코 사옥 입구
Cloudflare 샌프란시스코 사옥 입구(101 Townsend Street) — 사진: HaeB · Wikimedia Commons · CC BY-SA 4.0

세 지표는 Core Web Vitals다. Cloudflare는 이 지표들이 체감 성능을 재는 사실상의 표준으로 오래 쓰였다고 설명한다. 이번 데이터가 보여 주는 것은 평균에 가려진 느린 경험이 어디에 몰려 있는가다.

첫 분석에서 드러난 속도 격차는 어디에 있나

WebKit은 현재 iOS의 유일한 브라우저 엔진이고, 전체로는 이 지표들에서 가장 좋은 성적을 낸다. 그러나 그 우위가 모든 곳에서 통하지는 않는다. WebKit 비중이 10%를 넘는 국가 중 46개국에서 LCP나 INP, 또는 둘 다가 크롬·엣지·오페라 같은 Blink 계열보다 10% 이상 나빴다. 캄보디아에서는 WebKit이 페이지뷰의 17.5%를 차지하는데 LCP가 Blink보다 50% 나빴다.

업종별로는 정부·정치, 건강, 어린이 안전(Safe for Kids) 분류가 상위권이고 광고·종교·날씨 분류가 대체로 가장 느렸다. P75 하나로는 보이지 않던 차이도 드러난다. 여러 업종에서 가장 느린 꼬리 구간의 경험이 급격히 나빠지며, 시각적 안정성(CLS)에서 특히 두드러진다.

페이지 이동 방식도 속도를 가른다. 싱글 페이지 앱의 소프트 이동은 모든 백분위에서 하드 이동보다 2~3배 빨랐지만, 첫 방문 로딩은 그보다 훨씬 무겁다.

LCPP50P75P90P95
하드 이동791ms1,421ms2,636ms4,122ms
소프트 이동274ms582ms1,169ms1,816ms
첫 방문(랜딩 페이지)1,370ms2,681ms5,397ms8,940ms

Cloudflare는 "이후 이동이 빨라진 만큼 첫 경험의 느림을 상쇄해야 한다"고 짚었다. 사용자가 랜딩 페이지를 넘어 이동하지 않는다면 무거운 첫 로딩의 비용을 회수하지 못할 수 있다.

페이지가 느려지는 단계는 어디인가

LCP는 네 단계로 쪼갤 수 있다. HTML 문서를 받는 시간(TTFB), 후보 요소를 발견하기까지의 로드 지연, 자원을 내려받는 시간, 마지막으로 화면에 그리기까지의 렌더 지연이다. Cloudflare가 제시한 단계별 값을 Good 구간과 Poor 구간으로 나눠 보면 시간이 늘어나는 곳이 한눈에 보인다.

LCP 단계GoodPoor늘어난 시간
문서 TTFB598ms1,891ms+1,293ms
로드 지연76ms1,485ms+1,409ms
자원 다운로드119ms119ms0ms
렌더 지연157ms2,002ms+1,845ms
단계 값의 합약 950ms약 5,497ms약 +4,547ms

늘어난 시간은 전부 TTFB, 로드 지연, 렌더 지연에서 나왔고 다운로드 시간은 그대로다. Cloudflare도 기준을 넘긴 대부분의 페이지뷰에서 개선 여지가 큰 곳은 이미지·폰트·영상을 내려받는 쪽이 아니라 LCP 후보를 일찍 발견하고 렌더링을 막는 요소를 푸는 쪽이라고 정리한다.

반응성(INP)은 입력 지연, 처리 시간, 표시 지연으로 나뉜다. 가장 느린 상호작용(Poor)에서는 처리 시간이 284ms로 가장 길고, 표시 지연도 217ms로 Good 구간의 56ms보다 크게 늘어난다. 표시 지연은 대개 복잡한 CSS 레이아웃 재계산이 좌우한다.

활용할 때 알아둘 한계와 다음 일정은 무엇인가

데이터는 쓰기 전에 가공 과정을 확인해야 한다. Cloudflare는 도메인 이름과 URL 경로를 제거해 사이트를 식별할 수 없게 했고, 트래픽 큰 사이트가 결과를 지배하지 않도록 대상을 상위 1만 개 사이트로 한정했다. 국가·운영체제·브라우저·프로토콜이 같은 기록을 묶고 데이터가 5건 미만인 묶음은 버린다. 측정 대상은 Cloudflare 네트워크의 대형 사이트다.

BigQuery에는 이 글의 표를 만든 예제 쿼리(업종별 CWV, 전역 LCP·INP 단계, 하드·소프트 이동, 랜딩 페이지, 국가별 집계)가 함께 저장돼 있어 조건만 바꿔 다시 돌려 볼 수 있다. Cloudflare는 LCP·INP 단계 지표를 몇 주 안에 자사 실사용 모니터링(RUM) 대시보드에도 추가하겠다고 밝혔다.

출처

  1. How fast is the web? Explore billions of real-user measurements with BEACON — Cloudflare 블로그
  2. BigQuery — Wikipedia (en)

이 기사는 AI 보조 도구로 초안을 작성하고 편집 책임자가 1차 출처와 대조해 사실을 확인한 뒤 수정·게재했습니다. 사실과 다른 내용이 있으면 정정 요청을 보내주세요.

댓글

에디터 배지가 붙은 댓글은 CloudTop100 편집진 계정이 AI로 쓴 것입니다