먼저 파일 이름과 역할을 찾으세요
‘렌더링을 막는 리소스’는 브라우저가 첫 화면을 그리기 전에 기다리는 파일을 뜻합니다. 보통 화면 모양을 정하는 CSS나 동작을 담당하는 JavaScript를 살펴보게 됩니다. 보고서에 스크립트 11개라고 적혀 있어도, 그 숫자만으로 지울 파일이나 느려진 정도를 정할 수는 없습니다. 먼저 어떤 파일인지 알아야 합니다.
Chrome에서 대상 페이지를 열고 개발자 도구의 Performance 탭으로 들어가세요. ‘Record and reload’를 눌러 페이지 로딩을 기록한 다음, Insights의 ‘Render-blocking requests’를 펼칩니다. 표시된 파일 주소를 복사하고, 어떤 기능이나 플러그인에서 불러오는지 확인하세요. 개발자 도구를 쓰기 어렵다면 이 확인을 사이트 제작 담당자에게 부탁해도 됩니다. 전달할 것은 ‘속도를 고쳐 주세요’보다 페이지 주소와 점검 항목입니다.
참고: Chrome for Developers · Render-blocking requests · Chrome DevTools · Performance reference
처음부터 필요한 파일인지 판단하세요
첫 화면의 글꼴과 배치를 만드는 CSS는 초반에 필요할 수 있습니다. 반면 페이지 아래쪽의 위젯처럼 늦게 실행해도 되는 기능은 로딩 시점을 조정할 여지가 있습니다. 다만 메뉴, 상담 폼, 결제와 연결된 파일을 무조건 늦추면 기능이 깨질 수 있습니다. 워드프레스라면 현재 사용 중인 성능 플러그인의 설정을 확인하고, 테스트할 수 있는 사본에서 한 항목씩 바꾸세요.
직접 코드를 수정하는 경우에는 의존성을 확인한 외부 일반 스크립트에 defer를 적용하는 방법이 있습니다. 아래는 파일 이름까지 설명을 위해 만든 코드입니다. 이 파일이 첫 화면 표시나 바로 뒤의 코드 실행에 필요하지 않다는 확인이 전제입니다. 모듈 스크립트나 인라인 스크립트에 똑같이 붙이는 방법은 아닙니다. CSS에는 이 속성을 쓰지 않습니다.
수정 전
<script src="/assets/course-enquiry.js"></script>수정 후
<script src="/assets/course-enquiry.js" defer></script>참고: Chrome for Developers · Render-blocking requests · MDN · The script element
화면과 기능을 확인한 뒤 다시 측정하세요
변경 전 설정과 기록을 남겨 두고, 적용 후 같은 페이지를 같은 기기·네트워크 조건으로 다시 측정하세요. 한 번의 수치에만 기대지 말고 여러 번 확인하며, 첫 화면이 나타나는 과정도 함께 봅니다. 메뉴를 열고, 상담 폼을 제출하기 전 단계까지 진행하고, 휴대폰 화면도 살펴보세요. 문제가 생기면 바꾼 설정을 되돌린 다음 해당 파일을 제외하고 다시 검토합니다.
담당자에게 맡긴다면 ‘이 페이지에서 이 파일이 초기 화면을 막는다고 나옵니다. 어떤 기능의 파일인지, 늦춰도 되는지 확인하고 변경 전후 기록과 기능 테스트 결과를 알려 주세요’라고 요청해 보세요. 파일의 역할과 변경 내용을 설명받으면 다음 점검도 쉬워집니다. 개발자 도구에서 얻은 한 번의 측정과 실제 방문자들의 Core Web Vitals는 서로 다른 데이터라는 점도 기억해 두세요.