플러그인 업데이트 후 사이트가 느려지는 이유
플러그인 업데이트 알림이 떠서 눌렀는데 그 직후부터 관리자 화면이 전보다 느리게 넘어간다면 이게 실제로 느려진 건지 눈으로만 가를 수는 없습니다
먼저 관리자 화면만 느린지, 방문자가 보는 공개 페이지도 느린지 나눠 봅니다 업데이트 전에도 로그인 사용자가 페이지 캐시에서 제외됐다면 그 설정만으로 갑자기 느려진 이유를 설명할 수는 없습니다 같은 주소의 응답 시간과 캐시 상태를 비교하고, 업데이트한 플러그인을 하나씩 껐다 켰을 때 차이가 반복되는지 봐야 원인 후보가 좁혀집니다
로그인 화면이 느린 게 방문자도 느리다는 뜻은 아니다
관리자 화면에서만 느려짐을 느낀다면 일반 방문자가 보는 화면도 함께 살펴봐야 합니다 이 화면은 일반 방문자가 보는 화면과 같은 조건이 아닙니다
사이트에 캐시를 걸어 둔 경우 로그인 사용자를 제외하는 정책은 주로 완성된 HTML을 재사용하는 페이지 캐시에서 살펴볼 부분입니다 관리자 화면이나 로그인한 공개 페이지가 이 캐시에서 제외되면 요청마다 워드프레스가 화면을 새로 처리할 수 있습니다 다만 로그인했다는 이유로 모든 캐시가 빠지는 것은 아닙니다
WordPress 캐시 문서는 페이지를 정적 파일로 제공하는 캐시와 데이터 조회 결과를 재사용하는 오브젝트 캐시를 구분합니다 오브젝트 캐시는 로그인 여부와 무관하게 쓰일 수 있고, CDN의 이미지·CSS·JavaScript 같은 정적 파일 캐시도 비로그인 방문자 전용이 아닙니다 서버 캐시 역시 어떤 결과를 저장하는지부터 구분해야 합니다
로그인한 공개 페이지를 캐시하는 제품도 있습니다 예를 들어 WP Rocket 사용자 캐시 문서는 로그인 사용자별 캐시 파일을 만드는 기능을 설명합니다 이것이 관리자 화면까지 캐시한다는 뜻은 아닙니다 사용하는 제품의 로그인 사용자 정책과 제외 주소를 확인해야 하며, 개인 정보가 있는 화면을 빠르게 만들겠다고 캐시 제외를 무작정 풀어서는 안 됩니다
방문자는 여전히 페이지 캐시를 받아 빠르게 보고 있는데 운영자만 캐시가 빠진 화면을 보며 느려졌다고 판단하는 경우가 생길 수 있습니다 하지만 업데이트 전부터 같은 우회 정책이었다면 새로 늘어난 처리 시간이나 바뀐 캐시 설정을 따로 찾아야 합니다 캐시 우회는 두 화면의 차이를 설명하는 조건이지, 업데이트 직후 느려진 원인을 확정하는 근거는 아닙니다
캐시가 빠진 것과 플러그인이 무거워진 것은 다른 문제다
관리자 화면이 페이지 캐시에서 제외되고 일반 방문자는 캐시에 적중한다면 두 화면의 속도는 다를 수 있습니다 하지만 업데이트된 플러그인 자체가 무거워졌거나 다른 플러그인과 기능이 겹치게 됐다면 이야기가 달라집니다 무겁거나 관리가 안 되는 플러그인, 비슷한 일을 하는 플러그인 간의 중복은 서버가 처리해야 할 코드 실행량 자체를 늘릴 수 있습니다 이 경우도 완성된 HTML을 페이지 캐시에서 제공하는 요청은 플러그인의 서버 처리를 우회할 수 있어 방문자 화면이 반드시 함께 느려지는 것은 아닙니다
두 경우를 가르는 첫 지점은 로그인 여부입니다 같은 공개 페이지를 로그인하지 않은 상태나 시크릿창으로 열어 보면 방문자 쪽에도 지연이 있는지 살펴볼 수 있습니다 다만 로그아웃 상태가 빠르다고 관리자 전용 문제로 확정할 수는 없습니다 페이지 캐시가 플러그인의 늘어난 처리 시간을 가리고 있을 수 있고, 로그인 사용자에게만 추가되는 기능도 있기 때문입니다
| 나눠 볼 조건 | 결과를 읽는 방법 | 다음에 볼 부분 |
|---|---|---|
| 관리자 화면만 느리고 공개 페이지는 캐시 미적중에서도 빠릅니다 | 관리자 전용 처리나 화면 요청이 원인 후보입니다 | 느린 관리자 주소의 문서 요청과 Fetch/XHR 요청 |
| 공개 페이지의 캐시 적중 요청은 빠르고 미적중 요청은 느립니다 | 페이지 캐시가 서버 처리 지연을 가리고 있을 수 있습니다 | 같은 미적중 조건에서 플러그인 변경 전후 비교 |
| 비로그인 캐시 미적중 요청도 느립니다 | 로그인 사용자 제외 정책만으로 설명하기 어렵습니다 | 플러그인 처리, 외부 호출, 서버 대기 상태 |
| 문서 응답은 비슷한데 화면이 늦게 완성됩니다 | 서버 응답 이후의 파일 다운로드나 화면 처리도 봐야 합니다 | 추가된 스크립트·스타일·이미지 요청과 실행 시간 |
업데이트한 플러그인이 많다면 그 플러그인들의 변경 내역에서 쿼리나 외부 호출이 추가됐다는 안내가 있는지 플러그인 화면에서 한 번 열어 보는 것도 참고가 됩니다
관리자 메뉴의 플러그인 → 설치한 플러그인에서 현재 버전을 적고 상세 정보나 개발자의 공식 변경 내역을 엽니다 이전 버전은 업데이트 전 기록이나 백업 정보에서 확인합니다 변경 내역에 성능 관련 설명이 없더라도 영향이 없다고 단정하지는 않습니다 실제로 느린 요청과 변경 전후 차이가 함께 있어야 판단에 도움이 됩니다
개인적으로는 로그인 화면만 보고 바로 플러그인을 지우기보다, 방문자가 실제로 받는 화면이 느려졌는지부터 가르는 쪽이 헛걸음을 줄인다고 봅니다
로그아웃해서 다시 보고, 그래도 느리면 하나씩 꺼본다
가장 먼저 할 일은 느린 관리자 화면과 별도로 공개 게시글 주소 하나를 정해 로그아웃 상태나 시크릿창에서 다시 열어 보는 것입니다 같은 공개 페이지에서 로그인 상태와 로그아웃 상태의 응답 시간을 비교하면 점검 방향이 갈립니다 관리자 화면은 로그아웃하면 같은 화면을 볼 수 없으므로 로그인 상태를 유지한 채 따로 비교합니다 비활성화는 그 플러그인이 제공하던 기능이 방문자 화면에서 잠시 멈춘다는 뜻이므로 운영 중인 사이트라면 사람이 적은 시간대에 확인하는 쪽이 안전합니다
체감만 적어 두면 다시 확인할 때 기준이 흔들립니다 크롬에서는 개발자 도구의 Network를 열고 같은 주소를 새로고침한 뒤, 유형이 document인 문서 요청을 선택합니다 Timing의 Waiting for server response가 TTFB를 살펴보는 항목입니다 이 값에는 네트워크 왕복과 서버가 응답을 준비하는 시간이 함께 들어가므로 PHP 실행 시간만을 뜻하지는 않습니다 전체 요청 시간도 함께 적어 두면 응답을 기다린 시간과 내려받는 시간을 나눠 볼 수 있습니다 항목 설명은 크롬 Network 공식 문서에서 확인할 수 있습니다
- 공개 URL과 관리자 URL을 각각 하나씩 정합니다 같은 브라우저·네트워크를 쓰고 Network의 속도 제한은 No throttling으로 맞춥니다 로그인 비교에서는 계정도 그대로 둡니다
- 개발자 도구가 열린 동안 Disable cache를 켜 브라우저 캐시 영향을 줄입니다 이 설정이 CDN이나 서버의 페이지 캐시까지 비우는 것은 아닙니다 강력 새로고침이나 임의의 주소 매개변수로 캐시를 우회하려 하면 요청 조건도 달라질 수 있으므로 같은 방식의 일반 새로고침을 유지합니다
- 문서 요청의 Headers에서 응답 헤더를 살펴봅니다 제품이 제공하는 X-Cache나 CF-Cache-Status 같은 표시가 있다면 HIT·MISS·BYPASS를 그대로 적습니다 이름과 의미는 제품에 따라 다르며, 표시가 없으면 속도만 보고 적중으로 판단하지 말고 캐시 제품의 로그나 호스팅 확인 기능을 봅니다
- 조건별로 3회 이상 측정하고 TTFB와 전체 시간을 적습니다 캐시 적중과 미적중 결과를 섞어 평균 내지 않고 나눠 비교합니다 한 번만 느렸다면 반복되는 차이인지부터 다시 봅니다
관리자 화면만 느리다면 같은 관리자 주소를 같은 계정으로 다시 엽니다 문서 요청의 대기 시간이 늘었는지 먼저 보고, 문서는 빨리 왔는데 목록이나 편집 화면이 늦게 뜬다면 Fetch/XHR로 좁혀 오래 걸리는 요청과 주소를 적습니다 예를 들어 admin-ajax.php나 REST API 요청이 늦는지 보는 방식입니다 상태 코드가 200이어도 응답이 늦을 수 있고, 대기 중이거나 실패한 요청도 함께 살펴봐야 합니다
업데이트 전 기록이 있다면 같은 URL·계정·캐시 상태끼리 비교합니다 기록이 없다면 지금의 로그인·로그아웃 차이를 업데이트 전후 차이처럼 쓰지는 않습니다 테스트용 복제 사이트에서 이전 버전과 현재 버전을 같은 데이터와 설정으로 비교할 수 있을 때 확인하고, 운영 사이트를 이전 버전으로 바꾸는 일을 첫 점검으로 삼지는 않습니다
| 비교 조건 | 플러그인 버전 | 로그인·페이지 캐시 | TTFB 3회 | 중앙값 |
|---|---|---|---|---|
| 업데이트 전 | 버전 A | 비로그인·MISS | 420 / 460 / 440 ms | 440 ms |
| 업데이트 후 | 버전 B | 비로그인·MISS | 980 / 1,040 / 1,010 ms | 1,010 ms |
| 업데이트 후 캐시 적중 | 버전 B | 비로그인·HIT | 110 / 130 / 120 ms | 120 ms |
この 예시처럼 캐시 적중 요청만 빠르다면 방문자가 지금 빠르게 본다는 사실과 새로 페이지를 만드는 처리가 느려졌다는 가능성이 함께 남습니다 숫자 자체를 합격 기준으로 쓰기보다 같은 조건에서 차이가 반복되는지를 보는 데 의미가 있습니다
그다음은 방금 업데이트한 플러그인을 하나씩 비활성화해 비교할 차례입니다 공개 페이지가 느린 경우에는 그 공개 URL을, 관리자 화면만 느린 경우에는 앞에서 적어 둔 관리자 URL과 느린 요청을 다시 봅니다 결제나 로그인처럼 핵심 기능을 맡은 플러그인은 테스트용 복제 사이트에서 확인하는 편이 낫습니다
- 현재 활성 상태에서 먼저 기록합니다 여러 플러그인을 업데이트했어도 비교할 때는 하나만 비활성화하고 나머지 설정은 그대로 둡니다 플러그인을 끄면 비교할 화면 자체가 없어지는 경우에는 같은 작업을 비교할 수 없다는 점도 남깁니다
- 공개 페이지는 변경된 HTML이나 최적화 파일이 이전 캐시에 남지 않도록 해당 URL의 페이지 캐시를 비웁니다 서버나 CDN에도 HTML 캐시가 있다면 그 계층도 함께 처리합니다 파일 결합·축소 설정이 달라진 경우에는 해당 제품의 생성 파일도 갱신합니다 메뉴 이름과 비우는 범위는 제품과 버전에 따라 다를 수 있습니다
- 활성 상태와 비활성 상태에서 각각 같은 방식으로 캐시를 비운 첫 미적중 요청을 모아 비교합니다 이후 요청은 적중 여부를 확인해 별도로 기록합니다 첫 요청과 이미 준비된 캐시 응답을 서로 비교하지 않는 것이 핵심입니다
- 관리자 화면은 공개 페이지 캐시를 비우는 것만으로 조건이 같아지지 않습니다 같은 계정과 주소, 같은 동작으로 3회 이상 다시 측정합니다 오브젝트 캐시는 전체를 일괄 삭제하면 다른 요청에도 영향을 줄 수 있으므로 기본 비교에서는 유지하고, 별도로 시험할 때만 양쪽에 같은 삭제·재측정 절차를 적용합니다
- 기록한 뒤 플러그인을 재활성화하고 필요한 캐시를 다시 갱신합니다 느려짐도 다시 나타나는지 확인한 다음 다음 플러그인으로 넘어갑니다 껐을 때만 빨라진 한 번의 결과보다 켰을 때 지연이 돌아오는 반복 결과가 원인 후보를 좁히는 데 도움이 됩니다
느려짐이 사라지면 그 플러그인이나 비슷한 기능을 하는 다른 플러그인과의 중복이 원인 후보로 좁혀집니다 끄고 나서도 속도가 그대로라면 그 플러그인 하나의 영향이 확인되지 않은 것입니다 캐시 상태와 느린 요청을 다시 확인하고, 다른 플러그인이나 서버 쪽 리소스도 함께 들여다볼 차례입니다
플러그인을 껐는데도 같은 캐시 응답을 받았다면 그 결과로 플러그인 영향을 제외하기 어렵습니다 반대로 문서의 TTFB는 그대로인데 화면 완성만 빨라졌다면 그 플러그인이 추가하던 파일이나 브라우저 작업이 줄었을 수 있습니다 이때는 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서처럼 문서 응답과 화면에 그려지는 시간을 나눠 보는 쪽이 맞습니다
도구 → 사이트 건강 → 정보에서는 WordPress·PHP 버전과 서버 환경을 기록할 수 있습니다 다만 이 화면만으로 느려진 순간의 CPU 사용량이나 PHP 작업자 대기 상태를 알 수는 없습니다 실시간 사용량은 호스팅 관리 화면의 모니터링·리소스 사용량·성능 항목에서 봅니다 제공되는 메뉴와 지표는 호스팅마다 다릅니다
- CPU는 해당 사이트나 계정의 할당 한도와 비교합니다 문서 응답이 늦어진 시간에 사용량이 한도에 붙거나 제한이 발생했는지 봅니다 CPU가 높다는 사실 하나로 특정 플러그인을 원인으로 정하지는 않습니다
- 메모리는 사용량뿐 아니라 한도 도달, 스왑 사용, 메모리 부족 오류가 같은 시간에 있었는지 봅니다 서버 전체 메모리와 PHP 요청별 메모리 제한은 다른 값입니다
- PHP 작업자는 활성 작업자 수와 허용 최대 수, 대기 요청을 봅니다 PHP-FPM 지표를 제공한다면 listen queue나 max children 도달 기록도 참고가 됩니다 지연 시점에 작업자가 모두 사용 중이고 대기가 늘었다면 요청이 실행되기 전부터 기다렸을 가능성이 있습니다
- 지표가 보이지 않으면 호스팅 지원에 느린 URL, 측정 시각과 시간대, TTFB, 캐시 상태를 함께 전달합니다 그 시간의 자원 제한과 PHP 대기·오류 기록을 확인해 달라고 하면 점검 범위가 분명해집니다
사이트마다 할당량이 달라 CPU 몇 퍼센트나 메모리 몇 MB를 공통 기준으로 잡기는 어렵습니다 중요한 것은 평소보다 느린 요청이 반복되는 시간과 자원 한도·대기 증가가 겹치는지입니다 자원이 여유로운데 특정 요청만 늦다면 외부 서비스 응답이나 데이터베이스 조회처럼 기다리는 작업도 남아 있으므로 서버 사양부터 올릴 근거는 아직 부족합니다
로그아웃 상태에서도 그대로 느리던 화면이 특정 플러그인을 끄자 평소 속도로 돌아왔다면 그 플러그인 화면에서 지금 버전과 바로 전 버전의 변경 내역을 비교해 두는 것이 다음 업데이트 전 판단 기준이 됩니다
버전과 함께 캐시 설정 화면, 비교한 URL, 로그인 여부, 측정 시각을 남겨 두면 다음 업데이트 때 무엇이 달라졌는지 보기 쉽습니다 검증 환경 기록은 예를 들어 ‘테스트용 복제 사이트 / WordPress·PHP는 양쪽 동일 버전 / 공개 게시글 1개와 관리자 목록 1개 / 플러그인 버전 A·B / 페이지 캐시 적중·미적중 분리 / 각 조건 3회 측정’처럼 적을 수 있습니다 이것은 기록 방식의 예시이며 이 사이트에서 직접 검증한 결과는 아닙니다
기술 근거는 WordPress 캐시 문서, WP Rocket 사용자 캐시 문서, 크롬 Network 문서를 확인했습니다 공식 문서 확인일은 2026년 10월 10일입니다 이번 보강에서는 캐시 적용 범위를 바로잡고 관리자 전용 지연과 공개 페이지 지연의 비교 절차를 추가했습니다 실제 운영 환경에서 확인한 결과를 덧붙일 때는 측정일과 사용 버전도 함께 남기는 편이 좋습니다
You May Also Like
워드프레스 이미지 최적화 후 느릴 때 확인하는 방법
토픽 클러스터 만드는 방법과 자기잠식 점검
