워드프레스 속도 개선 실무 가이드

워드프레스 속도 개선을 실무에서 구현하는 방법은 다음과 같습니다. 기준을 먼저 측정한 후 효과 순서대로 개선하세요. 서버 응답 시간과 페이지 캐싱, 그 다음 용량이 큰 히어로 이미지, 렌더링을 차단하는 CSS와 자바스크립트, 마지막으로 데이터베이스와 플러그인 로드가 순서입니다. 느린 대부분의 사이트는 이 중 2~3가지에만 막혀있지, 모두가 문제인 경우는 드뭅니다.

요약

PageSpeed Insights에서 가장 느린 템플릿을 실행하고 가장 큰 콘텐츠풀 페인트 요소를 적어두세요. 그리고 이 목록을 위에서 아래로 진행하면서 숫자가 초록색으로 바뀔 때까지 개선하세요. 기준 없이 속도를 개선하는 것은 미신입니다. 가장 느린 실제 템플릿(보통 큰 히어로 이미지가 있는 글이나 우커머스 상품 페이지)에서 세 개의 숫자를 기록하세요. Largest Contentful Paint, Interaction to Next Paint, Time to First Byte입니다.

기준을 먼저 설정해야 틀린 것을 개선하지 않습니다

속도 작업을 기준 없이 하는 것은 미신입니다. 플러그인을 건드리기 전에 가장 느린 실제 템플릿(보통 큰 히어로 이미지가 있는 글이나 우커머스 상품 페이지)에서 세 개의 숫자를 기록하세요. Largest Contentful Paint, Interaction to Next Paint, Time to First Byte입니다. 모바일 환경에서 테스트하세요. 이것이 내 기계에서는 빠르지만 고객의 방문자에게는 느린 상황을 드러내는 순간입니다.

목표값은 공식 문서에 나와있습니다, 전설이 아닙니다. Google의 web.dev 가이드에 따르면 Largest Contentful Paint는 2.5초 이하가 실제 방문의 75 백분위수에서 좋습니다. Interaction to Next Paint는 200밀리초 이하로 유지되어야 하고 레이아웃 시프트는 0.1 미만이어야 합니다. 이 숫자를 화면 옆에 포스트잇에 적어두세요.

Lighthouse 같은 실험실 도구는 반복할 수 있는 기준을 줍니다. Chrome 사용자 경험 보고서의 필드 데이터(PageSpeed Insights 맨 위에 표시됨)는 방문자가 실제로 얻은 것을 알려줍니다. 둘이 다르면 필드 데이터를 믿고 실험실 실행으로 원인을 찾으세요.

주변부 글: 이 작업 순서는 WordPress 6.5 이상에 적용됩니다. 더 오래된 설치는 이것 중 어떤 것도 상관없어지기 전에 더 많은 것을 수정해야 합니다.

서버를 먼저 수정하세요: 호스팅, PHP, Time to First Byte

모든 프론트엔드 트릭은 첫 응답 위에 있습니다. HTML이 도착하는 데 1.5초가 걸리면 어떤 이미지 압축도 당신의 Largest Contentful Paint를 구할 수 없습니다. Time to First Byte는 약한 호스팅, 구식 PHP 브랜치, 또는 모든 요청에서 처음부터 다시 빌드되는 페이지를 드러내는 숫자입니다.

이 순서대로 세 가지를 확인하세요. 현재 지원되는 PHP 브랜치를 실행하세요. 각 릴리스는 마지막 것보다 요청당 측정할 수 있을 정도로 저렴합니다. 호스트가 persistent object cache(Redis 또는 Memcached)를 제공하는지 확인하세요. 이것이 옵션, 메뉴, 쿼리에 대한 반복 데이터베이스 읽기를 제거합니다. 그리고 계획 자체를 살펴보세요. 백 명의 이웃이 있는 공유 서버는 트래픽이 급증하는 정확한 순간에 당신을 가로채울 것입니다.

많은 클라이언트 사이트를 관리하는 경우, 이것은 관리형 호스팅이 수수료를 버는 곳입니다. 호스팅, 캐싱, 성능 목표를 묶는 플랫폼은 전체 추측 범주를 제거합니다. 10Web은 Google Cloud에 WordPress를 호스팅하고 기본적으로 90+ PageSpeed 점수를 목표로 하는 한 가지 예입니다. 이것은 전담 운영 담당자 없는 소규모 에이전시에 합리적인 기본값입니다.

캐싱을 활성화하기 전에 더 큰 계획을 구매하려는 유혹을 피하세요. 캐시되지 않은 페이지를 제공하기 위해 하드웨어를 업그레이드하는 것은 같은 낭비적인 작업을 더 빠르게 하기 위해 더 많이 지불하는 것입니다.

전체 페이지 캐싱을 켜고 실제로 hit되는지 확인하세요

WordPress는 누군가 요청할 때마다 PHP와 MySQL로 각 페이지를 빌드합니다. 페이지 캐시는 완성된 HTML을 저장하고 그 파일 대신 제공합니다. 블로그, 브로셔 사이트, 포트폴리오 같은 대부분 읽는 사이트의 경우, 이 단일 변경만으로도 종종 Time to First Byte를 초 단위에서 십 밀리초 범위로 이동합니다.

하나의 페이지 캐싱 레이어를 선택하고 오직 하나만 사용하세요. 호스트 레벨 캐시, 캐싱 플러그인, CDN 캐시를 어느 것이 요청을 제공하는지 알지 못하면서 스택하는 것이 당신이 오후 내내 오래된 콘텐츠를 디버깅하게 되는 방법입니다. 뭔가 설치하기 전에 당신의 호스트가 이미 제공하는 것을 물어보세요.

그 다음 캐시가 hit되는지 확인하세요. 브라우저의 네트워크 패널을 열고 공개 페이지를 두 번 새로고침하고 응답 헤더를 읽으세요. 대부분의 캐시는 hit나 miss를 알려주고, 많은 것이 나이 값을 추가합니다. 항상 miss만 보면 캐시가 쿠키, 쿼리 문자열, 또는 로그인 상태로 우회되고, "최적화"는 장식입니다.

상점은 특별한 주의가 필요합니다. 장바구니, 결제, 계정 페이지는 절대 캐시되어서는 안 되고, 우커머스 사이트는 보통 이러한 제외를 아는 캐싱 플러그인에 의존합니다. 제외를 잘못 설정하면 고객이 서로의 장바구니를 봅니다. 이것은 느린 페이지보다 더 나쁜 문제입니다.

히어로 이미지를 축소하세요. 가장 흔한 Largest Contentful Paint 범인입니다

대부분의 느린 WordPress 페이지에서 Largest Contentful Paint 요소는 이미지입니다. 히어로, featured image, 또는 전체 너비 배너입니다. 이것이 이미지 크기가 가장 흔한 단일 실패 원인인 이유입니다. 카메라에서 직접 내보낸 4000픽셀 너비 JPEG는 1200픽셀 열에 표시될 때 레이아웃이 사용할 수 있는 것보다 몇 배 더 많은 바이트를 배송합니다.

이 순서대로 이미지 파이프라인을 진행하세요:

• 레이아웃이 정말로 표시하는 가장 큰 크기로 크기를 조정하세요. 디자이너가 내보낸 크기가 아니라.

• WebP 또는 AVIF를 제공하세요. WordPress 코어는 여러 릴리스 동안 둘 다 처리해왔습니다.

• 한 개의 큰 파일을 하드 코딩하는 대신 코어에서 responsive srcset 변형을 생성하게 하세요.

• 히어로를 lazy-load하지 마세요. 코어는 WordPress 6.3 이후로 첫 콘텐츠 이미지에서 lazy loading을 건너뛰었고 fetchpriority="high"를 추가했으니 당신의 테마나 플러그인이 그것을 실행 취소하지 않았는지 확인하세요.

• 모든 이미지에 명시적 너비와 높이를 지정하세요. 브라우저가 공간을 예약하고 레이아웃 시프트는 0에 가깝게 유지됩니다.

스크롤 아래에서 lazy loading은 올바르고 무료입니다. 스크롤 위에서는 자기 유발 지연이고, "lazy load everything" 플러그인을 설치한 후 가장 자주 나타나는 실수입니다.

전자상거래의 경우, 무게는 종종 상품 사진에서 나옵니다. 일관되고 올바른 크기의 시각 자료를 소스에서 생성하는 것이 50개의 과도하게 큰 파일을 나중에 압축하는 것보다 저렴하고, Klayn 같은 AI 상품 사진 플랫폼은 한 개의 상품 사진을 장면 세트로 변환하므로 미디어 라이브러리에 도달하기 전에 치수를 계획할 수 있습니다.

렌더링을 차단하는 CSS와 자바스크립트를 소스에서 제거하세요

서버와 히어로가 정렬되면 다음 지연은 브라우저가 그리기 전에 다운로드하고 실행해야 할 것입니다. head의 모든 스타일시트는 렌더링을 차단합니다. 모든 동기식 스크립트는 파싱을 차단합니다. 페이지 빌더와 다목적 테마는 보통의 위반자입니다. 페이지가 사용하든 안 하든 모든 기능에 대해 스타일과 스크립트를 배송하기 때문입니다.

Block 테마는 구조적 이점을 가지고 있습니다. 코어는 그 블록이 페이지에 나타날 때만 블록 스타일을 로드하므로, 일반 글은 Query Loop나 Gallery의 비용을 지불하지 않습니다. 이것이 lean Full Site Editing 테마가 번들 슬라이더와 번들 아이콘 글꼴이 있는 레거시 테마보다 앞서 시작하는 한 가지 이유입니다. Classic 페이지 빌더는 격차를 좁힐 수 있지만, 사용하지 않는 모듈을 비활성화하는 경우에만 가능합니다.

Divi는 공정한 테스트 케이스입니다. Divi 5는 더 현대적인 아키텍처로 재구축되었고 수백 개의 모듈을 배송하는데, 이것이 정확히 dynamic CSS와 critical CSS 같은 성능 설정이 당신이 배송하는 모든 사이트에서 신중한 살펴봄을 받을 자격이 있는 이유입니다.

실용적인 단계, 위험 순서대로:

• 중요하지 않은 자바스크립트를 연기하고 서드파티 스크립트(채팅 위젯, 분석, 태그 관리자)를 가능한 경우 상호작용 후에 로드하세요.

• 위 콘텐츠의 중요 CSS를 인라인하고 나머지를 비동기로 로드하세요. 캐시 도구가 지원하면.

• 폰트를 자체 호스팅하고, 부분 집합을 만들고, font-display: swap을 사용하세요. 폰트가 로드되는 동안 텍스트가 보입니다.

• 모든 페이지에서 큰 스크립트를 로드하는 모든 플러그인을 제거하거나 교체하세요. 단 한 곳에서 사용되는 기능입니다.

• 각 변경 후 테스트하세요. 적극적인 자바스크립트 연기는 깨진 메뉴나 죽은 결제 버튼의 넘버원 원인입니다.

플러그인 스택을 정리하고 데이터베이스를 쉬게 하세요

플러그인 개수는 나쁜 메트릭입니다. 중요한 것은 각 플러그인이 프론트엔드에서 로드하는 것과 모든 요청에서 하는 것입니다. 무거운 쿼리가 있는 하나의 나쁘게 작성된 플러그인은 30개의 잘 작동하는 플러그인보다 더 비용이 들 수 있습니다. staging 사본에서 Query Monitor를 사용하여 느린 쿼리, 그것을 트리거한 플러그인, 각각이 대기열에 넣는 스크립트를 보세요.

그 다음 options 테이블을 살펴보세요. 몇 년 전에 제거된 플러그인은 종종 autoload로 표시된 행을 남겨두는데, 이것은 WordPress가 모든 요청에서 메모리로 읽는다는 뜻입니다. Site Health는 autoloaded options이 대략 800 KB에 도달하면 플래그를 지정하기 시작합니다. 그 경고를 보면, 가장 큰 행을 감사하고 더 이상 실행하지 않는 플러그인의 leftovers를 정리하세요.

Post 버전, 만료된 transients, orphaned metadata는 시간이 지남에 따라 무게를 더하지만, 이것을 maintenance로 취급하세요. 실행 취소할 마지막 수정이 아닙니다. 먼저 백업하세요, staging에서 정리를 실행하세요, 다시 측정하세요. 이득은 종종 작은 사이트에서는 modest이고 몇 년의 주문과 sessions이 있는 상점에서는 중요합니다.

CDN과 추측적 로딩으로 마지막 구간을 진행하세요

콘텐츠 전송 네트워크는 static 파일을 배송하고, 종종 캐시된 HTML도, 방문자에게 가까운 위치에서 배송합니다. 아라비아어 사이트처럼 지역 전체에 퍼진 청중의 경우 기원 서버가 유럽에 있지만 만큼 지연 절약은 미용이 아닙니다. 거리는 비용이고, CDN이 그것을 단축하는 가장 저렴한 방법입니다.

WordPress 6.8은 비용이 들지 않는 것을 추가했습니다: 추측적 로딩. Speculation Rules API를 사용하여 방문자가 클릭을 시작할 때 페이지를 prefetch하므로 다음 네비게이션이 거의 즉각적으로 느껴집니다. 코어 팀은 이전 플러그인 버전을 사용하는 사이트가 WordPress 6.8 추측적 로딩 개발자 노트에 설명되어 있듯이 중앙값에서 약 1.9% Largest Contentful Paint pass rate를 개선했다고 보고합니다. 이것은 사이트당 작고 구성 없이 옵니다.

코어는 pretty permalinks가 있는 사이트에서 logged-out 방문자에 대해 활성화합니다. 플러그인이 일반 GET 요청에서 상태를 변경하는 action URL을 사용하는 경우, 설정을 더 eager하게 만들기 전에 wp_speculation_rules_href_exclude_paths 필터로 이러한 경로를 제외하세요. 당신의 카트와 분석을 확인할 때까지 기본값으로 유지하세요.

튜닝을 언제 멈출지, 그리고 먼저 어느 fix를 실행할지

WordPress 튜닝이 비용보다 더 반환하는 지점이 있습니다. 작은 상점이 매달 캐싱 제외, 플러그인 충돌, 호스팅 업그레이드로 싸우는 데 보낸다면, 솔직한 질문은 스택이 비즈니스에 맞는지입니다. WiziShop 같은 호스팅 플랫폼은 유연성의 일부를 교환하여 속도가 다른 사람의 일인 상점을 원합니다. 그리고 당신이 유지보수에 청구하는 시간에 대해 가격을 책정할 가치가 있습니다.

콘텐츠 사이트, 에이전시, RTL 프로젝트의 경우 WordPress는 여전히 올바른 도구이고, 위의 모든 것이 여전히 가치가 있습니다. 포인트는 각 클라이언트가 어느 쪽에 있는지 아는 것입니다.

오늘 가장 느린 템플릿에서 기준을 실행하세요. Time to First Byte가 800밀리초 이상이면 호스팅, PHP, 캐싱으로 시작하세요. Time to First Byte는 healthy하지만 Largest Contentful Paint가 실패하면 waterfall을 열고 히어로 이미지를 찾으세요. 둘 다 pass하고 상호작용이 sluggish하면 자바스크립트와 플러그인 스택을 보세요. 당신의 가장 나쁜 페이지가 어느 세 가지를 실패합니까?