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

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

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

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

⠀⠀⠀

⠀⠀⠀

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

⠀⠀⠀

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

다만 이 기능이 동작하려면 서버의 ImageMagick이나 GD에 libavif가 포함돼 있어야 합니다.⠀

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

⠀⠀⠀

AVIF로 올린 이미지에도 반응형 이미지, Fetch Priority, 기본 lazy loading이 다른 형식과 똑같이 적용됩니다.⠀

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

⠀⠀⠀

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

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

화면 아래쪽 이미지를 스크롤할 때 불러오는 Lazy Load 설정이 꺼져 있지 않은지도 같은 자리에서 봐 둡니다.⠀

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

⠀⠀⠀

⠀⠀⠀

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

⠀⠀⠀

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

⠀

⠀⠀⠀

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

⠀⠀⠀

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

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

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

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

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

⠀⠀⠀

⠀⠀⠀

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

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

#LCP개선⠀