워드프레스 Heartbeat API 최적화｜admin-ajax.php 20분 진단
워드프레스 관리자 화면을 열어 둔 동안 CPU 사용량이 주기적으로 오르거나 admin-ajax.php 요청이 반복된다면 Heartbeat API를 확인할 차례입니다. 다만 이 파일을 호출하는 요청이 모두 Heartbeat는 아니며, 요청 자체가 많다는 이유만으로 기능을 꺼서도 안 됩니다. 이 글에서는 크롬 개발자 도구로 진짜 Heartbeat 요청을 구분하고, 자동 저장과 글 잠금을 보존하면서 부하가 생기는 범위만 줄이는 방법을 설명합니다.
먼저 결론: 차단보다 발신 화면을 찾는다
- Network 탭에서
admin-ajax.php를 찾은 뒤 요청 데이터의action=heartbeat를 확인합니다. - 관리자 대시보드, 글 편집기, 방문자 화면을 나눠 어느 화면에서 반복되는지 기록합니다.
- 요청 간격뿐 아니라 한 번의 응답 시간과 응답 데이터 크기도 비교합니다.
- 글 편집기의 자동 저장·편집 잠금은 유지하고 문제가 확인된 화면만 조정합니다.
- 변경 전후를 같은 조건에서 5분씩 측정하고 이상이 생기면 즉시 되돌립니다.
Heartbeat API는 무엇을 하는 기능인가?
Heartbeat API는 브라우저와 워드프레스 서버가 일정 간격으로 정보를 주고받게 하는 폴링 기능입니다. 워드프레스 공식 문서에 따르면 틱 간격은 15초에서 120초 범위이며, 브라우저가 데이터를 모아 서버의 AJAX 처리기로 보내고 JSON 응답을 받습니다. 글을 편집하는 동안에는 다른 사용자의 편집 여부, 글 잠금, 자동 저장과 로그인 상태 관련 기능에 활용됩니다. 플러그인도 Heartbeat 요청에 자체 데이터를 추가할 수 있으므로 같은 요청이라도 설치 환경에 따라 처리 비용이 달라집니다.
admin-ajax.php가 보여도 바로 Heartbeat는 아니다
admin-ajax.php는 검색, 필터, 보안 검사, 쇼핑몰 장바구니처럼 여러 기능이 함께 사용하는 통로입니다. 크롬에서 문제가 의심되는 화면을 열고 F12를 누른 뒤 Network의 Fetch/XHR 항목에서 admin-ajax.php를 선택하세요. Payload 또는 Form Data에 action 값이 heartbeat로 표시될 때만 Heartbeat 요청으로 분류합니다. Initiator, 시작 시각, Duration, 응답 크기를 함께 기록하면 단순 호출 빈도와 실제 병목을 구분할 수 있습니다.
| 확인 항목 | 기록할 내용 | 판단 기준 |
|---|---|---|
| 발신 화면 | 대시보드·글 편집기·방문자 페이지 | 특정 화면에서만 반복되는지 확인 |
| Action | heartbeat 여부 | 다른 AJAX 요청과 분리 |
| 간격 | 연속 요청 사이의 초 | 탭 수가 늘 때 요청 수도 비례하는지 확인 |
| 처리 시간 | Duration과 TTFB | 몇 차례만 보지 말고 5분 평균 비교 |
| 응답 데이터 | JSON 키와 크기 | 플러그인이 큰 데이터를 추가하는지 확인 |
20분 진단 순서
1. 재현 조건을 고정한다
로그인한 브라우저 탭 수, 열어 둔 관리자 화면, 측정 시간을 먼저 적습니다. 탭 하나로 5분을 측정한 다음 같은 화면을 세 탭으로 늘려 비교하면 동시 편집 화면이 부하를 키우는지 확인하기 쉽습니다. 서버의 CPU와 PHP 작업 수치도 같은 시간대에 기록하세요. 사이트 전체가 간헐적으로 느리다면 워드프레스 간헐적 느림 진단 순서를 함께 적용하는 편이 정확합니다.
2. 요청 안의 데이터를 확인한다
Heartbeat 응답에 낯선 플러그인 이름이나 큰 데이터 묶음이 반복되면 해당 플러그인을 테스트 환경에서만 잠시 비활성화한 뒤 다시 측정합니다. 전후 차이가 뚜렷할 때 원인 후보로 판단하세요. 관리자 화면의 느린 PHP 처리나 데이터베이스 쿼리는 Query Monitor로 느린 플러그인 찾는 방법으로 교차 확인할 수 있습니다.
3. 화면별로 조정 범위를 결정한다
| 화면 | 보존할 기능 | 안전한 첫 대응 |
|---|---|---|
| 글·페이지 편집기 | 자동 저장, 글 잠금, 세션 확인 | 완전 중지하지 말고 플러그인 추가 데이터부터 점검 |
| 관리자 대시보드 | 필요한 알림과 상태 갱신 | 실시간 기능 필요 여부를 확인한 뒤 간격 확대 검토 |
| 방문자 화면 | 회원·쇼핑몰의 실시간 기능 | 로그인 여부와 페이지 종류별로 실제 사용 여부 확인 |
코드로 조정할 때는 워드프레스의 heartbeat_settings 필터를 사용해 간격을 설정할 수 있습니다. 공식 코드 참고 사항은 15~120초 범위를 안내합니다. 운영 사이트에서 바로 수정하지 말고 스테이징 환경에서 화면 ID를 확인한 뒤 적용하세요. 테마의 functions.php에 임시로 넣는 방식보다 코드 스니펫 관리 도구나 자체 플러그인처럼 쉽게 끄고 되돌릴 수 있는 위치가 안전합니다.
변경 후 반드시 확인할 기능
- 새 글을 10분 이상 편집하고 자동 저장 표시가 정상인지 확인합니다.
- 서로 다른 두 계정으로 같은 글을 열어 편집 잠금 알림을 확인합니다.
- 관리자 화면을 오래 열어 두고 로그인 만료 안내와 재인증을 확인합니다.
- 쇼핑몰이나 회원 기능이 있다면 장바구니, 결제, 알림을 직접 시험합니다.
- 같은 탭 수와 시간으로 요청 횟수, 평균 응답 시간, CPU를 다시 측정합니다.
요청 수가 줄었는데도 응답이 느리다면 Heartbeat 빈도가 아니라 PHP 처리나 데이터베이스가 원인일 수 있습니다. 이때는 워드프레스 TTFB 줄이는 점검 순서로 서버 처리 구간을 확인하세요. 자동 저장 누락, 편집 충돌, 로그인 이상이 나타나면 최적화 효과보다 위험이 크므로 즉시 이전 설정으로 되돌려야 합니다.
TIP
“30초를 60초로 바꿨다”는 기록만으로는 효과를 판단할 수 없습니다. 변경 전후 각각 5분 동안 요청 횟수, 평균 응답 시간, 가장 느린 요청, 서버 CPU를 한 줄로 남기세요. 요청이 줄어도 한 번의 응답이 계속 느리다면 Heartbeat에 데이터를 추가하는 플러그인이나 느린 쿼리를 먼저 고쳐야 합니다.
자주 묻는 질문
Heartbeat API를 완전히 꺼도 되나요?
권장하지 않습니다. 글 잠금, 자동 저장 연계, 로그인 상태 갱신처럼 관리자 작업에 필요한 기능이 영향을 받을 수 있습니다. 먼저 원인이 확인된 화면과 플러그인 데이터만 좁혀 조정하세요.
admin-ajax.php 요청이 많으면 서버 문제인가요?
호출 횟수만으로 판단할 수 없습니다. action, 처리 시간, 응답 크기와 동시 탭 수를 함께 봐야 합니다. 요청이 빠르게 끝나고 자원 사용량이 안정적이라면 우선순위가 낮습니다.
캐시 플러그인으로 Heartbeat 요청도 빨라지나요?
로그인 사용자용 동적 AJAX 요청은 일반 페이지 캐시와 성격이 다릅니다. 캐시 설정만 바꾸기보다 요청에 연결된 PHP 작업과 데이터베이스 쿼리를 확인해야 합니다.
공식 자료
마무리
워드프레스 Heartbeat API 최적화는 admin-ajax.php를 막는 작업이 아니라 요청의 정체와 비용을 확인하는 작업입니다. action=heartbeat를 확인하고 발신 화면, 간격, 응답 시간을 기록한 뒤 필요한 화면만 조정하세요. 자동 저장과 글 잠금을 실제로 시험하고 같은 조건에서 다시 측정해야 성능과 편집 안정성을 함께 지킬 수 있습니다.
댓글 0
첫 댓글을 남겨보세요.