워드프레스 느려졌다면 플러그인 수부터?

워드프레스가 느려졌다고 플러그인 수부터 줄이면, 실제로 영향을 주는 기능을 놓칠 수 있습니다. 개수가 적어도 플러그인 하나가 모든 페이지에서 큰 파일을 불러온다면 이야기가 달라집니다. 블로그 글을 열 때마다 느리다면, 설치된 개수와 실제로 불러오는 파일 중 무엇을 봐야 할까요?

이 글은 “어떤 파일을 확인하고, 바꾼 뒤 어떻게 다시 비교하는가”라는 실행 절차를 다룹니다. 플러그인을 남길지 지울지 판단하는 기준 자체는 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 따로 정리했습니다. 기준이 먼저 궁금하시면 그 글을 먼저 읽고 오셔도 좋습니다.

개수가 적은데 왜 느릴까요?

플러그인 수부터 줄여야 하는 것은 아닙니다. 개수만으로 페이지에 추가되는 작업량을 알 수 없기 때문입니다. 플러그인은 기능에 따라 페이지를 만들 때 작업을 수행하거나, 방문자 화면에 필요한 파일을 불러옵니다. 방문자에게 보내는 파일이 크면 해당 페이지가 불러와야 할 데이터도 늘어납니다. 플러그인이 늘수록 이런 작업이 더해질 여지는 있지만, 모든 플러그인이 같은 일을 하지는 않습니다.

플러그인이 방문자 화면에 파일을 싣는 방식은 워드프레스가 정해 둔 절차를 따릅니다. 개발자 문서의 wp_enqueue_script 항목을 보면, 프런트엔드 화면용 스크립트는 wp_enqueue_scripts 훅에서 등록하고 관리자 화면용은 admin_enqueue_scripts를 쓰도록 안내합니다. 관리자 화면에서만 쓰는 파일과 방문자에게 내려가는 파일이 코드 단계에서 나뉜다는 뜻입니다. 다만 플러그인을 어떻게 만들었는지에 따라 이 구분이 얼마나 지켜지는지는 달라질 수 있어서, 결국 실제 요청을 눈으로 확인하는 편이 확실합니다.

글을 읽는 방문자에게 영향을 주는 파일인지, 관리자 화면에서만 쓰이는 기능인지도 구분해야 합니다. 방문자가 보는 페이지에서 쓰이지 않는 기능이라면, 그 페이지의 파일 다운로드와 바로 연결되지 않습니다. 같은 개수라도 어떤 기능을 설치했는지에 따라 방문자가 받는 파일은 달라집니다.

파일은 어느 페이지에서 불러올까요?

특정 페이지에서만 쓰는 기능과 모든 페이지에서 쓰는 기능은 영향을 받는 범위가 다릅니다. 한 페이지에서만 필요한 파일은 그 페이지를 열 때의 부담으로 좁혀 볼 수 있습니다. 모든 페이지에 실리는 큰 파일이라면, 블로그 글과 홈페이지를 열 때마다 내려받는 대상이 됩니다.

브라우저의 개발자 도구에서 네트워크 목록을 열면 페이지가 요청한 파일을 하나씩 볼 수 있습니다. 느리다고 느낀 페이지를 열고, 파일 이름과 크기, 어느 페이지에서도 다시 나타나는지를 살펴봅니다. 파일 이름만으로 플러그인과 연결되지 않으면 경로를 보고, 해당 플러그인의 기능이 쓰이는 위치와 대조합니다. 이 목록은 방문자 화면에서 불러온 파일을 보여 주며, 서버 안에서 수행한 작업까지 보여 주지는 않습니다.

네트워크 목록은 이렇게 엽니다

크롬 기준으로 설명드리면, 아래 순서로 보시면 됩니다. 캐시를 끄는 이유는 이미 저장된 파일이 목록에서 빠지거나 크기가 0처럼 보이는 것을 막기 위해서입니다.

1. 느리다고 느낀 글을 열고 F12(또는 마우스 오른쪽 → 검사)로 개발자 도구를 연 뒤 Network 탭을 고릅니다.
2. 상단 설정 막대에서 Disable cache에 체크합니다. 개발자 도구가 열려 있는 동안에만 적용됩니다.
3. 페이지를 새로고침해 요청 목록을 다시 채웁니다.
4. 목록 머리글의 Size를 눌러 큰 파일이 위로 오게 정렬합니다.
5. Filter 칸에 /wp-content/plugins/를 입력하면 플러그인 폴더에서 내려온 파일만 남습니다. 폴더 이름이 곧 어떤 플러그인인지 알려 주는 단서가 됩니다.
6. 크기 기준으로 좁히고 싶으면 Filter 칸에 larger-than:100k처럼 입력합니다. 다른 조건은 공백으로 이어 쓰면 함께 적용됩니다.

Size 칸에는 전송된 크기가 보이고, 압축을 푼 뒤의 크기는 그보다 클 수 있습니다. 방문자가 실제로 내려받는 양은 전송 크기이니, 비교할 때는 늘 같은 쪽을 보세요. 메뉴 이름과 위치는 크롬 버전에 따라 조금 다를 수 있으며, 자세한 내용은 Chrome DevTools Network 레퍼런스에서 확인할 수 있습니다.

어느 정도를 큰 파일로 볼지는 공식 기준이 따로 있지 않습니다. 이 글에서는 편의상 압축 전송 기준으로 100KB를 넘는 스크립트나 스타일 파일을 먼저 의심해 보는 선으로 잡았습니다. 이 선은 정답이 아니라 후보를 줄이기 위한 출발점입니다. 100KB보다 작아도 모든 페이지에 겹쳐 실리면 합산이 커지니, 크기와 함께 어느 페이지에서 나타나는지를 같이 봐 주세요.

참고로 이미지 파일이 목록 맨 위를 차지한다면 플러그인보다 이미지를 먼저 봐야 합니다. 그 경우는 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유에서 이어서 확인하시면 됩니다.

하나가 여러 개보다 무거울까요?

모든 페이지에서 큰 파일을 불러오는 플러그인 하나는 가벼운 플러그인 여러 개보다 영향이 클 수 있습니다. 설치 목록에서 개수를 세는 것만으로는 이 차이가 드러나지 않습니다. 속도 때문에 고를 대상은 플러그인 이름보다, 해당 파일이 실제로 불러와지는 페이지와 크기로 좁혀집니다.

플러그인 유형별로 어디서 부담이 생기기 쉬운지 정리하면 이렇습니다. 아래는 일반적인 경향을 정리한 것이고, 실제 파일 크기와 로딩 방식은 플러그인과 설정마다 다르니 반드시 내 사이트에서 확인해 보셔야 합니다.

유형	주로 불러오는 파일	영향이 커지는 경우
슬라이더	자바스크립트, 스타일, 슬라이드용 이미지	첫 화면 슬라이드 이미지가 LCP 요소가 되는 홈페이지
페이지 빌더	레이아웃용 스크립트·스타일 여러 개	빌더로 만들지 않은 글에도 같은 파일이 실릴 때
폼	입력 검증 스크립트, 스타일, 외부 서비스 스크립트가 붙는 경우도 있음	폼이 없는 글에도 파일이 실릴 때

슬라이더는 파일 자체보다 첫 화면 이미지와 맞물릴 때 체감이 큽니다. 빌더는 페이지마다 쓰는 범위가 넓어서 “모든 페이지에 실리는지”가 핵심입니다. 폼은 기능이 연락 페이지 하나에만 필요한 경우가 많아 사용 범위를 따지기 가장 쉬운 유형입니다.

큰 파일이 여러 페이지에 반복해 나타난다면, 어떤 기능이 그 파일을 쓰는지부터 짚어봅니다. 특정 페이지에서만 나타난다면, 전체 사이트 문제로 묶지 않고 그 페이지의 기능을 살펴봅니다. 파일 요청에서 단서가 없다면, 플러그인 개수만 근거로 삭제 대상을 정하지 않습니다.

결과가 다르게 보이는 예외

목록만 봐서는 판단이 어긋나는 경우가 몇 가지 있어서 미리 말씀드립니다.

• 조건부 로딩: 플러그인이나 테마가 특정 페이지에서만 파일을 싣도록 만들어져 있으면, 홈페이지에서 안 보이던 파일이 글이나 연락 페이지에서만 나타납니다. 한 페이지만 보고 “이 플러그인은 안 쓰인다”고 결론 내리지 말고 홈, 글, 보관함 페이지를 각각 열어 보세요.
• 캐시·최적화 플러그인의 합치기: 파일을 하나로 합치거나 파일 이름을 바꾸는 설정을 쓰면 /wp-content/plugins/ 필터에 원래 플러그인 파일이 안 나올 수 있습니다. 이때는 합쳐진 파일이 /wp-content/cache/ 같은 다른 경로에 있는지 함께 봅니다. 경로 이름은 사용하는 플러그인마다 다릅니다.
• 로그인 상태 차이: 관리자로 로그인한 채 열면 관리 막대 등 방문자에게는 없는 파일이 추가됩니다. 비교는 시크릿 창이나 로그아웃 상태로 하는 편이 정확합니다.
• 서버 쪽 부하: 네트워크 목록에 작은 파일만 보여도, 서버에서 페이지를 만드는 데 오래 걸리는 플러그인이 있을 수 있습니다. 이 경우는 파일 크기가 아니라 문서 요청의 대기 시간(TTFB)에서 드러납니다. 이 부분은 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것에서 나눠 보시길 권합니다.

저라면 모든 페이지에 실리는 큰 파일을 찾았을 때, 설치 개수보다 그 기능의 사용 범위를 먼저 따져보겠습니다. 기능을 바꾸기로 했다면 백업해 둔 뒤 하나만 변경하고, 같은 페이지를 다시 열어 파일 요청을 비교합니다. 플러그인을 꺼도 설치 파일은 남으며, 삭제는 그 파일을 제거하는 별개의 작업입니다.

바꾸기 전에 할 일

가능하면 스테이징 사이트나 복사본에서 먼저 해 보시길 권합니다. 운영 중인 사이트라면 방문자가 적은 시간에 하고, 아래 순서를 지켜 주세요. 한 번에 하나만 바꿔야 어느 변경 때문에 달라졌는지 알 수 있습니다.

1. 파일과 데이터베이스를 백업합니다.
2. 변경 전 값을 먼저 기록합니다. 같은 페이지를 3회 새로고침해 전송 크기, 요청 수, 완료 시간을 적고 평균을 냅니다.
3. 관리자 화면의 플러그인 > 설치된 플러그인에서 의심되는 플러그인 하나만 비활성화합니다.
4. 캐시 플러그인이나 서버 캐시를 쓰고 있다면 캐시를 비웁니다.
5. 같은 브라우저, 같은 페이지, Disable cache 체크 상태로 다시 3회 측정해 평균을 냅니다.
6. 기능이 깨진 곳이 없는지 확인한 뒤, 영구적으로 빼기로 했을 때만 삭제합니다.

전후 비교는 이런 모양이 됩니다

아래 표는 기록 방식을 보여 드리려는 예시이고, 제가 측정한 값이 아닙니다. 예를 들어 모든 페이지에 실리던 슬라이더 플러그인 하나를 껐을 때 이 정도로 나올 수 있습니다. 실제 수치는 사이트마다 다릅니다.

측정 항목 (예시)	변경 전 (3회 평균)	변경 후 (3회 평균)
전송 크기 합계	1.8MB	1.3MB
요청 수	74개	61개
페이지 완료 시간	3.4초	2.8초
LCP	3.1초	2.6초

LCP는 개발자 도구의 Performance 탭이나 PageSpeed Insights에서 볼 수 있습니다. 판단 기준은 web.dev의 LCP 문서에 있는 값을 쓰면 편합니다. 2.5초 이하면 좋음, 4초를 넘으면 나쁨이고, 그 사이는 개선 필요로 봅니다. 위 예시에서는 3.1초에서 2.6초로 줄어 기준에 가까워졌지만 아직 넘지 못한 셈입니다. 이렇게 수치가 기준선 근처에 있을 때는 3회 값이 서로 많이 흔들릴 수 있으니, 평균과 함께 가장 크게 벗어난 값도 같이 적어 두세요.

전송량이 얼마나 줄어야 개선이냐는 질문도 있을 텐데요, 정해진 정답은 없습니다. 저는 3회 측정에서 전송 크기 합계와 LCP가 함께, 그리고 매번 같은 방향으로 줄었는지를 먼저 봅니다. 한쪽만 줄었거나 회차마다 들쭉날쭉하면 변화를 단정하지 않고 조건을 다시 맞춰 재측정합니다.

플러그인이 아니라 이미지 쪽을 줄였는데도 첫 화면이 여전히 느리다면 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에서 남은 원인을 나눠 보실 수 있습니다.

워드프레스가 느려졌다면 플러그인 수보다, 영향이 의심되는 파일을 어느 페이지에서 불러오는지 살펴보는 편이 정확합니다.

확인 기준: 이 글의 절차와 메뉴 이름은 2026년 10월 10일에 Chrome DevTools, web.dev, WordPress 개발자 문서를 열어 확인한 내용을 바탕으로 정리했습니다. 크롬이나 워드프레스 버전에 따라 메뉴 위치와 이름은 다를 수 있습니다. 작성자 정보는 사이트의 About 페이지에서 보실 수 있습니다.

• NAS 워드프레스 운영 가능한가 직접 확인해본 결과 정리
• 워드프레스 첫 화면이 느려졌을 때 먼저 확인할 것
• 워드프레스 카테고리 개수와 SEO 최적화 설정
• 갑자기 느려진 워드프레스, 어디부터 손대야 할까