갑자기 느려진 워드프레스, 어디부터 손대야 할까

사이트가 느려지면 플러그인부터 지우고 싶어지지만, 갑자기 느려진 원인은 이미지일 수도 서버 응답일 수도 있어서 어디부터 손댈지가 달라집니다.⠀

새로고침을 두세 번 해도 그대로라서 캐시 플러그인 설치와 사진 교체를 한꺼번에 해 보면, 무엇이 속도를 바꿨는지 알 길이 사라집니다.⠀

다른 사이트는 멀쩡히 열리는데 내 사이트만 느릴 때, 호스팅 업체에 문의하기 전에 혼자 짚어 볼 순서는 무엇일까요?⠀

이 글은 각 원인을 깊게 파고드는 글이 아니라, 증상을 보고 어디부터 볼지 정하는 순서를 다루는 글입니다. 이미지, 플러그인, 서버 각각의 상세한 절차는 장마다 이어지는 관련 글로 넘겨 두었습니다.⠀

⠀⠀⠀

⠀⠀⠀

1. 내 컴퓨터만 느린 걸까?⠀

⠀⠀⠀

체감 속도는 인터넷 환경이나 브라우저에 쌓인 캐시에 따라 달라질 수 있어서, 내 컴퓨터에서 느린 것만으로 사이트 문제라고 보기는 어렵습니다.⠀

같은 브라우저에서 새로고침만 반복하면 저장된 캐시가 다시 쓰일 수 있어 비교가 되지 않습니다.⠀

평소 쓰던 브라우저 말고 다른 브라우저를 하나 더 열고, 스마트폰에서도 같은 페이지 주소를 띄워 봅니다.⠀

비교할 때는 같은 페이지 주소를 정해 두고 기기만 바꿔 가며 여는 편이 헷갈리지 않습니다.⠀

⠀⠀⠀

다른 브라우저나 스마트폰에서는 금방 열린다면 내 컴퓨터의 캐시나 네트워크 쪽을 먼저 의심해 볼 수 있습니다.⠀

반대로 어느 기기에서 열어도 똑같이 느리다면 그때부터 사이트 쪽 점검이 시작됩니다.⠀

PageSpeed Insights 같은 외부 측정 도구는 통제된 환경에서 페이지를 불러오기 때문에, 이 단계에서 한 번 돌려 두어도 좋습니다.⠀

⠀⠀⠀

사이트 쪽이라고 판단되면 다음으로 가를 것은 느린 범위입니다.⠀

메인 화면은 바로 뜨는데 특정 글 하나만 느리다면 그 글에 들어간 이미지나 삽입된 콘텐츠부터 살펴보는 것이 순서입니다.⠀

메인이든 글이든 모든 페이지가 느리다면 서버, 캐시, 플러그인처럼 페이지 전체가 함께 쓰는 요소를 먼저 봐야 합니다.⠀

어느 쪽인지 애매하다면 느린 글과 메인 화면을 각각 PageSpeed Insights에 넣어 결과를 따로 받아 봅니다.⠀

⠀⠀⠀

새 글을 발행한 날 밤 스마트폰으로 그 글을 열어 본 운영자라면, 그 글만의 문제인지부터 가려 두는 편이 좋습니다.⠀

비교할 페이지는 메인, 최근 글, 이미지가 많은 글처럼 성격이 다른 곳으로 두세 개 골라 두면 차이가 잘 보입니다.⠀

다만 기기를 바꿔 열어 보는 것만으로 원인이 드러나지는 않으며, 어디부터 볼지 방향이 정해질 뿐입니다.⠀

⠀⠀⠀

⠀⠀⠀

2. 사진 원본을 그대로 올렸다⠀

⠀⠀⠀

스마트폰이나 카메라로 찍은 고화질 사진을 손대지 않고 올리면 한 장의 파일 크기가 상당히 커질 수 있습니다.⠀

사진이 여러 장 들어간 후기 글이라면 그 글을 열 때 받아야 할 데이터도 장수만큼 불어납니다.⠀

미디어 라이브러리에서 이미지를 눌러 첨부 파일 상세를 열면 파일 크기가 나오니, 유독 큰 파일이 섞였는지부터 봅니다.⠀

1장에서 특정 글만 느리다고 가려 두었다면 그 글의 이미지부터 이 순서로 살펴봅니다.⠀

‘유독 크다’를 가르는 공식 기준 수치는 없어서, 저는 파일 용량보다 먼저 표시 크기와 실제 픽셀 수를 견주어 봅니다. 아래는 그 비교 방법과 예시 기준입니다.⠀

• 첨부 파일 상세에 나오는 가로·세로 픽셀(예: 4000×3000)을 확인합니다. 이어서 글에서 그 사진이 실제로 보이는 가로 폭을 확인합니다. 브라우저에서 사진 위에 오른쪽 클릭 후 검사를 누르면 표시 크기가 나옵니다.
• 예를 들어 본문 폭이 800px인 테마이고 스마트폰처럼 화면 배율이 2배인 기기까지 생각한다면, 가로 1600px 안팎이면 충분합니다. 이보다 훨씬 큰 원본이 그대로 들어가 있다면 줄일 여지가 큽니다.
• 용량은 같은 기준으로, 본문 사진 한 장이 수백 KB를 넘어 1MB에 가까워진다면 의심해 볼 만하다고 잡아 둡니다(예시 기준이며 사진 내용과 형식에 따라 달라집니다).
• 줄인 뒤에는 같은 글 주소로 다시 측정해, 이미지 요청의 전송량이 실제로 줄었는지 확인합니다.

크기를 고르고 교체하는 절차는 사진 많은 워드프레스 속도 개선하는 방법에, 어느 이미지 요청이 느린지 보는 방법은 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유에 정리해 두었습니다. 업로드한 사진 하나가 여러 파일로 저장되거나 -scaled 파일이 생겨서 헷갈린다면 사진 한 장인데 썸네일 파일이 여러 개 생기는 이유와 워드프레스 -scaled 파일이 생기는 이유와 원본 보존 확인 방법을 함께 보시면 됩니다.⠀

⠀⠀⠀

업로드 전에 화면에 실제로 보일 크기로 사진을 줄이고 WebP나 AVIF 같은 형식으로 저장하는 것이 흔히 쓰는 방법입니다.⠀

AVIF는 WordPress 6.5부터 코어에서 업로드와 변환을 기본으로 지원합니다.⠀

다만 이 기능이 동작하려면 서버의 ImageMagick이나 GD가 AVIF를 처리할 수 있어야 합니다.⠀

AVIF 업로드가 되지 않는다면 서버 설정을 직접 건드리기보다 호스팅 업체에 지원 여부를 먼저 물어보는 편이 안전합니다.⠀

업체에 묻기 전에 관리자 화면의 도구 > 사이트 상태 > 정보 탭에서 ‘미디어 처리’ 항목을 펼치면 지원 형식 목록에 AVIF가 있는지 직접 볼 수 있습니다. WordPress 개발팀의 안내에 따르면 방문자 브라우저에 따라 AVIF를 못 보여 주는 경우도 있어서, 미지원 브라우저 비중이 큰 사이트라면 대체 이미지 방안을 따로 생각해야 합니다(Make WordPress: WordPress 6.5 adds AVIF support).⠀

⠀⠀⠀

AVIF로 올린 이미지도 다른 형식과 마찬가지로 반응형 이미지와 기본 lazy loading의 대상이 됩니다. 다만 첫 화면 이미지의 우선순위 처리는 버전과 테마에 따라 다를 수 있어서, 실제 출력된 HTML에서 확인하는 편이 정확합니다.⠀

다만 형식만 WebP나 AVIF로 바꿨다고 사이트 전체 속도가 크게 달라지는 것은 아닙니다.⠀

⠀⠀⠀

한 글에 들어간 이미지 수가 많다면 장수부터 줄여 보는 것이 좋습니다.⠀

반대로 몇 장 안 되는데 느리다면 본문 폭보다 훨씬 큰 원본이 그대로 들어가 있지 않은지 표시 크기를 살펴봅니다.⠀

화면 아래쪽 이미지를 스크롤할 때 불러오는 Lazy Load 설정이 꺼져 있지 않은지도 워드프레스 기본 동작과 최적화 플러그인 설정, 두 곳에서 봐 둡니다.⠀

Lazy Load가 켜져 있어도 첫 화면에 뜨는 사진 한 장이 느리다면, 그 사진의 크기를 줄이는 쪽이 먼저입니다.⠀

두 곳을 나눠 보는 이유는 설정 위치가 다르기 때문입니다.⠀

• 워드프레스 기본 lazy loading: 관리자 메뉴에 켜고 끄는 스위치가 따로 없습니다. 5.5부터 이미지 태그에 width와 height 속성이 있으면 loading=”lazy”가 붙고, 끄려면 wp_lazy_loading_enabled 필터 같은 코드를 써야 합니다. 그래서 확인은 글을 연 뒤 이미지 요소를 검사해 loading 속성이 붙어 있는지 보는 방식이 가장 빠릅니다(Make WordPress: Lazy-loading images in 5.5).
• 캐시·최적화 플러그인: 플러그인마다 이미지나 미디어 관련 탭에 Lazy Load 항목이 따로 있고 이름과 위치가 제각각입니다. 플러그인 설정에서 켜져 있는지, 그리고 첫 화면 이미지가 제외 대상에 들어 있는지 함께 봅니다.
• 첫 화면의 가장 큰 이미지에는 lazy loading을 피하는 편이 좋습니다. web.dev는 LCP 이미지에 lazy loading을 쓰면 불필요한 로딩 지연이 생겨 LCP에 나쁜 영향을 준다고 설명합니다(Optimize Largest Contentful Paint).

⠀⠀⠀

⠀⠀⠀

3. 플러그인 일괄 삭제는 그만⠀

⠀⠀⠀

워드프레스는 플러그인 하나로 기능을 붙일 수 있어 편하지만, 플러그인이 늘수록 페이지를 열 때마다 처리할 작업도 함께 늘어날 수 있습니다.⠀

그래서 플러그인을 줄이라는 조언이 흔한데, 갑자기 느려진 경우라면 개수보다 최근 변화가 더 가까운 단서일 수 있습니다.⠀

플러그인 목록에서 최근 설치하거나 업데이트한 항목이 있는지, 느려지기 시작한 날과 겹치는지부터 맞춰 봅니다.⠀

⠀⠀⠀

어제까지 멀쩡하던 사이트가 어떤 플러그인을 설치한 뒤부터 느려졌다면, 정상이던 시점과 느려진 시점 사이에 바뀐 것만 추려 보면 됩니다.⠀

이것저것 한꺼번에 지우기보다 이 차이부터 보는 편이 원인에 닿기 쉽고, 삭제가 필요해 보여도 사이트 전체를 백업한 뒤에 진행하는 것이 안전합니다.⠀

⠀⠀⠀

방문자 화면을 건드리지 않고 시험하려면 Health Check & Troubleshooting 플러그인의 문제 해결 모드가 있습니다.⠀

도구 메뉴의 사이트 건강에서 문제 해결 탭으로 들어가 이 모드를 켤 수 있습니다.⠀

켜는 순간 관리자 본인의 브라우저 세션에서만 모든 플러그인이 꺼지고 기본 테마로 바뀌며, 쿠키 방식이라 다른 방문자에게는 사이트가 평소대로 보입니다.⠀

플러그인이 모두 꺼진 상태에서 속도가 돌아온다면 플러그인이나 테마 쪽에, 그대로라면 서버 쪽에 무게를 두고 볼 수 있습니다.⠀

플러그인 페이지에는 이 설정이 현재 사용자 계정에만 적용되고 모드를 해제하거나 로그아웃할 때까지 유지된다고 적혀 있습니다. 그래도 사이트를 건드리는 도구이니 사용 전에 백업을 해 두는 편이 안전합니다(Health Check & Troubleshooting).⠀

⠀⠀⠀

어느 플러그인이 무거운지 더 좁히고 싶다면 Query Monitor라는 무료 플러그인도 있습니다.⠀

페이지를 불러올 때 실행되는 데이터베이스 쿼리와 PHP 오류, HTTP 요청을 추적하고, 느린 쿼리와 중복 쿼리를 표시해 줍니다.⠀

각 쿼리가 코어, 테마, 어느 플러그인에서 나왔는지 구성요소별로 나눠 보여 주어 느린 쿼리의 출처를 짚기 쉽습니다.⠀

결과를 볼 때는 한 구성요소에 쿼리 시간이 몰려 있는지, 여러 곳에 고르게 퍼져 있는지부터 가려 보세요. 하나에 몰려 있다면 그 플러그인을 끄고 비교해 볼 이유가 생기고, 고르게 퍼져 있다면 특정 플러그인보다 서버나 데이터베이스 상태를 의심하는 쪽이 낫다고 봅니다. 숫자 자체보다 이런 분포가 다음 행동을 정해 줍니다.⠀

⠀⠀⠀

다만 문제가 되는 플러그인 하나를 찾아 끈다고 해서 사이트 전체가 크게 빨라진다고 장담할 수는 없습니다.⠀

테마를 바꾼 직후부터 느려졌다면 플러그인보다 테마 쪽을 먼저 의심해 볼 수 있습니다.⠀

끈 뒤에는 같은 페이지를 다시 열어 보고 어떤 플러그인을 언제 껐는지 적어 둡니다.⠀

플러그인 개수 대신 무엇을 기준으로 걸러야 하는지는 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 따로 다뤘습니다.⠀

⠀⠀⠀

⠀⠀⠀

4. 이미지를 줄여도 느린데 왜?⠀

⠀⠀⠀

속도라고 하면 화면에 글과 사진이 뜨는 시간을 먼저 떠올리게 됩니다.⠀

그 앞 단계에는 서버가 요청을 받아 응답을 돌려주기까지의 시간이 있고, 이를 재는 지표가 TTFB입니다.⠀

PageSpeed Insights에서는 진단 항목의 Server Response Time 인사이트에서 이 값을 볼 수 있습니다.⠀

이 값이 ‘길다’는 기준은 web.dev가 제시한 수치를 따릅니다.⠀

TTFB	판단	이 글에서의 분기
0.8초 이하	좋음	서버 응답은 일단 두고 이미지·렌더링 구간을 봅니다
0.8초 초과 ~ 1.8초 이하	개선 필요	이미지와 서버를 함께 보되 플러그인 비교(3장)를 먼저 해 봅니다
1.8초 초과	나쁨	이미지를 줄여도 한계가 있으니 서버 쪽(아래)을 우선합니다

기준값은 web.dev의 TTFB 문서에 있고, 마지막 열의 분기는 이 글에서 정한 작업 순서입니다. PageSpeed Insights 말고 브라우저 개발자 도구의 Network 탭에서 문서(HTML) 요청을 눌러 서버 응답을 기다린 시간을 봐도 대략 가늠할 수 있습니다.⠀

⠀⠀⠀

서버 응답 자체가 길게 나온다면 이미지를 줄이고 디자인을 가볍게 다듬어도 개선되는 폭에 한계가 있습니다.⠀

이때 살펴볼 곳은 호스팅의 서버 환경, PHP 설정, 데이터베이스 상태, 그리고 서버에 걸리는 부하입니다.⠀

⠀⠀⠀

3장의 문제 해결 모드로 플러그인을 모두 꺼도 이 값이 그대로라면 서버 쪽일 가능성에 더 무게가 실립니다.⠀

PHP 설정은 사이트 전체에 걸리는 부분이라 바꾸기 전에 백업을 하거나 호스팅 업체에 먼저 문의하는 편이 안전합니다.⠀

무엇을 보라는 건지 막막하실 수 있어서 위치를 적어 둡니다. 관리자 화면의 도구 > 사이트 상태 > 정보 탭에서 서버 항목을 펼치면 PHP 버전, 메모리 제한, 최대 실행 시간 같은 값을 볼 수 있습니다(워드프레스 버전에 따라 항목 구성은 다를 수 있습니다). 먼저 PHP 버전이 호스팅에서 지원하는 비교적 최근 버전인지, 메모리 제한이 너무 낮지 않은지 정도만 확인하고, OPcache 사용 여부는 호스팅 관리 화면이나 업체 문의로 알아보는 편이 안전합니다.⠀

방문자가 늘어난 시기부터 느려지기 시작했다면 이미지보다 서버 부하 쪽에 무게를 두고 보는 것이 맞을 수 있습니다.⠀

반대로 방문자 수는 그대로인데 특정 날부터 느려졌다면 앞에서 본 플러그인 변경 이력과 날짜를 맞춰 보는 쪽이 먼저입니다.⠀

⠀⠀⠀

필드 데이터의 TTFB에는 리디렉션 지연이 포함되지만, 실험실 도구는 최종 URL만 재는 경우가 많습니다.⠀

두 값이 크게 다르게 나온다면 주소가 여러 번 넘어가는 리디렉션이 끼어 있지 않은지 같이 봐 둘 만합니다.⠀

⠀⠀⠀

호스팅 관리 화면의 자원 사용량 표시는 업체마다 달라서, 위치를 모르겠다면 느려진 시간대의 부하 기록을 업체에 요청해 볼 수 있습니다.⠀

다만 호스팅을 옮기는 것만으로 느림이 모두 풀리지는 않으며, 플러그인의 느린 쿼리가 원인이라면 서버를 바꿔도 같은 쿼리가 그대로 돌아갑니다.⠀

호스팅 이전이나 PHP 버전 변경처럼 되돌리기 번거로운 작업은 점검 순서의 맨 뒤에 두는 편이 안전합니다.⠀

이미지를 줄인 뒤에 TTFB와 LCP를 어떻게 나눠 보고 다음 점검 대상을 고르는지는 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서 이어서 다룹니다. 이 글에서는 어느 쪽으로 갈지 정하는 데까지만 짚어 둡니다.⠀

⠀⠀⠀

⠀

⠀⠀⠀

5. 점수보다 세부 숫자를 적었다⠀

⠀⠀⠀

개선을 시작하기 전에 Google PageSpeed Insights에 주소를 넣고 모바일과 데스크톱 결과를 각각 남겨 둡니다.⠀

결과 화면에는 통제된 환경에서 잰 실험실 데이터와 실제 사용자 경험을 담은 필드 데이터가 함께 나옵니다.⠀

필드 데이터는 Chrome 사용자 경험 보고서, 즉 CrUX에서 가져온 값입니다.⠀

여기에는 최근 28일 동안의 FCP·LCP·INP·CLS와 실험적 지표인 TTFB가 담깁니다.⠀

⠀⠀⠀

점수 하나보다 먼저 볼 것은 LCP·CLS·INP와 서버 응답 같은 세부 항목입니다.⠀

공식 문서가 정한 좋음 기준은 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하입니다.⠀

이 값은 실제 방문자 데이터의 75번째 백분위수로 평가하며, 세 지표가 모두 기준을 충족해야 전체 평가가 좋음으로 표시됩니다.⠀

기준은 web.dev의 Web Vitals 문서에서 확인할 수 있습니다. 이 문서는 모바일과 데스크톱을 나누어 평가한다고 설명하므로, 기록할 때도 기기별로 따로 적어 두는 편이 좋습니다.⠀

⠀⠀⠀

실험실 데이터는 조건이 고정돼 있어 원인을 찾는 데 쓰기 좋고, 필드 데이터는 방문자가 실제로 겪은 속도를 보여 줍니다.⠀

그래서 설정을 바꾼 직후의 변화는 실험실 값으로 먼저 보고, 필드 값은 28일 단위로 쌓이는 흐름을 두고 봐야 합니다.⠀

⠀⠀⠀

같은 느림이라도 LCP가 늦은데 서버 응답은 짧다면 큰 이미지 쪽을, 서버 응답부터 길다면 호스팅과 데이터베이스 쪽을 먼저 봐야 합니다.⠀

이 두 숫자를 나란히 적어 두면 WebP 변환부터 할지, 호스팅 업체에 문의부터 할지가 갈립니다.⠀

개인적으로는 이미지를 줄였는데도 LCP가 2.5초를 넘는다면 서버 응답 값부터 의심하는 게 맞다고 봅니다.⠀

다만 LCP는 서버 응답 하나로만 늦어지지 않습니다. web.dev는 LCP를 TTFB, 리소스 로딩 지연, 리소스 로딩 시간, 요소 렌더링 지연 네 구간으로 나누고, 이상적인 비율을 TTFB 약 40%, 로딩 시간 약 40%, 두 지연 구간은 각각 10% 미만으로 안내합니다(Optimize Largest Contentful Paint). 그래서 TTFB가 0.8초 이하로 괜찮은데 LCP만 길다면, 서버보다 이미지 발견이 늦거나 그리는 작업이 늦은 것은 아닌지 그 구간을 같이 봅니다.⠀

⠀⠀⠀

이 글에서 쓰는 판별은 아래처럼 정리됩니다. 숫자 조합은 기준값을 바탕으로 만든 예시이며, 실제 사이트에서는 값이 다르게 나올 수 있습니다.⠀

증상 조합 (예시)	의심 순서	먼저 갈 곳
LCP 3.6초, TTFB 0.4초, 첫 화면 사진이 큼	이미지	2장, 사진 많은 워드프레스 속도 개선하는 방법
LCP 3.6초, TTFB 2.0초	서버·캐시·플러그인	3장 문제 해결 모드 비교, 4장 서버 점검
LCP 3.2초, TTFB 0.5초, 이미지는 이미 작음	로딩 지연·렌더링 지연	lazy loading 설정 확인, 이미지 최적화 후 느릴 때 확인하는 방법

⠀⠀⠀

캐시 플러그인을 설치하거나 파일을 지우기 전에 지금 값을 적어 두고, 한 번에 하나만 바꾼 뒤 같은 페이지를 다시 잽니다.⠀

캐시 설정과 이미지 교체를 같은 날 함께 하면 어느 쪽이 LCP를 움직였는지 가려내기 어렵습니다.⠀

다만 기록을 남긴다고 속도가 빨라지는 것은 아니고, 다음에 무엇을 되돌릴지 고를 근거가 생길 뿐입니다.⠀

⠀⠀⠀

⠀⠀⠀

첫 기록에는 LCP 값 옆에 진단 항목 Document request latency 인사이트의 수치를 함께 적어 둡니다.⠀

그다음 하나만 바꾸고 같은 주소를 같은 모바일 조건으로 다시 측정해 두 줄을 나란히 남깁니다.⠀

측정값은 회차마다 조금씩 흔들리기 때문에 한 번의 숫자로 결론을 내리지 않는 편이 안전합니다. 같은 URL을 같은 모바일 조건으로 3회 이상 재고 중앙값을 적어 두면, 한 번 튄 값에 휘둘리지 않고 전후를 비교할 수 있습니다. 회차 사이에 값이 크게 벌어지면 횟수를 늘리거나 시간대를 바꿔 다시 재 보세요.⠀

기록 양식 (예시 값)	1회	2회	3회	중앙값
변경 전 LCP	3.4초	3.1초	3.6초	3.4초
변경 전 TTFB	0.5초	0.4초	0.5초	0.5초
첫 화면 사진을 줄인 뒤 LCP	2.4초	2.2초	2.5초	2.4초

위 표는 양식을 보여 드리려고 만든 예시 값이고, 실제 측정 결과가 아닙니다. 이런 흐름이라면 TTFB는 그대로인데 LCP만 줄어든 셈이라 이미지 쪽이 원인이었다고 읽을 수 있습니다. 반대로 사진을 줄였는데도 두 값이 모두 그대로라면 4장의 서버 쪽으로 넘어갑니다.⠀

⠀⠀⠀

참고한 공식 문서와 확인 일자

• web.dev: Web Vitals (LCP·INP·CLS 기준)
• web.dev: Time to First Byte (TTFB 기준, 리디렉션 포함)
• web.dev: Optimize Largest Contentful Paint (LCP 하위 구간, LCP 이미지 권고)
• Make WordPress: WordPress 6.5 adds AVIF support
• Make WordPress: Lazy-loading images in 5.5
• Health Check & Troubleshooting 플러그인 페이지

위 문서들은 2026년 10월 10일에 다시 열어 내용을 확인했습니다. 공식 기준과 메뉴 이름은 바뀔 수 있으니 적용 전에 최신 문서를 한 번 더 보시길 권합니다.⠀

점검 환경 기록 양식 (예시)	적을 내용
WordPress / PHP 버전	예: 6.x / 8.x (사이트 상태 > 정보에서 확인)
테마 / 호스팅	예: 사용 중인 테마 이름 / 호스팅 종류
PageSpeed Insights 측정 시점	예: 2026-10-10, 모바일, 같은 URL 3회
수정 이력	예: 2026-10-10 기준 문서 확인 후 기준값 갱신

#LCP개선⠀