워드프레스 글 편집 화면이 느릴 때 확인 방법

글 편집 화면이 느리다고 방문자가 보는 페이지까지 느린 것은 아닙니다. 관리자 화면에서 글을 고칠 때마다 기다린다면, 캐시 설정을 바꾸기 전에 지연이 나타나는 곳을 살펴봐야 합니다. 편집 화면은 열리는데 입력이 늦는지, 화면 자체가 열리지 않는지에 따라 첫 행동이 달라집니다.

방문자 페이지도 느린가요

글 편집 화면을 열고, 같은 글의 방문자 페이지도 별도 창에서 열어 지연이 어디서 나타나는지 살펴봅니다. 방문자 페이지는 곧 열리는데 편집 화면에서만 입력이나 저장이 늦다면, 방문자용 페이지 캐시를 먼저 바꿀 이유가 없습니다. 방문자용 페이지 캐시는 방문자에게 보여 주는 페이지의 제공 방식에 관여하며, 관리자 편집 화면의 작업을 대신 처리하지 않습니다.

편집 화면과 방문자 페이지가 모두 늦다면, 지연을 편집 기능 하나의 문제로 좁히지 않습니다. 편집 화면에 들어갈 수는 있지만 입력할 때만 늦다면, 화면을 여는 지연과 글을 다루는 지연을 구별해 둡니다. 글을 고치는 도중이라면 저장까지 늦는지도 살펴보면, 호스팅의 서버 응답을 조사할 때 증상을 더 정확히 설명할 수 있습니다.

“늦다”는 느낌은 날마다 달라지기 때문에, 나중에 설정을 바꿨을 때 정말 나아졌는지 말하려면 숫자로 남겨 두는 편이 좋습니다. 같은 글 하나를 정해 두고, 글자 한 줄을 고친 뒤 저장 버튼을 누르고 “저장됨” 표시가 뜰 때까지 걸린 시간을 초시계로 재서 세 번 적습니다. 방문자 페이지는 같은 글 주소를 새로 열어 브라우저 개발자 도구(F12)의 네트워크 탭에서 첫 문서 요청의 시간을 봅니다. 저장할 때는 같은 탭에서 wp-json 또는 admin-ajax.php로 나가는 요청이 보이는데, 이 요청의 시간이 저장 지연의 대부분을 차지하는지 함께 확인합니다. 이후 모든 변경은 이 글, 이 작업, 같은 시간대의 같은 방식으로 다시 잰다는 점이 중요합니다.

측정 항목(예시 값)	변경 전	변경 후
저장 클릭부터 완료까지 (3회 중앙값)	약 9초	약 3초
저장 요청 시간 (네트워크 탭)	약 8.5초	약 2.6초
방문자 페이지 첫 문서 요청	약 0.6초	약 0.6초

이 예시처럼 방문자 페이지는 그대로인데 저장 요청만 줄었다면, 바꾼 설정이 관리자 쪽 지연에 작용했다고 볼 수 있습니다. 반대로 저장 시간이 거의 그대로면 그 변경은 원인이 아니었다고 보고 보존해 둔 설정으로 되돌립니다.

편집 화면이 열리나요

화면에 들어갈 수 있다면 관리자의 도구 → 사이트 건강에서 상태 탭의 권장 사항을 살펴봅니다. 정보 탭의 서버 항목에서는 PHP 버전과 메모리 제한을 읽고, 현재 환경을 파악합니다. 사이트 건강의 권장 사항은 점검할 대상을 알려 주지만, 편집 화면 지연의 원인을 하나로 확정하지는 않습니다.

이 말을 뒷받침하는 근거는 공식 문서에 있습니다. 워드프레스 사이트 건강 문서는 상태 탭을 심각도별 점검 결과(중요 문제, 개선 권장, 통과)로, 정보 탭을 사이트 구성을 보여 주는 화면으로 설명합니다. 정보 탭은 정보만 보여 주고 설정을 바꾸는 화면은 아니며, 서버 항목의 값을 바꾸려면 호스팅에 문의하거나 호스팅이 허용할 때 php.ini에서 바꿔야 한다고 안내합니다. 그래서 여기서 읽은 값은 “무엇을 손볼지” 정하는 출발점으로 씁니다.

읽은 값이 괜찮은지는 다음 정도를 기준으로 봅니다. 숫자만 맞는다고 지연이 해결되는 것은 아니니, 어디까지나 “후보에서 빼도 되는지”를 가르는 용도입니다.

• PHP 버전: 워드프레스 요구 사항 문서는 PHP 8.3 이상을 권장합니다. 이보다 한참 낮은 버전이라면 호스팅 관리 화면의 PHP 버전 설정에서 올릴 수 있는지 먼저 확인합니다. 올리기 전에는 플러그인과 테마가 새 버전을 지원하는지 보고, 백업을 해 둡니다.
• 데이터베이스: 같은 문서의 권장은 MariaDB 10.11 이상 또는 MySQL 8.0 이상입니다. 정보 탭의 데이터베이스 항목에서 버전을 볼 수 있습니다.
• 메모리 제한: 요구 사항 문서에는 메모리 제한의 권장 수치가 따로 없습니다. 다만 wp-config.php 문서는 기본값을 단일 사이트 40MB, 멀티사이트 64MB로 시도한다고 설명하고, 관리자 작업용 WP_MAX_MEMORY_LIMIT의 예시로 128M을 듭니다. 그래서 저는 40~64MB 근처라면 편집기와 플러그인이 많은 사이트에는 빠듯할 수 있다고 보고, 128M 정도를 시험해 볼 출발점으로 삼습니다.

메모리 제한은 호스팅 설정에서 바꾸는 것이 가장 확실합니다. 호스팅이 막아 두지 않았다면 wp-config.php에 define( 'WP_MEMORY_LIMIT', '128M' );처럼 한 줄을 추가하는 방법도 있습니다. 다만 이미 PHP에 더 큰 값이 잡혀 있으면 워드프레스가 낮추거나 올리지 못하고, 호스팅이 변경을 허용하지 않는 경우도 있습니다. 공식 문서도 한도를 올리면 근본 원인이 가려질 수 있다고 경고하니, 올린 뒤에는 앞서 만든 기록표로 저장 시간이 실제로 줄었는지 확인합니다.

저라면 편집 화면만 늦을 때 방문자용 캐시를 설치하기보다, 사이트 건강에서 서버 상태를 먼저 읽겠습니다. 플러그인 설정을 바꾸려면 현재 설정을 보존하고 한 번에 하나만 변경한 뒤, 같은 편집 작업에서 지연이 달라지는지 봅니다. 변화가 없으면 보존한 설정으로 되돌리며, 어떤 변경에서 달라졌는지 알 수 있도록 여러 설정을 함께 바꾸지 않습니다.

편집 화면이나 관리자 화면이 열리지 않는다면 FTP·SFTP 또는 호스팅 파일 관리자에서 사이트 파일에 접속합니다. wp-content의 plugins 폴더를 백업한 뒤 이름을 plugins-off처럼 임시로 바꾸고, 관리자 화면이 다시 열리는지 봅니다. 전체 플러그인을 끄는 동안 방문자에게 보이는 기능이 잠시 멈출 수 있으며, 열리지 않는 상태라면 폴더 이름을 plugins로 되돌립니다.

화면이 열리면 관리자의 플러그인 화면(주소 끝이 /wp-admin/plugins.php)을 한 번 열어 둡니다. 워드프레스가 플러그인 파일이 없다는 것을 확인하면서 모든 플러그인을 비활성화 상태로 바꿔 두기 때문입니다. 폴더 이름을 plugins로 되돌린 뒤 목록에서 하나씩 켜며 지연이 돌아오는 지점을 찾습니다. 이 방법은 일반 plugins 폴더에만 적용되며, mu-plugins나 advanced-cache.php는 그대로 남습니다.

이 절차는 워드프레스 공식 문제 해결 FAQ에도 나옵니다. 문서는 폴더를 plugins.hold 같은 이름으로 바꾼 뒤 plugins.php에 접속하고, 다시 plugins로 되돌리면 플러그인이 비활성화된 채 남으니 하나씩 켜라고 안내합니다. 켤 때마다 앞의 기록표와 같은 방식으로 저장 시간을 재면, 어느 플러그인에서 느려지는지 숫자로 구분됩니다.

그대로 느리면 어디를 보나요

사이트 건강에서 서버 환경을 읽었는데도 편집 화면이 느리다면, 호스팅 화면의 서버 응답 시간과 CPU 사용량을 살펴봅니다. 호스팅마다 화면 위치가 다르므로 제공되는 PHP 오류 기록의 위치도 해당 호스팅 안내에서 찾습니다. 서버 사용량이 지연과 함께 높아진다면 서버 쪽 상황을 살펴볼 근거가 되고, 오류 기록은 발생한 오류를 찾는 데 쓰입니다.

여기서 “높다”의 기준은 호스팅마다 달라 하나의 숫자로 말하기 어렵습니다. 그래서 저는 지연을 겪은 시각을 미리 적어 두고, 그 시각의 그래프가 평소 편집하던 때보다 눈에 띄게 튀는지(예를 들어 평소의 두세 배), 또는 요금제가 정한 CPU·메모리 한도에 붙어 있는지를 봅니다. 지연이 없던 시간대와 나란히 놓고 비교해야 의미가 있으며, 그래프가 평평한데 저장만 늦다면 서버 자원보다 플러그인이나 쿼리 쪽을 의심하는 편이 맞습니다.

서버 쪽 항목으로 방향이 잡히지 않으면 Query Monitor 같은 진단 플러그인을 점검하는 동안에만 켭니다. 쿼리와 실행 시간을 살펴 느린 요청의 후보를 좁힌 뒤에는 진단 플러그인을 끕니다. 진단용 플러그인을 추가하는 단계이므로, 새 도구의 영향까지 겹치지 않게 앞선 설정 변경을 마친 상태에서 사용합니다.

Query Monitor를 켜면 관리자 상단 막대에 메뉴가 생기고, 항목을 누르면 상세 패널이 열립니다. 플러그인 소개 페이지에 따르면 느린 쿼리와 중복 쿼리, 오류 쿼리를 알려 주고 쿼리를 구성 요소별, 호출한 함수별로 묶어 볼 수 있습니다. 글 편집 화면에서 저장을 한 번 누른 뒤 아래 순서로 보면 후보가 좁혀집니다.

• Queries(쿼리): 전체 쿼리 수와 총 시간을 봅니다. 느린 쿼리는 강조되어 나오므로 그 쿼리를 어떤 함수가 호출했는지 함께 적어 둡니다.
• 구성 요소별 쿼리(Queries by Component): 플러그인·테마·워드프레스 코어 중 어디가 시간을 많이 쓰는지 비교합니다. 특정 플러그인 하나가 유독 크다면, 앞서 하나씩 켜 보던 목록에서 그 플러그인을 먼저 의심합니다.
• 중복 쿼리(Duplicate Queries): 같은 쿼리가 여러 번 반복되는지 확인합니다. 반복 횟수가 많으면 한 번에 가져오지 않고 되풀이해 호출하는 코드가 있다는 뜻입니다.

이렇게 좁힌 후보를 끄거나 설정을 바꾼 뒤에는, 기록표와 같은 글·같은 작업으로 저장 시간을 다시 재서 줄었는지 확인합니다. 쿼리 시간이 줄었는데도 저장이 그대로라면 쿼리가 원인이 아니었다는 뜻이니, 서버 쪽 기록을 근거로 호스팅에 문의하는 쪽으로 넘어갑니다.

편집 화면만 늦다면 방문자 페이지를 빠르게 하는 설정 대신 관리자 작업의 지연을 조사해야 합니다. 서버 사용량과 느린 요청이 함께 나타난다면, 해당 시점의 기록을 근거로 호스팅에 문의할 수 있습니다.

확인 환경과 기준일

이 글의 메뉴 이름과 절차는 워드프레스 6.x 관리자 화면(블록 에디터)을 기준으로 정리했으며, 예시 표의 수치는 WordPress 6.x, PHP 8.3, 공유 호스팅 환경을 가정한 값입니다. 메뉴 이름과 위치는 버전과 호스팅에 따라 다를 수 있습니다. 인용한 공식 문서(사이트 건강, 문제 해결 FAQ, 요구 사항, wp-config.php)는 2026년 10월 11일에 다시 열어 내용을 확인했고, 이 글의 최종 확인일도 같은 날입니다.

• 사양 올려도 똑같이 버벅이는 워드프레스, 진짜 원인은 이것
• 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것