워드프레스가 느릴 때: CDN 도입 전 병목부터 찾는 법

Read in English

워드프레스가 느리다면 HTML 응답을 기다리는 구간과 응답 후 화면이 그려지는 구간부터 나눠 확인한다. HTML 생성이 병목이면 페이지 캐시를, 이미지나 글자가 늦게 보이면 관련 파일과 브라우저 작업을 조사한다. CDN은 방문 지역·반복 요청·비용을 확인한 뒤 도입 여부를 판단한다.

첫 점검에서는 비로그인 홈과 대표 글을 PC·모바일로 나눠 측정하고, 다음에 시험할 변경 하나를 고르면 된다. 아래 판단표부터 보고 필요한 측정 방법으로 이어갈 수 있도록 구성했다.

느리다는 느낌을 두 질문으로 나눈다

설정 변경에 앞서 내가 구분하려는 것은 두 가지다. 페이지 응답이 시작되기까지 오래 기다리는가, 아니면 응답을 받기 시작한 뒤 중요한 내용이 늦게 보이는가.

첫 응답까지의 시간을 보는 지표가 TTFB(Time to First Byte)다. 페이지 탐색을 시작한 뒤 첫 바이트가 도착할 때까지의 시간으로, 서버 처리 외에도 리디렉션·주소 조회·연결 설정 등의 영향이 포함될 수 있다. TTFB가 길다고 곧바로 DB나 서버 사양이 원인이라고 단정할 수는 없다. TTFB 설명

실제로 중요한 내용이 언제 보이는지는 LCP(Largest Contentful Paint)로 살펴본다. 처음 보이는 화면 안에서 가장 큰 이미지나 텍스트 영역이 표시되는 시점이다. 대표 이미지일 수도 있고 제목 같은 텍스트일 수도 있다. 어떤 요소가 LCP인지부터 봐야 손댈 파일을 고를 수 있다. LCP 설명

HTML 첫 응답까지의 시간

알려주는 내용응답을 시작하기까지 지연이 있는지

이 값만으로 알 수 없는 것PHP·DB·네트워크 중 무엇이 원인인지

LCP와 해당 요소

알려주는 내용큰 이미지나 본문·제목이 언제 표시되는지

이 값만으로 알 수 없는 것그 요소만 수정하면 전체 문제가 해결되는지

실제 요청 목록과 전송량

알려주는 내용어떤 파일과 외부 요청이 내려왔는지

이 값만으로 알 수 없는 것받은 파일이 화면 표시를 얼마나 늦췄는지

이 첫 점검만으로 사이트의 모든 성능을 평가하는 것은 아니다. 버튼 반응이나 스크롤 중 끊김은 별도 상호작용 측정이 필요하다. 우선 첫 화면이 늦어지는 위치부터 좁힌다.

기록한 결과로 다음 변경을 고른다

아래 표는 실제 측정값을 넣은 결과표가 아니라, 관찰한 현상에 따라 다음 시험을 고르는 기준이다. 첫 편에서는 모든 항목을 고치려 하지 않고 가장 의심되는 한 구간을 선택한다.

HTML 응답 시작이 반복해서 늦다

먼저 확인할 후보리디렉션·연결 지연·서버 부하·PHP·DB·페이지 캐시 여부

다음 조치·유지 판단HTML 전달 경로를 더 조사한다. 서버 처리 지연이 확인되면 페이지 캐시나 해당 처리의 개선을 시험한다. CDN부터 추가하지 않는다.

HTML은 빨리 오지만 LCP 이미지가 늦다

먼저 확인할 후보이미지 크기·형식·발견 시점·불필요한 지연 로딩

다음 조치·유지 판단해당 이미지 하나의 전송과 표시를 먼저 개선해 비교한다.

큰 텍스트가 늦게 보인다

먼저 확인할 후보폰트 요청·CSS 차단·텍스트 렌더링

다음 조치·유지 판단관련 폰트와 CSS를 조사한다. 파일 개수를 줄였다는 이유만으로 성공 처리하지 않는다.

파일은 받았는데 화면 표시나 반응이 늦다

먼저 확인할 후보긴 JavaScript 작업·렌더링 지연

다음 조치·유지 판단Performance 기록에서 스크립트 실행과 화면 작업을 맡는 브라우저의 주 작업 흐름(메인 스레드)을 확인하고 관련 스크립트를 좁힌다.

두 번째 방문만 빠르다

먼저 확인할 후보브라우저 캐시와 서버 캐시 상태

다음 조치·유지 판단첫 방문과 재방문을 따로 비교한다. 지금 구성을 바꾸기 전에 어느 캐시가 효과를 내는지 확인한다.

응답·표시가 사용 목적에 충분하고 반복 측정도 안정적이다

먼저 확인할 후보실제 휴대폰의 읽기·메뉴·검색·앱 동작

다음 조치·유지 판단현재 구성을 유지할 수 있다. 설정을 더 늘리는 것을 목표로 삼지 않는다.

개선 시험은 백업과 복귀 방법을 준비한 테스트 환경에서 시작한다. 바꿀 항목을 한 가지로 좁히면 전후 차이를 해석하기가 쉽다. 운영 페이지의 광고·로그인·앱 기능을 끄고 얻은 결과를 그대로 독자 화면의 개선이라고 보고하지 않는다.

같은 조건으로 비교할 준비를 한다

내가 보고 있는 화면과 독자가 보는 화면이 다르면 결과도 달라진다. 관리자 로그인 화면 대신 비로그인 공개 화면을 기준으로 삼고, 홈과 대표 글 한 편을 고른다. 상품·앱처럼 동작이 다른 페이지는 따로 측정한다.

주소는 페이지의 대표 주소인 정규 URL을 쓴다. 지금 사용 중인 기능과 요청 조건도 다음처럼 기록한다.

페이지

적어 둘 내용정규 URL, 홈인지 일반 글인지

요청 조건

적어 둘 내용비로그인 여부, PC·모바일 구분, 측정 도구와 시각

전달 구성

적어 둘 내용서버·호스팅, 페이지 캐시, CDN·프록시 사용 여부

브라우저 조건

적어 둘 내용브라우저 버전, 캐시 사용 여부, 회선·CPU 제한 설정

외부 요소

적어 둘 내용광고·분석·동영상·외부 폰트 등이 표시됐는지

PC와 모바일은 나눠 기록한다. 서로 다른 도구의 결과를 같은 조건의 전후 비교처럼 합치지도 않는다. 변경 전 기록을 저장한 뒤에 개선안을 시험해야 무엇이 달라졌는지 볼 수 있다.

PageSpeed에서는 점수보다 늦은 요소를 먼저 찾는다

첫 자료는 PageSpeed Insights에서 얻을 수 있다. 정규 URL을 입력하고 모바일과 데스크톱 보고서를 각각 저장한다. 성능 점수와 함께 LCP 수치, LCP 대상 요소, 관련 진단 항목을 본다.

이 화면에는 실제 방문자의 경험을 모은 데이터와 페이지를 시험 조건에서 실행하는 Lighthouse가 생성한 실험실 데이터가 함께 나올 수 있다. 실제 사용자 데이터가 없다고 사이트가 빠르다는 뜻은 아니며, 시험 결과 한 번이 모든 방문자의 경험을 뜻하지도 않는다. PageSpeed 데이터 구분

같은 옵션으로 여러 번 실행해 결과가 얼마나 흔들리는지 본다. 세 번 실행했다면 값을 크기순으로 놓았을 때 가운데인 중앙값과 최소·최대값을 함께 적을 수 있다. 세 번만으로 충분한 통계가 되지는 않지만, 가장 잘 나온 한 번만 골라 쓰는 일은 피할 수 있다. 광고·서버 부하·측정 위치 등에 따라 값은 달라질 수 있다. Lighthouse 점수의 변동

LCP 대상이 무엇인지 찾기 어렵다면 내 브라우저에서도 확인할 수 있다. 다만 이 실행은 PageSpeed 보고서와 다른 측정이다.

1. Chrome에서 확인할 페이지를 연다. Windows/Linux는 Ctrl+Shift+I, Mac은 Command+Option+I로 개발자 도구를 열고 Performance(성능) 탭을 선택한다.
2. 탭을 연 채 페이지를 새로 불러온다. Live metrics(실시간 지표)에 표시되는 LCP element를 찾는다.
3. 그 요소 표시 위에 마우스를 올려 페이지의 어느 이미지나 텍스트가 강조되는지 확인하고 기록한다. 브라우저 버전·화면 크기·측정 시점에 따라 요소가 달라질 수 있다. LCP 요소 확인 방법

보고서에서 이미지 전송이 크다고 해도 지금 늦게 보이는 요소가 제목이라면 폰트나 CSS도 살펴야 한다. 진단 목록을 위에서부터 무조건 적용하기보다, 실제 LCP 요소와 요청 흐름에 맞춰 후보를 고른다.

브라우저에서 HTML과 파일 요청을 나눠 본다

보고서로 후보를 찾았다면, 내 브라우저에서 어떤 요청이 일어나는지 확인한다. Chrome이나 Edge의 개발자 도구에서 Network(네트워크)를 열고 페이지를 다시 불러온다. 먼저 현재 캐시 설정과 회선 제한 상태를 기록한다.

1. 목록에서 페이지 주소에 해당하는 Document 요청을 고른다. 주소를 바꾸는 리디렉션이 있는지도 살핀다.
2. Timing(시간)에서 연결과 응답 대기 구간을 본다. Waiting for server response가 길면 서버 응답을 기다리는 구간을 더 조사할 근거가 된다. 다만 이 구간에도 네트워크 영향이 있어 PHP 처리시간으로 그대로 읽을 수는 없다.
3. CSS·JS·이미지·폰트 요청을 나눠 본다. 요청 주소, 크기, 오래 걸린 파일과 시작 시점을 확인한다.
4. 이미지라면 실제 선택된 파일이 지나치게 크지 않은지, 텍스트가 늦게 보인다면 관련 폰트와 CSS가 언제 도착했는지 본다. 이 목록만으로 원인을 확정하지 않고 Performance 기록 등으로 화면 표시와 연결해 확인한다.

Network의 Waiting 구간과 페이지 탐색 전체의 TTFB는 범위가 같지 않다. 또 PageSpeed의 시험 회선과 내 PC 회선은 다르므로, 그 LCP에서 내 브라우저의 대기시간을 빼서 처리시간을 계산하지 않는다. Network 시간과 캐시 표시

브라우저 캐시의 영향을 분리해 보고 싶다면 Disable cache를 켠 실행을 별도로 기록한다. 이 옵션은 개발자 도구가 열린 동안 브라우저의 HTTP 캐시 사용을 막는 용도다. 서버의 페이지 캐시나 CDN 캐시까지 비워 주지는 않는다. 평소 캐시를 사용하는 결과와 섞어 비교하지 않는다.

HTML이 만들어지는 과정

홈 주소를 열면 브라우저는 글의 내용과 구조가 담긴 HTML 문서를 요청한다. 완성된 HTML 사본을 보관했다가 다시 제공하는 기능을 페이지 캐시라고 한다. 우선 이 캐시가 없는 기본 구성을 생각해 보자. 웹 서버가 요청을 받아 WordPress 코드를 실행하는 PHP로 처리를 넘기면, WordPress는 필요한 데이터베이스(DB) 정보를 조회해 HTML을 만든다. 웹 서버는 그 결과를 브라우저에 돌려준다.

호스팅에서 이미 페이지 캐시를 제공한다면 이 과정 일부를 건너뛸 수 있으므로, 내 환경에 있는 캐시부터 적어 둔다.

브라우저는 HTML을 읽으면서 화면 스타일을 정하는 CSS, 동작을 추가하는 JavaScript(JS), 이미지·폰트를 발견해 요청한다. 내용을 매번 새로 만들지 않고 저장된 그대로 제공하는 파일을 정적 파일이라고 한다. 같은 서버의 CSS·JS·이미지·폰트는 보통 PHP와 DB를 거치지 않고 웹 서버가 제공한다. 외부 광고나 분석 도구가 있다면 그 서비스로도 별도 요청이 생긴다. 파일을 받은 뒤에도 브라우저가 CSS를 적용하고 JavaScript를 실행하며 화면을 그리는 과정인 렌더링(rendering)에도 시간이 필요하다.

이 그림은 CDN이 없는 사이트를 설명하기 위한 기본 모델이다. 내 운영 사이트에서 CDN을 제거해 측정한 결과는 아니다. 이미 CDN·요청을 중계하는 프록시·캐시를 쓰고 있다면 우선 켜 둔 상태를 기록한다. 비교 기준을 만들기 위해 운영 구성을 갑자기 끌 필요는 없다.

내 폰트 사례에서 놓쳤던 점

내 사이트는 이미 CDN과 최적화 도구를 쓰고 있었다. 따라서 이 결과를 CDN 없는 기본 구성의 성능으로 볼 수는 없다. 여기서 가져올 교훈은 파일 용량과 화면 표시 결과를 따로 확인해야 한다는 점이다.

폰트 묶음을 줄인 뒤에도 공개 HTML에는 이전 폰트의 선로딩 24개가 남아 있었다. 이를 제거하기 전의 단일 모바일 Lighthouse 실험실 결과는 54점·LCP 19.582초였고, 수정 후 단일 결과는 91점·LCP 2.853초였다. 같은 조건의 반복 전후 측정을 확보한 것은 아니며, 최초 폰트 최적화 이전의 PageSpeed 비교값도 없었다. 지속적인 개선 폭으로 일반화할 수 없는 이유다. 당시 폰트·선로딩 수정 기록

수정 전: 모바일 54점

수정 후: 모바일 91점

두 화면은 CDN과 최적화 도구가 있던 운영 환경의 과거 단일 측정이다. CDN 없는 기본 구성의 기준값이나 동일 조건의 반복 전후 시험이 아니다. 화면의 요약 영역만 보여 주며 전체 자료는 원본 링크에서 열 수 있다. 당시 사례와 측정 한계

이후에는 캐시가 생성됐는지와 별개로 공개 응답의 실제 요청 목록을 확인했다. 지금 새로 성능 개선을 시작한다면, 나는 이런 기준 자료부터 남기겠다.

첫 점검이 끝났을 때 남길 것

홈과 대표 글의 주소, PC·모바일 보고서, 요청 조건, 느린 구간의 캡처를 모은다. 다음 양식을 페이지·도구·PC/모바일별로 따로 채우면 조건이 다른 숫자를 섞지 않고 다음 변경을 고를 수 있다.

페이지 URL:
측정 날짜·시각:
도구·버전 / PC·모바일:
로그인 / 브라우저 캐시 / 서버 캐시·CDN 상태:
회선·CPU 제한 / 외부 광고 등 표시 여부:
각 실행의 수치와 보고서 링크:
TTFB(측정한 도구와 범위):
Network Waiting(별도 브라우저 측정이면 따로 기록):
LCP 시간·대상 요소(동일 실행 기준):
중앙값·최소/최대(동일 조건의 반복 결과):
관찰한 느린 구간과 증거:
다음에 시험할 변경 한 가지:
성공 기준 / 기능 확인 항목:
복귀 방법:

예를 들어 HTML 대기가 문제라면 같은 조건에서 대기 구간이 줄고 페이지 내용이 정상인지 본다. 폰트나 이미지가 문제라면 실제 받은 파일과 LCP 요소의 표시를 확인한다. 빠르게 나왔더라도 메뉴·검색·글자·코드·이미지가 깨지면 적용을 멈추고 복구한다.

다음 편에서는 HTML 응답을 만드는 비용이 클 때 페이지 캐시가 무엇을 줄이는지 살펴볼 예정이다. 측정상 그 구간이 문제가 아니라면 파일 전송·렌더링 쪽을 먼저 조사해도 된다. CDN 도입은 그 뒤에 방문 지역·반복 요청·비용을 보고 판단한다.

함께 읽기

• 폰트 선로딩 수정 사례
• OCI WAAS 정적 파일 캐시 사례