회원관리(수정), 주문내역(보기) 딜레이 로딩

제로데일리님이 짚어주신 주소검색 스크립트가 실제 원인인지, 운영 파일을 수정하기 전에 브라우저에서만 구분하는 방법을 보완합니다. 질문자님 환경에서 재현한 결과는 아닙니다.

1. F12 → Network에서 지연 중인 postcode 관련 스크립트 요청을 찾습니다.
2. 그 요청 하나만 우클릭 → Block request(버전에 따라 Block request URL)로 임시 차단하고 새로고침합니다. 전체 도메인이나 다른 요청은 차단하지 않습니다.
3. 차단했을 때 두 관리자 화면의 대기가 사라지는지 비교합니다. 사라지면 해당 외부 스크립트 로딩 경로를 우선 점검할 근거가 됩니다. 그대로라면 PHP 문서 요청이나 다른 자원을 확인해야 합니다.

이 테스트 중 주소검색 기능이 동작하지 않는 것은 예상되는 결과이며, 차단을 해결책으로 유지하면 안 됩니다. 비교가 끝나면 Request conditions/Network request blocking에서 해당 규칙을 해제·삭제하고 정상 상태로 돌아오세요.

Chrome 공식 절차: 요청 차단을 이용한 원인 분리

관리자에서 우편번호 찾기(다음 주소) 스크립트를 불러오는 화면이 딱 두 곳인데, 회원 수정(adm/member_form.php)과 주문 내역 보기(adm/shop_admin/orderform.php)입니다. 말씀하신 두 화면과 정확히 겹쳐서 이 스크립트부터 확인해 보시길 권합니다. 원인이라고 단정할 수는 없습니다.

F12 Network 탭을 켜고 회원 수정을 눌렀을 때 postcode.v2.js 줄이 Pending 으로 오래 남아 있는지 보세요. 그렇다면 config.php 의 G5_POSTCODE_JS 줄을 확인하시면 됩니다. 2022년 10월 전 배포본은 이 줄에 async 가 없어서, 외부 스크립트가 늦게 오면 화면 전체가 그걸 기다리느라 멈춥니다. 주소도 예전 것(dmaps.daum.net 등)인데 지금은 이 주소들이 정상 응답을 하지 않습니다.

현재 그누보드 원본 값은 공식 저장소 config.php 241번째 줄에서 보실 수 있습니다. 주소가 t1.kakaocdn.net 으로 바뀌었고 끝에 async 가 붙어 있습니다. 바꾸기 전에 config.php 는 백업해 두세요.
https://github.com/gnuboard/gnuboard5/blob/v5.6.43/config.php#L241

반대로 member_form.php 요청 자체가 오래 걸린다면 이 스크립트가 아니라 서버나 DB 쪽이니, 위 답변처럼 서버 로그를 보셔야 합니다.

소스를 수정하지 않았어도 서버나 DB 쪽 문제로 갑자기 느려질 수 있습니다.

다른 관리자 페이지는 정상인데 회원 수정이랑 주문 수정 페이지만 느리다면 서버 전체 문제보다는 해당 페이지에서 실행되는 PHP나 DB 쿼리를 먼저 확인해 보시는 게 좋을 것 같아요.

일단 F12 누르고 Network 탭을 켠 상태에서 문제가 되는 페이지에 접속해 보세요.

요청 자체가 오래 걸리는 건지, 응답은 왔는데 화면이 안 뜨는 건지부터 구분해 보시면 됩니다.

특히 서버 응답을 기다리는 시간이 길다면 PHP 오류 로그나 MySQL 슬로우 쿼리 로그를 확인해 보시는 게 좋겠습니다.

새로고침하면 가끔 정상적으로 열린다는 점도 확인해 볼 부분이고요.

회원 수정과 주문 수정에서 공통으로 불러오는 소스나 추가 기능이 있는지도 확인해 보세요. 두 페이지에만 문제가 생긴다면 공통 처리 부분에서 원인을 찾을 수도 있을 것 같습니다.

지금 증상만으로 원인을 단정하기는 어렵지만, 우선 Network에서 어느 요청이 지연되는지 확인하는 게 가장 빠른 출발점일 것 같습니다.