워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것

잘 열리던 사이트라도 첫 화면만 유독 느려지는 순간이 있습니다⠀

새로고침을 여러 번 눌러 봐도 체감은 그대로여서, 감으로 판단하기보다⠀

LCP라는 지표부터 화면에서 직접 짚어 보게 됩니다⠀

⠀⠀⠀

⠀⠀⠀

새로고침 대신 봐야 할 숫자가 따로 있다⠀

⠀⠀⠀

⠀⠀⠀

⠀⠀⠀

첫 화면이 얼마나 늦는지는 체감이 아니라⠀

LCP, Largest Contentful Paint라는 지표로 잡습니다⠀

첫 화면에서 가장 큰 요소, 대개 상단 이미지나 큰 제목이⠀

언제 그려지는지를 재는 값입니다⠀

web.dev는 이 LCP의 좋음 기준을 2.5초 이하로 두고 있습니다⠀

이 기준선 하나만 알아 둬도, 지금 느낌이 아니라⠀

숫자로 판단할 근거가 생깁니다⠀

⠀⠀⠀

모바일 점수는 좋은데 데스크톱은 다르게 나온다⠀

⠀⠀⠀

Google PageSpeed Insights는 구글이 만든 무료 진단 도구입니다⠀

페이지 주소를 넣고 분석을 누르면 LCP를 포함한 지표가 나옵니다⠀

web.dev는 모바일과 데스크톱을 나눠 측정하라고 안내합니다⠀

같은 사이트라도 두 환경의 LCP가 다르게 나올 수 있어서⠀

모바일 탭의 LCP와 데스크톱 탭의 LCP를 각각 확인하고⠀

둘 다 2.5초와 나란히 놓고 봅니다⠀

⠀⠀⠀

볼 때마다 값이 다른데 어느 걸 믿어야 하나⠀

⠀⠀⠀

같은 페이지를 다시 측정하면 LCP 값이 조금씩 바뀌곤 합니다⠀

기준으로 삼는 값은 페이지 로드 전체의 75번째 백분위수입니다⠀

방문 100번 중 75번째에 해당하는 값을 본다는 뜻입니다⠀

이 p75 값이 2.5초 이하면 좋음으로 분류되고⠀

그렇지 않으면 개선이 필요함이나 나쁨 구간으로 갈립니다⠀

한 번 측정한 순간값보다 이 p75 칸을 기준으로 둡니다⠀

⠀⠀⠀

이미지를 줄여도 안 빨라지는 이유가 여기 있었다⠀

⠀⠀⠀

LCP에는 이전 페이지 언로드, 연결 설정, 리디렉션, 그리고⠀

TTFB, 서버 응답을 기다리는 시간까지 이미 포함돼 있습니다⠀

사진을 아무리 줄여도 이 앞단이 늦으면 2.5초를 맞추기 어렵습니다⠀

web.dev 검색 결과에서는 LCP가 나쁜 출처의 절반 이상에서⠀

p75 TTFB가 2,270ms로 나타났고⠀

이 값 하나만으로도 2.5초 기준을 넘기기 쉬운 구조였습니다⠀

워드프레스는 요청마다 PHP와 DB로 페이지를 새로 만들기 때문에⠀

페이지 캐시가 없거나 호스팅이 약하면 TTFB가 늘어날 수 있습니다⠀

반대로 서버 응답이 정상인데 LCP만 늦다면⠀

상단 이미지가 지연 로딩으로 걸려 있는지도 함께 봅니다⠀

LCP 요소인 이미지는 지연 로딩에서 빼고⠀

fetchpriority가 high로 붙어 있는지 확인하는 편입니다⠀

개인적으로는 이미지 용량부터 줄이고 보는 순서보다⠀

TTFB 숫자를 먼저 열어 보는 쪽이 헛짚을 일이 적다고 봅니다⠀

⠀⠀⠀

손대기 전에 적어 둬야 나중에 비교가 된다⠀

⠀⠀⠀

설정을 바꾸기 전, 지금 화면의 숫자를 먼저 적어 둡니다⠀

모바일 LCP의 p75 값, 데스크톱 LCP의 p75 값⠀

그리고 같은 화면에 뜨는 TTFB 값까지 세 가지입니다⠀

캐시 플러그인을 새로 켜거나 이미지를 손보고 나면⠀

같은 페이지, 같은 탭에서 다시 측정해 나란히 놓고 봅니다⠀

플러그인을 한 번에 여러 개 끄기보다⠀

백업해 둔 뒤 느려진 시점 무렵 업데이트된 것 하나만 꺼 봅니다⠀

이렇게 바꾸고 재는 순서를 한 번 거쳐 두면⠀

다음에 값이 달라졌을 때 무엇 때문인지 짚을 실마리가 남습니다⠀

⠀⠀⠀

적어 둔 표에서 TTFB 칸이 가장 먼저 눈에 들어온다면⠀

호스팅 관리자 화면에서 PHP 워커 수나 캐시 설정 항목부터⠀

열어 보는 것이 다음 순서가 됩니다⠀