본문은 떴는데 로딩 화면만 남는다면: 전체 화면 로더의 종료 조건

본문 HTML이 도착했는데 전체 화면 로더가 남아 있다면, 서버 응답과 로더 해제 조건을 나눠 확인해야 합니다. 서버에서 본문을 렌더링하는 읽기 화면은 글과 무관한 외부 리소스를 기다리지 않고 공개하는 편이 좋습니다.

개발자 도구에서 본문 요소가 존재하는지, 그 위에 덮개가 남아 있는지부터 확인하세요. 이 글에서는 준비 조건을 나누고, 외부 요청을 지연·차단해 읽기와 탐색이 가능한지 검증하는 방법을 다룹니다.

본문 공개에 필요한 준비 조건부터 정합니다

MDN에 따르면 load 이벤트는 지연 로딩을 제외한 이미지·프레임 등 종속 리소스의 로드를 기다립니다. 이를 본문 공개 조건으로 사용하면 읽기와 무관한 리소스도 대기 경로에 들어갑니다.

DOMContentLoaded는 DOM 구성이 끝난 시점을 판단하는 데 쓰지만 모든 기능의 준비를 보장하지는 않습니다. 늦게 실행되는 스크립트가 이벤트를 놓칠 수 있으므로, DOM만 필요한 작업은 readyState를 확인해 바로 실행하는 경로를 둘 수 있습니다.

다만 readyState가 interactive인 동안에도 다른 deferred/module 스크립트는 아직 실행 중일 수 있습니다. 다른 모듈이 만드는 상태에 의존한다면 해당 초기화의 완료 신호도 기다려야 합니다.

실제 수정은 서버에서 렌더링하는 블로그로 한정했습니다

심플소프트 저장소에서는 블로그에만 hidePreloader를 지정했습니다. 목록·상세 Blade가 이 값을 전달하고 공통 레이아웃은 로더 마크업을 생략합니다. 검색·상담 링크 같은 개별 동작은 별도로 확인하도록 범위를 나눴습니다.

서버가 제목과 본문을 반환하는 화면이라 가능한 선택입니다. 저장이나 결제는 준비 전 실행을 허용하면 데이터 손상이나 잘못된 처리가 생길 수 있으므로, 본문 공개와 별도로 버튼의 활성화 조건을 정해야 합니다.

예시: 외부 이미지 한 건을 지연·차단해 확인합니다

다음은 검증 환경에서 실행할 절차 예시입니다. 실제 광고가 장애 원인이었다는 관찰 기록은 아닙니다. 먼저 같은 콘텐츠를 가진 수정 전후 환경을 준비하고, 필수 CSS·JS가 아닌 외부 이미지 요청 한 건을 고릅니다. 지연 중 행동을 관찰하려면 지연 로딩되지 않는 충분히 큰 테스트 이미지가 적합합니다.

Chrome DevTools의 Request conditions에서는 URL별 요청 지연과 차단을 설정할 수 있습니다. 두 조건을 나눠 확인하세요. 차단은 요청을 즉시 실패시킬 수 있으므로, 계속 기다리는 상태의 재현과는 다릅니다.

1. Network 패널에서 캐시를 비활성화하고 정상 새로고침합니다. 페이지 URL, 브라우저 버전, 대상 이미지 URL, 로더 유무를 기록합니다.

2. 대상 요청을 우클릭해 Throttle request를 선택합니다. Request conditions에서 해당 URL에 느린 프리셋을 적용하고 새로고침합니다.

3. Network에서 요청이 아직 진행 중인지 확인한 상태로 본문을 선택하고 목록 링크로 이동해 봅니다. 같은 조건을 수정 전후 환경에서 반복합니다.

4. 이번에는 해당 URL의 지연 규칙을 해제하고 차단 규칙을 적용합니다. 새로고침 후 실패한 이미지 때문에 본문이나 링크가 가려지는지 확인합니다.

5. 지연·차단 규칙을 모두 해제하고 캐시 설정도 원복한 뒤 정상 화면을 다시 확인합니다.

요청이 너무 빨리 끝나 지연 중 행동을 확인하지 못했다면 통과로 기록하지 않습니다. 더 느린 프로필이나 큰 테스트 이미지를 사용해 다시 확인합니다. 문서 요청 전체를 느리게 하면 서버 본문 도착까지 함께 늦어지므로 이 검증의 원인을 분리하기 어렵습니다.

검증 기록 예시 — 기대값이며 실측 결과 아님
환경: 수정 전 / 수정 후의 배포 식별자
대상: 비필수 외부 이미지 URL 1개
조건: 정상 / 요청 진행 중 / 요청 차단
본문 요소 존재: 예 또는 아니오
본문 선택: 가능 또는 불가
목록 링크: 키보드 초점·실제 이동 가능 여부
증거: 조건별 화면 캡처와 요청 상태

수정 전 로더가 남았다면 그 화면과 요청 상태를 함께 남깁니다. 수정 후에는 같은 요청이 진행 중이거나 실패한 상태에서도 읽기와 링크 이동이 가능해야 합니다. 캡처나 네트워크 기록을 공유할 때에는 토큰·쿠키·개인정보를 제외합니다.

편집 화면에 같은 규칙을 적용하면 안 됩니다

편집기의 초기값을 받기 전에 저장 버튼까지 열면 빈 내용을 저장할 수 있습니다. 이 경우에는 읽기는 허용하되 초기화 완료 전 저장을 막고, 실패 시 재시도나 읽기 전용 복구 경로를 제공해야 합니다. 스크립트 실패 검증은 별도 테스트에서 편집기 준비 신호를 실패시켜 저장이 차단되는지 확인합니다.

본문 자체가 오지 않았다면 로더 제거로 해결되지 않습니다. 요청 실패 안내와 재시도가 필요합니다. 필수 기능까지 사용할 수 없게 됐다면 변경을 되돌린 뒤 해당 기능의 준비 조건부터 다시 확인합니다.

본문 공개 후에도 표시가 느리다면 Core Web Vitals 원인 분류 가이드에서 네트워크와 렌더링 병목을 이어서 확인할 수 있습니다.

완료 조건은 정상·외부 요청 지연·차단 조건에서 본문 선택과 링크 이동을 확인하고 기록하는 것입니다. 저장이 있는 화면은 초기화 실패 시 실행이 막히는지도 별도로 확인합니다.