WordPress의 Core Web Vitals를 개선하려면 대표 템플릿을 측정하고 느린 단계를 찾은 다음, 원인이 되는 호스팅·테마·플러그인 동작을 수정해야 합니다. 로그인하지 않은 방문자로 공개 페이지를 확인하고 중요한 상호작용도 시험합니다. 캐시 플러그인은 HTML 대기를 줄일 수 있지만 무거운 이미지, 불안정한 레이아웃, 느린 클릭 처리기를 모두 고치지는 못합니다.
사이트의 운영 조건도 다릅니다. 캐시된 출판 사이트, 회원 영역, WooCommerce 결제에는 서로 다른 규칙이 필요합니다. 설치 전체에 최적화를 적용하기 전에 차이를 기록합니다.
템플릿과 방문자 상태별 기준을 만듭니다
홈페이지, 일반 게시물, 목록, 랜딩 페이지를 선택하고 쇼핑몰이라면 상품과 장바구니도 포함합니다. 큰 갤러리나 상호작용 요소가 있는 페이지도 고릅니다. 홈페이지 한 곳의 성공적인 테스트가 나머지 사이트의 성능을 보장하지는 않습니다.
사용 가능한 실제 사용자 데이터로 문제 템플릿과 기기 그룹을 찾은 뒤 PageSpeed Insights와 브라우저 기록으로 재현합니다. Core Web Vitals 입문 안내는 LCP, INP, CLS를 구분합니다. 필드 데이터가 없다는 것은 정보가 부족하다는 뜻이며 0이나 통과를 의미하지 않습니다.
테스트 날짜와 WordPress, PHP, 테마, 관련 플러그인 버전을 기록합니다. 로그인 여부, 장바구니 존재, 동의 상태, 페이지 캐시 적중 여부도 적습니다. 변경을 비교할 때 화면 크기, 네트워크 설정, 작업 순서를 동일하게 유지합니다.
테마 코드나 PHP를 바꾸기 전에 스테이징과 복구 절차를 준비합니다. 고객 정보를 노출하지 않는 대표 콘텐츠를 사용합니다. 스테이징의 캐시와 호스팅은 운영 환경과 다를 수 있습니다. 호환성을 먼저 확인하고 승인된 배포 후 실제 설정에서 성능을 다시 확인합니다.
프런트엔드를 바꾸기 전에 서버 시간을 조사합니다
문서를 받기까지 오래 기다린다면 서버 경로를 살펴봅니다. 캐시 적중, 캐시 삭제 후 첫 요청, 의도적으로 캐시하지 않는 페이지를 비교합니다. 반복 방문이 빨라도 캐시 미적중이 느린 문제는 중요합니다. 호스팅 담당자나 개발자와 PHP 실행, 데이터베이스 질의, 외부 HTTP 호출, 자원 경합을 확인합니다.
2026년 10월 17일 확인한 WordPress 공식 요구사항은 PHP 8.3 이상, MariaDB 10.11 이상 또는 MySQL 8.0 이상, HTTPS를 권장합니다. 모든 오래된 플러그인이 모든 최신 PHP를 지원한다는 뜻은 아닙니다. 호환성과 업데이트를 시험하고 해당 설치에 적합한 지원 중인 PHP 계열을 선택합니다.
PHP 워커 포화, opcode 캐시, 메모리 제한, 느린 요청 진단을 호스팅 업체에 문의합니다. 워커를 늘리려면 CPU와 메모리도 충분해야 하므로 많다고 항상 좋은 것은 아닙니다. 매 요청마다 실행되는 외부 API 호출은 상위 요금제보다 캐시나 구조 변경이 필요할 수 있습니다.
데이터베이스 정리를 무차별 삭제로 처리하지 않습니다. 비싼 질의와 데이터를 소유한 플러그인을 찾습니다. 오래된 기록을 지우기 전에 백업하고 필요한 업무 이력을 보존하며 다음 요청에서 같은 작업이 재생성되는지 확인합니다. 문서 응답이 주된 병목이면 서버 응답 시간 개선 안내를 참고합니다.
캐시 계층과 예외를 구분합니다
WordPress 기본 객체 캐시는 현재 요청 동안 유지됩니다. 요청 사이에 저장하려면 호환되는 통합과 백엔드가 필요합니다. 데이터를 재사용하는 것과 저장된 HTML을 제공하는 것은 다르므로 각각 판단합니다.
다음 표는 캐시 계층별 역할을 구분합니다.
| 계층 | 줄일 수 있는 작업 | 별도로 시험할 항목 |
|---|---|---|
| 전체 페이지 캐시 | 적합한 HTML 응답 재생성 | 로그인, 개인화, 장바구니 |
| 영구 객체 캐시 | 반복 데이터 조회와 계산 | 무효화, 가용성, 메모리 |
| PHP opcode 캐시 | 실행마다 PHP 재컴파일 | 호스트 설정과 코드 갱신 |
| 브라우저 파일 캐시 | 변하지 않은 파일 재다운로드 | 버전 URL과 배포 무효화 |
| CDN 또는 에지 캐시 | 원본에서 반복 전송 | 캐시 키, 쿠키, 삭제 규칙, 비공개 내용 |
계층마다 책임자를 정합니다. 두 플러그인이 동시에 스크립트를 재작성하거나 중요 CSS를 생성하거나 이미지 URL을 바꾸면 원인을 추적하기 어렵습니다. 새 시스템을 넣기 전에 호스트의 기존 캐시를 확인합니다. 관리자 화면의 활성화 표시만으로 공개 응답의 캐시 가능 여부나 실제 사용을 알 수는 없습니다.
로그아웃 상태에서 응답 헤더와 반복 요청을 확인합니다. 콘텐츠를 바꾸면 공개 페이지가 올바르게 갱신되는지도 봅니다. 언어, 통화, 기기별 콘텐츠, 동의가 응답을 바꾼다면 안전한 변형 키나 우회 규칙을 정의합니다. 캐시가 모든 플러그인을 이해한다고 가정하지 않습니다.
공유 페이지 캐시로 한 고객의 계정이나 장바구니를 다른 고객에게 전달해서는 안 됩니다. WooCommerce 문서는 장바구니, 결제, 내 계정을 부적절한 페이지 캐시에서 제외해야 할 동적 페이지로 명시합니다. 맞춤 엔드포인트와 세션 동작도 실제 통합에 맞춰 검토합니다.
플러그인 수보다 테마와 플러그인의 동작을 점검합니다
각 플러그인의 기능과 필요한 위치를 나열합니다. 연락처 페이지에서만 쓰는 폼은 전체 검색 기능과 다르게 조사해야 합니다. 개수만으로 질의 비용, HTML 크기, 외부 서비스, JavaScript 실행량을 알 수 없습니다.
스테이징에서 비필수 요소 하나를 끄고 관련 캐시를 삭제한 뒤 같은 시나리오를 반복합니다. 사라진 기능과 개선된 부분을 기록합니다. 서버와 브라우저를 모두 봅니다. 눈에 띄는 파일 없이 캐시되지 않은 요청을 늦추는 플러그인도 있고, PHP 시간은 비슷한 채 브라우저 위젯만 추가하는 플러그인도 있습니다.
여전히 무겁다면 대표 콘텐츠를 사용해 더 단순한 테마를 시험합니다. 빈 데모와 내비게이션, 번역, 광고, 갤러리를 포함한 실제 글은 다른 조건입니다. 테마 판매 페이지의 점수를 예측값으로 쓰지 말고 필요한 기능을 같은 조건에서 비교합니다.
블록 테마와 블록 편집기도 작은 페이지를 보장하지 않습니다. 반복 쿼리 블록, 중첩 레이아웃, 큰 갤러리, 인터랙티브 확장은 계속 작업을 만듭니다. 렌더링 결과를 보고 정보를 중복하는 패턴을 단순화하며, 사용하지 않는 요소가 공유 CSS나 스크립트를 여전히 등록하는지 확인합니다.
편집상의 선택도 함께 검토합니다. 장식용 캐러셀을 유용한 이미지 한 장으로 바꾸면 JavaScript를 계속 수정하는 것보다 유지하기 쉬울 수 있습니다. 독자에게 도움이 없는 동작을 제거하면서 정보와 접근성은 보존합니다.
WordPress의 이미지 마크업을 활용하고 결과를 검사합니다
첨부 파일 함수는 미디어 메타데이터로 크기와 반응형 후보를 출력할 수 있습니다. 모든 썸네일에 원본 전체를 넣지 말고 적절하게 등록된 크기를 사용합니다. 테마의 이미지 크기가 바뀌면 기존 업로드에 파생 파일이 있는지 확인합니다. 재생성이 필요하다면 저장 공간과 처리 비용을 계획합니다.
다음 코드는 첨부 파일 API로 대표 이미지를 출력합니다. 현재 게시물을 사용할 수 있는 WordPress PHP 템플릿에 넣는 예입니다.
<?php
$image_id = get_post_thumbnail_id();
if ( $image_id ) {
echo wp_get_attachment_image(
$image_id,
'large',
false,
array( 'class' => 'article-featured-image' )
);
}
?>소스 조각뿐 아니라 최종 HTML을 확인합니다. 테마나 플러그인이 srcset, sizes, 로딩 속성, 크기를 수정할 수 있습니다. 모바일과 데스크톱에서 실제 표시 공간과 브라우저가 선택한 이미지를 비교합니다. 이미지 최적화 안내는 표시 크기와 픽셀 밀도가 선택에 미치는 영향을 설명합니다.
WordPress는 서버 이미지 라이브러리가 지원할 때 5.8부터 WebP, 6.5부터 AVIF 업로드를 지원합니다. 기존 JPEG가 자동으로 모두 변환된다는 뜻은 아닙니다. 이미지 서비스를 추가하기 전에 실제 응답 형식, 대체 동작, 생성 크기를 확인합니다.
코어의 이미지 로딩 로직은 발전해 왔으며 6.3에서는 지연 로딩과 가져오기 우선순위의 조정이 도입되었습니다. 모든 이미지를 지연 로딩하지 않습니다. 실제 LCP 이미지를 찾고 일찍 발견할 수 있도록 하며 플러그인이 loading="lazy"를 붙이지 않았는지 확인합니다. 모든 이미지에 높은 우선순위를 주는 것도 의미 있는 우선순위 설정을 방해합니다.
의존성을 유지하면서 차단 리소스를 줄입니다
필요한 콘텐츠를 늦추는 CSS나 스크립트를 찾고 제거 전에 소유자를 확인합니다. 폼 플러그인 이름의 파일이 푸터 입력창, 모달, 번역된 템플릿에도 필요할 수 있습니다. 특정 페이지로 제한할 때 이 상태들을 모두 시험합니다.
자체 테마 스크립트에는 넓은 텍스트 필터로 태그를 고치기보다 WordPress enqueue API를 사용합니다. 6.3에서 defer와 async용 strategy 인자가 추가되었습니다. WordPress가 적절한 전략을 고를 때 의존성 트리를 고려하므로 정확하게 선언합니다.
다음 예는 자식 테마의 functions.php에 넣으며 참조 파일이 해당 테마에 있어야 합니다.
<?php
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_script(
'site-navigation',
get_stylesheet_directory_uri() . '/assets/navigation.js',
array(),
'1.0.0',
array( 'strategy' => 'defer', 'in_footer' => true )
);
} );이 예는 모든 플러그인 스크립트를 지연시키지 않습니다. 등록된 의존성이 없는 자체 스크립트의 선언 방법입니다. 라이브러리를 사용한다면 올바른 핸들을 추가하고 인라인 초기화 순서를 확인합니다. 로딩 중에도 기능을 유지하고 사용자가 작동하지 않는 버튼을 누를 때까지 필수 내비게이션을 미루지 않습니다.
중요 CSS나 리소스 제거 기능은 생성 결과를 검토한 뒤 사용합니다. 메뉴, 검색, 검증 메시지, 동의 제어, 동적 콘텐츠를 시험합니다. 탐색 기록에서 쓰이지 않은 CSS가 나중에 필요할 수 있습니다. 정상 스크린샷 하나로 전체 인터페이스가 보존되었다고 볼 수는 없습니다.
템플릿 전반에서 글꼴과 레이아웃을 안정화합니다
실제로 요청하는 글꼴 패밀리, 굵기, 문자 집합을 조사합니다. 중복 패밀리와 사용하지 않는 변형을 제거합니다. 로컬 글꼴은 라이선스를 확인하고 모든 언어에 필요한 문자를 유지합니다. 라틴 문자만 있는 부분집합으로는 한국어나 히브리어를 올바르게 표시할 수 없습니다.
선호 글꼴이 도착하기 전 대체 텍스트를 확인합니다. 줄바꿈, 버튼 너비, 제목 높이를 비교합니다. font-display 선택으로 글자가 보여도 메트릭이 다르면 교체 시 레이아웃이 움직입니다. 광고, 미디어, 알림 공간을 확보하고 읽고 있는 내용 위에 새 요소를 삽입하지 않습니다.
현실적인 확대 비율과 화면 크기로 고정 헤더와 메뉴를 시험합니다. 데스크톱 캡처에서는 안정적이어도 전화기에서 줄이 바뀌면 움직일 수 있습니다. 측정 중 증상을 숨기지 말고 요소의 크기나 흐름을 수정합니다.
WooCommerce 전용 테스트 표를 만듭니다
단순 상품과 옵션 상품, 카테고리 필터, 미니 장바구니, 장바구니, 결제를 시험합니다. 적절한 테스트 환경에서 상품 추가, 수량 변경, 쿠폰 입력, 결제 수단 선택을 포함합니다. 초기 화면이 뜬 뒤의 반응성도 측정합니다. 옵션 스크립트는 첫 화면이 빨라도 쇼핑을 느리게 만들 수 있습니다.
장바구니 프래그먼트에 관한 오래된 일괄 조언을 피합니다. WooCommerce 7.8부터 wc-cart-fragments는 기본적으로 모든 경로에 등록되지 않습니다. Cart Widget 표시, 다른 스크립트의 의존성 선언, 맞춤 코드의 명시적 등록으로 나타날 수 있습니다. Mini-Cart 블록은 다른 방식이며 해당 API를 사용하지 않습니다.
수정 전에 실제 구현을 확인합니다. 위젯을 이해하지 않고 이전 스크립트를 끄면 장바구니 표시가 오래된 상태로 남을 수 있습니다. 블록으로 바꾸려면 특히 맞춤 상품 추가 동작의 호환성과 스타일을 점검해야 합니다. 이론적인 절감 때문에 잘못된 주문 상태를 표시해서는 안 됩니다.
상품 갤러리에는 별도 이미지 규칙이 필요합니다. 첫 번째 보이는 이미지를 신속히 로드하고 크기를 확보하며 모든 영상과 확대 기능을 즉시 초기화하지 않습니다. 선택 시 다른 미디어를 사용할 수 있게 합니다. 옵션 변경 후 이미지, 가격, 재고가 함께 맞는지 확인합니다.
수정 작업을 반복 가능한 배포 절차로 만듭니다
변경마다 템플릿, 의심 원인, 정확한 설정이나 코드, 복구 방법, 측정값을 기록합니다. 성능 체크리스트로 추적하고 판단 근거가 되는 브라우저 기록을 보관합니다.
업데이트 후 빈 캐시와 준비된 캐시에서 같은 작업을 반복합니다. 점수 개선을 해석하기 전에 실패한 요청, JavaScript 오류, 오래된 콘텐츠, 폼을 확인합니다. 실제 데이터를 기기와 템플릿별로 관찰해 한 페이지의 개선이 다른 페이지의 악화를 숨기지 않게 합니다.
새 플러그인과 큰 테마 변경은 배포 전에 검토하고 업무 기능이 바뀌면 목록도 갱신합니다. 플랫폼 안내에서 플랫폼 특성과 공통 브라우저 문제를 구분할 수 있습니다. 다음 변경은 측정한 병목 하나와 유지해야 할 동작을 정한 뒤 두 가지를 함께 시험합니다.
