워드프레스가 가끔 느릴 때 원인 찾는 30분 점검법｜재현 기록표 포함

워드프레스 사이트가 항상 느린 것이 아니라 특정 시간이나 일부 페이지에서만 느리다면 캐시 플러그인을 바꾸는 것부터 시작하면 원인을 놓치기 쉽습니다. 간헐적인 문제는 느려진 순간의 조건을 기록하고 정상일 때와 비교해야 찾을 수 있습니다. 이 글에서는 별도 유료 도구 없이 30분 동안 시간, 주소, 사용자 상태, 요청 시간을 기록해 원인 범위를 줄이는 방법을 안내합니다.

이 글에서 얻을 수 있는 결과

• 느림을 재현할 수 있는 기록표를 직접 만들 수 있습니다.
• 브라우저 문제와 서버 문제를 먼저 구분할 수 있습니다.
• 플러그인을 무작정 중지하지 않고 의심 범위를 줄일 수 있습니다.
• 호스팅 업체에 전달할 구체적인 자료를 준비할 수 있습니다.

먼저 ‘느리다’를 한 문장으로 정의하기

“사이트가 느리다”만으로는 점검을 시작하기 어렵습니다. 방문자가 첫 화면을 기다리는지, 버튼 클릭 후 반응이 늦는지, 관리자 글 저장이 오래 걸리는지에 따라 확인할 위치가 다릅니다. 예를 들어 “로그인한 상태에서 오후 8시쯤 글 저장을 누르면 10초 이상 걸린다”처럼 조건과 행동, 결과가 포함된 문장으로 바꾸세요.

30분 재현 기록표

아래 항목을 정상 3회와 느린 상황 3회에 각각 기록합니다. 한 번의 결과만 보면 일시적인 통신 지연을 서버 장애로 오해할 수 있습니다. 같은 기기와 같은 네트워크에서 비교하고, 로그인 상태만 바꾸는 식으로 조건을 하나씩 변경하세요.

0~10분: 브라우저와 서버 문제 구분

1. 문제가 발생한 페이지를 일반 창과 시크릿 창에서 각각 엽니다.
2. 휴대전화 데이터 연결처럼 다른 네트워크에서도 한 번 확인합니다.
3. F12를 눌러 Network 패널을 열고 페이지를 새로고침합니다.
4. Document 요청의 Time과 Waiting 항목, 가장 오래 걸린 요청을 기록합니다.

시크릿 창에서만 정상이라면 확장 프로그램이나 브라우저 캐시를 먼저 의심할 수 있습니다. 모든 기기에서 HTML 문서의 대기 시간이 길다면 서버 처리, 데이터베이스 또는 외부 API 범위를 살펴봐야 합니다. 이미지 한 장만 늦다면 서버 전체보다 해당 이미지의 용량과 전송 경로를 확인하는 편이 빠릅니다.

10~20분: 로그인 상태와 페이지 범위 비교

20~30분: 워드프레스 정보와 기록 대조

관리자 화면의 도구 → 사이트 건강에서 상태와 정보 탭을 확인합니다. 서버의 PHP 버전, 메모리 제한, 활성 플러그인, 데이터베이스 정보는 호스팅 문의에 필요한 기본 자료입니다. 경고가 있다고 모두 속도 원인은 아니므로 기록표의 발생 시간과 증상에 맞는 항목부터 확인하세요.

오류 로그가 필요하다면 운영 사이트에서 방문자에게 오류를 표시하지 말고 스테이징 환경이나 호스팅 기능을 이용하는 것이 안전합니다. 워드프레스 공식 문서도 디버깅 기능을 사용하기 전에 백업 또는 스테이징 환경을 준비하고, 운영 환경에서 디버그 표시를 계속 켜 두지 않도록 안내합니다.

점검 결과별 다음 행동

• 서버 대기만 길다: 발생 시각과 URL, 로그인 여부를 호스팅 업체에 전달하고 CPU·메모리·느린 쿼리 기록을 요청합니다.
• 외부 요청이 길다: 요청 도메인과 기능을 확인한 뒤 필요한 페이지에서만 불러오거나 지연 로딩을 검토합니다.
• 특정 플러그인 기능만 느리다: 운영 사이트에서 바로 삭제하지 말고 스테이징에서 동일 조건으로 재현합니다.
• 정해진 시간에 반복된다: 백업, 보안 검사, WP-Cron 작업 시간이 겹치는지 확인해 실행 시간을 분산합니다.
• 이미지만 늦다: 원본 크기와 표시 크기를 비교하고 WebP·AVIF 변환 및 CDN 캐시 상태를 확인합니다.

호스팅 문의에 그대로 쓸 수 있는 양식

발생 시각: 2026-08-23 20:10 KST
문제 URL: https://example.com/sample/
사용자 상태: 로그인하지 않음
재현 횟수: 3회 중 3회
증상: HTML 문서의 첫 응답 대기 시간이 평균 4.2초
정상 비교: 오전 10시에는 평균 0.8초
확인 요청: 해당 시간의 PHP 처리, CPU·메모리 사용량과 느린 데이터베이스 쿼리 확인 부탁드립니다.

(adsbygoogle = window.adsbygoogle || []).push({});

Network 기록에서 문서 응답은 빠르지만 화면 작업이 길다면 프론트엔드 Waterfall·Main Thread 진단으로 이어가세요. 관리자 요청에서 admin-ajax.php가 반복되면 admin-ajax.php action별 진단, 특정 플러그인 화면에서만 느리면 Query Monitor 플러그인 진단으로 범위를 좁힐 수 있습니다.

TIP

플러그인을 여러 개 동시에 끄거나 캐시·CDN·PHP 버전을 한 번에 바꾸면 무엇이 효과가 있었는지 알 수 없습니다. 한 번에 한 항목만 변경하고, 변경 전후를 같은 URL과 같은 로그인 상태에서 3회씩 비교하세요. 결과가 좋아져도 결제·로그인·글 저장 같은 핵심 기능 테스트까지 마친 뒤 적용을 유지해야 합니다.

자주 묻는 질문

PageSpeed 점수만 확인하면 되나요?

점수는 개선 방향을 찾는 참고 자료지만 간헐적인 서버 지연의 발생 시간과 조건을 대신 기록해 주지는 않습니다. 실제 문제가 생긴 순간의 Network 요청과 서버 자료를 함께 봐야 합니다.

캐시를 지우면 잠시 빨라지는 이유는 무엇인가요?

오래된 파일이나 설정 충돌이 해소될 수도 있지만, 캐시를 다시 만드는 동안 오히려 느려질 수도 있습니다. 삭제 전후 조건과 시간을 기록해야 원인을 구분할 수 있습니다.

호스팅 업체에 무엇을 보내야 하나요?

정확한 발생 시각, URL, 로그인 여부, 재현 횟수, 오류 코드, 정상일 때와 느릴 때의 대기 시간을 보내세요. “가끔 느리다”보다 서버 기록을 찾는 데 훨씬 유용합니다.

이 글의 점검 기준과 참고 자료

이 글은 워드프레스 공식 사이트 건강 안내, 디버깅 안내, Chrome 공식 Network 패널 문서에서 일반 사용자가 직접 확인할 수 있는 항목을 기준으로 구성했습니다. 특정 플러그인 구매나 호스팅 상품 가입을 전제로 하지 않습니다.

마무리

워드프레스가 가끔 느릴 때 가장 먼저 필요한 것은 새로운 플러그인이 아니라 재현 가능한 기록입니다. 30분 동안 정상과 느린 상황을 같은 조건으로 비교하고, 브라우저·페이지·로그인·발생 시간 순서로 범위를 줄이세요. 기록표와 문의 양식을 사용하면 추측성 설정 변경을 줄이고 실제 원인을 해결할 가능성을 높일 수 있습니다.