워드프레스 속도, 도구마다 점수가 다른 이유

도구마다 점수가 다르면 한쪽이 고장 났다고 여기기 쉽지만, 한 도구 화면 안에서도 숫자는 두 갈래로 계산됩니다.⠀

한 주소를 PageSpeed Insights, GTmetrix, WebPageTest에 넣으면 숫자가 제각각이라 무엇이 맞는지 막막해집니다.⠀

플러그인 하나를 끄고 다시 쟀더니 점수는 올랐는데 PageSpeed Insights 위쪽 칸은 그대로라면, 어느 숫자를 믿어야 할까요?⠀

⠀⠀⠀

⠀⠀⠀

새로고침 속도는 어느 칸일까⠀

⠀⠀⠀

잘 열리던 사이트가 어느 날부터 굼떠지면 처음엔 회선 탓인가 싶어 새로고침부터 몇 번 누르게 됩니다.⠀

다른 사이트는 멀쩡히 열리는데 내 사이트만 답답하다면 새로고침을 더 눌러도 달라지는 것이 없습니다.⠀

검색 결과마다 플러그인을 줄이라거나 캐시를 깔라거나 호스팅을 바꾸라는 말이 달라 손이 멈추게 됩니다.⠀

⠀⠀⠀

그쯤 PageSpeed Insights에 주소를 넣어 보면 결과 화면에 두 종류의 데이터가 함께 나옵니다.⠀

위쪽은 Chrome UX Report(CrUX)가 실제 방문자에게서 모은 실사용자 데이터입니다.⠀

아래쪽은 Lighthouse로 한 번 측정한 실험실 데이터입니다.⠀

⠀⠀⠀

둥근 원 안의 성능 점수는 아래쪽 실험실 데이터로만 계산됩니다.⠀

위쪽 실사용자 영역은 최근 28일 동안 쌓인 방문 기록을 p75 기준으로 보여 줍니다.⠀

p75는 방문의 75%가 이 값 이하라는 뜻입니다.⠀

나머지 25%의 방문은 그 값보다 나쁜 쪽에 있습니다.⠀

⠀⠀⠀

원 안의 점수와 위쪽 값은 계산에 쓰는 데이터도 묶는 기간도 달라서 한 화면 안에서도 어긋나 보일 수 있습니다.⠀

내가 새로고침하며 느끼는 속도는 내 기기와 회선에서 겪은 한 번의 경험이라 위아래 어느 쪽과도 같은 기준이 아닙니다.⠀

결과 화면을 처음 열었다면 원 안의 점수보다 위쪽 영역의 LCP·INP·CLS 값을 먼저 봅니다.⠀

⠀⠀⠀

⠀⠀⠀

사진을 바꿨더니 점수만 올랐다⠀

⠀⠀⠀

Google Search Console의 Core Web Vitals 보고서도 CrUX 실사용자 데이터를 바탕으로 합니다.⠀

모바일과 데스크톱으로 나뉜 ‘개선 필요’·’나쁨’ URL 그룹에 사진이 많은 글이 몰려 있는지 훑어봅니다.⠀

모바일 쪽에만 그룹이 잡혀 있다면 그 글을 스마트폰으로 직접 열어 사진이 뜨는 모습을 봅니다.⠀

⠀⠀⠀

메인 화면은 멀쩡한데 그 그룹에 든 글 하나가 무겁게 열린다면 본문 사진의 용량을 미디어 라이브러리에서 살펴봅니다.⠀

다른 사진보다 용량이 눈에 띄게 큰 파일이 있다면 그 파일이 첫 후보가 될 수 있습니다.⠀

여러 장이 모두 크다면 글 첫머리에 놓인 사진부터 교체 후보로 둡니다.⠀

휴대폰 원본을 그대로 올린 사진이라면 WebP나 AVIF로 줄인 파일로 바꿔 올려 볼 수 있습니다.⠀

⠀⠀⠀

PageSpeed Insights에는 메인 주소 대신 그 글의 주소를 넣어 따로 잽니다.⠀

성능 점수는 측정 버튼을 누를 때마다 그 순간의 페이지로 새로 계산됩니다.⠀

사진을 바꾸고 다시 재면 아래쪽 점수는 곧바로 오를 수 있습니다.⠀

⠀⠀⠀

위쪽 실사용자 영역에는 사진을 바꾸기 전의 방문 기록이 아직 섞여 있어 같은 날에는 달라지지 않을 수 있습니다.⠀

사진을 바꾼 뒤의 방문이 쌓일수록 위쪽 값도 새 사진 기준의 기록으로 채워집니다.⠀

⠀⠀⠀

⠀⠀⠀

당일 비교는 점수 칸으로만⠀

⠀⠀⠀

느려졌다고 느낀 날짜를 떠올려 두고, 그 무렵 업데이트 날짜가 찍힌 플러그인을 목록에서 추려 봅니다.⠀

업데이트 날짜가 겹치는 플러그인이 없다면 그 무렵 새로 설치한 플러그인을 후보로 올립니다.⠀

사이트 전체를 백업해 둔 뒤 후보 가운데 하나만 비활성화하고 나머지는 그대로 둡니다.⠀

끄기 전에 PageSpeed Insights 성능 점수를 한 번 재 두고, 끈 직후 같은 주소로 다시 잽니다.⠀

⠀⠀⠀

이때 전후를 나란히 놓을 수 있는 숫자는 아래쪽 실험실 점수뿐입니다.⠀

위쪽 칸에는 아직 플러그인이 켜져 있던 날의 방문이 남아 있습니다.⠀

끈 당일 위쪽 값이 움직이지 않더라도 그 칸은 당일 비교 기준에서 빼 둡니다.⠀

⠀⠀⠀

GTmetrix는 무엇이 사이트를 느리게 하는지 구체적으로 짚어 보는 실험실 도구로 소개됩니다.⠀

GTmetrix 등급은 PageSpeed Insights 점수와 섞지 않고 끄기 전후의 GTmetrix 결과끼리만 나란히 놓습니다.⠀

⠀⠀⠀

두세 개를 한꺼번에 끄면 점수가 올라도 어느 플러그인의 몫인지 가려낼 수 없습니다.⠀

점수에 차이가 보였다면 그 플러그인은 꺼 둔 채 다음 날 한 번 더 재 봅니다.⠀

차이가 없다면 그 플러그인을 다시 켠 다음 목록의 다음 후보 하나로 넘어갑니다.⠀

⠀⠀⠀

⠀⠀⠀

잴 때마다 점수가 달라지는데 왜?⠀

⠀⠀⠀

같은 주소를 연달아 재도 성능 점수는 한 번의 실험실 측정으로 매겨져 매번 조금씩 흔들릴 수 있습니다.⠀

PageSpeed Insights와 GTmetrix, WebPageTest는 모두 실험실 쪽이지만 측정 위치와 조건이 도구마다 다릅니다.⠀

실험실 데이터는 통제된 환경에서 모아 원인을 찾는 데 쓸모가 있습니다.⠀

실제 환경의 병목은 놓칠 수 있어서 위쪽 실사용자 값과 결과가 다를 수 있습니다.⠀

⠀⠀⠀

위쪽 실사용자 영역은 여러 방문자의 기록을 p75로 묶은 값이라 한 번 잰 점수보다 덜 흔들립니다.⠀

서버 응답이 느린지 가늠할 때는 오르내리는 점수보다 이 위쪽 값을 기준으로 삼습니다.⠀

⠀⠀⠀

점수가 잴 때마다 달라도 위쪽 값까지 계속 나쁜 쪽에 머문다면 실제 방문자들도 같은 느림을 겪고 있을 수 있습니다.⠀

반대로 위쪽 값은 괜찮은데 점수만 오르내린다면 서버나 PHP 설정에는 손대지 않고 그대로 둡니다.⠀

⠀⠀⠀

WebPageTest는 Catchpoint가 지원하는 오픈소스 실험실 도구로, 느린 3G나 구형 기기 조건을 흉내 낼 수 있습니다.⠀

위쪽 값은 나쁜데 아래쪽 점수만 좋게 나온다면 WebPageTest에서 느린 3G 조건을 골라 같은 주소를 넣어 봅니다.⠀

느린 조건에서도 빠른 조건에서도 똑같이 늦게 열리기 시작한다면 서버 응답 쪽일 수도 있습니다.⠀

조건을 바꿔 재도 위쪽 값만큼 느리고 플러그인을 하나씩 꺼 봐도 차이가 없다면 그때 호스팅 업체에 문의합니다.⠀

⠀⠀⠀

⠀⠀⠀

순위는 점수를 보지 않는다⠀

⠀⠀⠀

점수가 낮게 나온 날에는 검색 순위까지 떨어질까 걱정됩니다.⠀

Google이 순위 신호로 쓰는 것은 원 안의 성능 점수가 아닙니다.⠀

순위 신호로 쓰이는 쪽은 화면 위쪽에 28일치로 쌓이는 CrUX 실사용자 데이터입니다.⠀

Lighthouse 점수와 GTmetrix 등급, WebPageTest 지표는 고칠 곳을 찾는 진단용이고 순위를 직접 정하지는 않습니다.⠀

⠀⠀⠀

Core Web Vitals의 ‘좋음’ 공식 기준은 LCP 2.5초 이하, INP 200ms 이하입니다.⠀

CLS는 0.1 이하가 기준이고, 세 지표 모두 p75 값에서 이 선을 넘지 않아야 통과로 봅니다.⠀

⠀⠀⠀

Site Kit은 Google이 만든 무료 워드프레스 플러그인입니다.⠀

Search Console과 PageSpeed Insights API를 대시보드에 이어 주니 관리자 화면에서 값을 열어 봅니다.⠀

⠀⠀⠀

기록표에는 성능 점수 칸과 실사용자 칸을 따로 나누고, 실사용자 칸에는 LCP·INP·CLS를 각각 적습니다.⠀

맨 앞 칸에는 측정 날짜를, 그 옆에는 그날 바꾼 사진이나 플러그인 이름을 적어 둡니다.⠀

GTmetrix 등급도 함께 본다면 점수 칸 옆에 한 칸을 따로 둡니다.⠀

⠀⠀⠀

Search Console에서 ‘나쁨’ 그룹에 든 글이 있다면 그 주소도 같은 날짜 줄에 옮겨 둡니다.⠀

개인적으로는 INP만 200ms를 넘는 사이트라면 기록표 실사용자 칸에서 INP 한 줄만 먼저 따라가도 된다고 봅니다.⠀

⠀⠀⠀

⠀⠀⠀

PageSpeed Insights의 실사용자 영역은 매일 갱신됩니다.⠀

기록표의 변경 날짜에서 28일이 지난 날, 같은 주소를 다시 넣어 위쪽 영역의 LCP·INP·CLS를 옮겨 적습니다.⠀

⠀⠀⠀