WordPress 사이트가 왜 그렇게 느리고 속도를 높이는 편리한 가이드

게시 됨: 2021-08-19

이 글은 단순히 "워드프레스 속도를 높이는 방법" 기사가 아님 을 알려드리며 이 글을 시작하고 싶었습니다.

나는 웹에서 이미 찾을 수 있는 어떤 것도 역류시키지 않을 것입니다. 캐싱 플러그인을 설치하고, 압축을 활성화하고, CSS/js 등을 축소해야 한다고 말하지는 않겠습니다.

결국, 이러한 작업을 수행하는 방법을 이미 알고 있어야 합니다. 그렇지 않은 경우 수백 개의 다른 블로그에서 이 일반 정보를 찾을 수 있습니다.

Wordpress Tricks

대신, 이 기사에는 내 WordPress 블로그의 속도를 높이고 기본적으로 악성 액세스로 인해 내 서버가 다운되는 것을 방지하기 위해 지난 달 정도에 구현한 모든 사용자 정의/세미 사용자 정의가 포함되어 있습니다.

그리고 그것이 "거의 알려지지 않은" 이유는 내가 설명하려는 기술이 귀하가 보고 있는 트래픽 패턴에 따라 귀하의 블로그에 매우 구체적이기 때문입니다.

wpengine 참고: 블로그 속도가 느리고 웹사이트 속도를 높이는 기술적 측면을 다루고 싶지 않다면 WP 엔진과 같은 서비스에 가입 해야 합니다.

이 사람들은 WordPress 호스팅을 전문으로 하며 블로그가 가능한 한 빨리 실행되도록 합니다. 그러나 당연히 여기에는 대가가 따릅니다. 이 게시물이 머리를 넘으면 확인해야합니다. :)

어쨌든, 내가 내 블로그에 했던 일을 어떻게 그리고 왜 했는지 설명하기 전에 WordPress와 캐싱에 대한 몇 가지 기본 개념을 이해해야 하며 아래에서 설명합니다.

몇 가지 흥미로운 WordPress 사실

WordPress 속도를 높이는 방법에 대한 모든 지침을 이미 따랐다고 가정해 보겠습니다. 블로그가 활기차게 느껴집니다. Webpagetest.org는 귀하의 블로그가 지옥만큼 빠르다는 것을 알려줍니다. 다 괜찮지 않나요? 반드시 그렇지는 않습니다 .

Webpage test

나는 내 블로그에 대해 정확히 같은 느낌을 사용하곤 했다. 결국, 나는 대부분의 표준 속도 향상 프로토콜을 따릅니다. 나는 아주 적은 수의 플러그인을 실행하고 내 블로그는 인간 독자의 관점에서 정상적인 사용에서 꽤 빠르게 느껴집니다(광고 네트워크는 내 블로그를 느리게 하여 광고를 마지막에 로드합니다).

하지만 그 후 CPU 사용량 그래프를 분석하기 시작했고 트래픽 수준이 낮거나 중간임에도 불구하고 서버 부하가 높은 기간을 자주 발견했습니다. 때때로 내 서버를 사용할 수 없거나 장기간 응답하지 않을 수도 있습니다.

내가 이 통계에 주목하기 시작한 유일한 이유는 얼마 전 내 블로그와 동일한 서버에서 내 온라인 상점을 운영하고 있었기 때문입니다. 그리고 주기적으로 나는 고객들에게 가게가 매우 느리다고 불평하게 하곤 했습니다. 마침내 파고 들었을 때 최적화되고 완전히 캐시 된 WordPress 블로그가 내 서버를 무릎 꿇게하고 있음을 발견했습니다!

이야기의 교훈? 속도 테스트에서 블로그가 빠르다고 해서 모든 것이 반드시 좋은 것은 아닙니다.

다음은 WordPress 및 WP Super Cache 및 W3 Total Cache와 같은 캐싱 플러그인에 대한 몇 가지 재미있는 사실입니다.

  • WordPress 404 응답이 느립니다 . 귀하의 블로그가 존재하지 않는 페이지에 대한 액세스를 수신할 때마다 귀하의 열악한 서버는 WordPress를 로드하고, 많은 PHP 코드를 실행하고, 많은 MySQL 쿼리를 수행한 다음 사용자 정의 WordPress 404 페이지를 뱉어내야 합니다. 이것은 리소스 집약적인 작업이며 캐싱은 도움이 되지 않습니다.
  • URL에 GET 매개변수가 있으면 캐싱 플러그인이 제대로 작동하지 않습니다. 예를 들어, 나는 내 이메일 목록에 폭발적인 메시지를 보낼 때마다 내 블로그가 크롤링 속도가 느려지는 것을 확인하곤 했습니다. 정적 파일 캐싱을 사용하는 이론상 내 서버는 거의 무적이어야 합니다.

    그러나 Aweber가 URL에 추적 매개변수를 삽입하기 때문에 내 파일은 슈퍼캐시되지 않습니다. 결과적으로 WordPress는 완전히 새로운 캐시 파일(이미 존재하더라도)을 생성하고 압축하여 매번 보내야 합니다. 최악의 부분은 이러한 캐시된 파일이 한 번만 사용되어 서버 리소스가 낭비된다는 것입니다.

  • 불량 액세스는 느립니다. 악성 액세스는 기본적으로 WordPress를 로드해야 하므로 잘못된 요청으로 사이트에 스팸을 보내기로 결정한 잘못된 봇이나 크롤러가 블로그를 매우 쉽게 중단시킬 수 있습니다.
  • 캐싱 플러그인에 버그가 있거나 블로그 설정 방식과 호환되지 않을 수 있습니다 . 예를 들어, 3년 동안 나는 내 로그를 보기 시작하고 코드에서 버그를 발견할 때까지 WP Super Cache가 올바른 일을 하고 있다고 생각했습니다. 내가 설정한 방식 때문에 WP Super Cache가 내 캐시를 너무 자주 플러시하는 문제가 있었습니다.

위의 글머리 기호로 만들려는 요점은 블로그에서 비표준 액세스가 발생할 때마다 WordPress 블로그 설정에 관계없이 많은 서버 리소스를 사용한다는 것 입니다. 그리고 이러한 유형의 액세스로 인해 서버가 일반 트래픽이 아니라 무릎을 꿇게 됩니다.

악성 액세스 감지

WordPress 블로그를 최적화하는 첫 번째 핵심은 블로그가 수신하는 트래픽 패턴을 이해하는 것입니다. WordPress 사용자의 99%가 이 작업을 수행하지 않는다고 확신합니다. 대신 맹목적으로 다양한 플러그인을 따라 설치하고 모든 것이 제대로 작동한다고 가정합니다. 기분나빠하지마, 나도 똑같았어.

그래서 첫 번째 단계는 도대체 무슨 일이 일어나고 있는지 알아내는 것입니다. 이를 수행하는 방법은 여러 가지가 있지만 가장 쉬운 방법은 플러그인 WP SuperCache가 제공하는 디버그 모드를 사용하는 것입니다. 이 모드는 무엇을 합니까? 기본적으로 액세스가 WordPress(리소스 집약적)에서 직접 처리될 때마다 WP 슈퍼 캐시 로그에 표시됩니다. 이 모드를 활성화하는 방법은 다음과 같습니다.

WP Super Cache Log

WP 슈퍼 캐시 플러그인의 디버그 탭에서 "디버깅 사용" 확인란을 클릭하기만 하면 됩니다.

로깅이 활성화되면 "logfile" 링크를 클릭하면 WordPress 트래픽을 자세히 설명하는 파일로 연결됩니다. 아래 텍스트와 유사하게 보일 것입니다.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

주목해야 할 중요한 점은 이 로그에서 무언가를 볼 때마다 WordPress가 작동해야 함을 의미하기 때문에 나쁜 일이라는 것입니다. 그리고 WordPress는 리소스를 많이 사용하기 때문에 가능한 한 적은 작업을 수행하기를 원합니다.

로그에서 찾아야 할 사항

WP Super Cache 로그는 진행 중인 모든 것을 알려 주기 때문에 훌륭합니다. 그러나 무엇을 찾아야 할지 알지 못한다면 엄청난 양의 정보에 압도될 수 있습니다. 이 로그에서 주의해야 할 사항은 다음과 같습니다.

  • 404 오류 – 기본적으로 블로그에 존재하지 않는 페이지에 대한 액세스입니다. WordPress에서 처리하는 각 404 액세스는 많은 서버 리소스를 차지하므로 가능하면 이를 새싹에서 잘라내고 싶습니다.
  • 일회성 액세스 – 서버가 한 번만 사용할 페이지를 캐시 및 압축하도록 하는 요청입니다(나중에 자세히 설명).
  • 이상한 트래픽 버스트 – 일반적으로 블로그를 한 번에 망치는 봇입니다.
  • 이상한 캐싱 동작 – 캐시가 플러시되어야 할 때 플러시됩니까? 모든 상황에서 모든 것이 올바르게 캐시되고 있습니까?

2주 동안 내 블로그 트래픽을 기록한 후 아래에서 설명할 많은 비효율성을 발견했습니다.

봇이 내 기록 보관소를 망치고 있었습니다.

가장 먼저 한 일은 CPU 부하가 높은 기간 동안 서버 로그를 살펴보는 것이었습니다. 그런 다음, 정확히 같은 기간 동안 슈퍼 캐시 로그를 분석하여 재미있는 비즈니스가 진행되고 있는지 확인했습니다. 이틀에 한 번 정도 봇 그룹이 와서 내 블로그의 모든 아카이브 페이지를 동시에 망치는 것으로 나타났습니다!

이러한 아카이브 페이지는 기본적으로 캐시되지 않기 때문에 많은 동시 액세스로 인해 서버 로드가 급증하고 작업이 매우 느려졌습니다. 그리고 때로는 내 서버가 다운되기도 했습니다.

그래서 HTML 출력을 자세히 살펴보고 WordPress 헤더의 일부로 많은 아카이브 링크가 있음을 발견했습니다. 따라서 봇 및 기타 웹 크롤러가 찾아와 아카이브를 탐색하려고 합니다.

인터넷 검색을 많이 한 후 다른 웹마스터가 비슷한 문제를 겪고 있음을 발견했습니다.

귀하의 사이트에서 로드 문제가 여러 번 발견되면 프록시 서버 IP에 대한 많은 조회수가 있으며 이론은 이러한 프록시가 귀하의 사이트를 캐시하고 모든 아카이브 링크에 도달한다는 것입니다. 사이트에서 로드 문제가 발생할 때 보게 되는 많은 IP는 누군가 사이트에 액세스할 때 콘텐츠를 미리 가져오는 것처럼 보이는 기업, 교육 및 정부/군사 프록시 IP입니다.

해결 방법: 블로그의 헤더 코드에 php 문 "wp_get_archives"가 있는지 확인하고 제거하십시오. 이 작은 조각을 삭제한 후 모든 아카이브 액세스가 사라졌습니다.

봇이 존재하지 않는 파일에 액세스하고 있었습니다.

내가 알아차린 두 번째 중요한 사실은 존재하지 않는 내 서버의 파일에 액세스하는 많은 봇이 있다는 것입니다. 문제는 파일 액세스가 발생할 때마다 서버가 WordPress를 로드하고 많은 PHP 코드를 실행한 다음 404 페이지를 발행해야 한다는 것입니다.

이 문제에 대한 해결책은 .htaccess(무엇인지 모르는 경우 Google에서 확인) 파일을 편집하고 다음 행을 추가하는 것입니다.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
RewriteRule .* – [L]

이 줄이 .htaccess 파일에 삽입되면 웹 서버는 먼저 파일이 존재하는지 확인합니다. 그렇지 않은 경우 WordPress를 로드하지 않고 404 응답을 발행합니다.

봇이 존재하지 않는 URL에 액세스하고 있었습니다.

WordPress가 작성된 방식에서 불행한 점은 데이터베이스에 존재하지 않는 기사에 대한 액세스가 있는 경우 서버가 WordPress를 로드하고 많은 PHP 코드를 실행하고 많은 MySQL 조회를 수행한 후에 발행한다는 것입니다. 404 응답.

로그를 주의 깊게 살펴보면 WordPress에 도달하기 전에 제외할 수 있는 특정 액세스 패턴을 발견할 수 있습니다.

예를 들어, 많은 봇이 www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… 그리고 매번 내 서버는 WordPress를 로드하고 404 응답을 발행합니다.

따라서 WordPress가 이러한 요청을 처리하도록 하는 대신 .htaccess 파일에 다음 행을 추가했습니다.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
RewriteRule .* 404.html [L,R=404]

위의 줄에서 내 웹서버가 URL에서 "www.facebook.com/plugins"를 찾고 WordPress를 로드하지 않고 즉시 404 응답을 발행하도록 했습니다. 로그를 자세히 살펴보면 위에서 설명한 것과 같은 악성 액세스를 많이 발견할 수 있습니다. 각각에 대해 .htaccess 규칙을 작성하면 이러한 액세스가 더 이상 서버를 로드하지 않습니다.

봇이 내 댓글 링크를 망치고 있었습니다.

GET 매개변수가 있는 URL이 캐싱 플러그인에 의해 다르게 처리된다고 말한 것을 기억하십니까? 나는 "댓글에 답장" 매개변수 세트를 사용하여 내 기사를 망치는 수많은 봇이 있다는 것을 발견했습니다.

이런 일이 발생하면(캐싱 설정에 따라 다름) wordpress가 로드되고 캐시된/zip 파일이 다시는 액세스되지 않더라도 제공됩니다. 이것은 자원 낭비입니다.

내 로그에서 가져온 예
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

해결책은 이러한 GET 매개변수가 있는 모든 봇과 크롤러를 기본 기사 페이지로 리디렉션하는 것입니다. 다음은 .htaccess 파일에 추가한 코드입니다.

RewriteCond %{QUERY_STRING} 회신
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|slurp) [NC]
RewriteRule .* https://mywifequitherjob.com%{REQUEST_URI}? [엘]

이 코드는 "replytocom" GET 매개변수를 찾은 다음 WordPress에 대한 액세스 권한을 제공하기 전에 최종 URL에서 이 매개변수를 제거합니다.

크롤러가 슬래시 없이 게시물에 액세스했습니다.

왜 그런지는 모르겠지만 URL에 슬래시를 추가하지 않고 내 블로그의 기사에 합법적으로 액세스하려고 시도하는 것처럼 보이는 많은 웹 크롤러를 발견했습니다.

http://yourblog.com/article/ 과 같이 작성된 URL은 http://yourblog.com/article 과 같은 URL과 다릅니다.

결과적으로 후행 슬래시가 없는 URL이 발생하면 WordPress가 개입하여 많은 PHP 코드를 실행한 다음 후행 슬래시가 있는 기사로 301 리디렉션을 발행해야 합니다. WordPress를 사진에서 빼내려면 .htaccess 파일에 다음 규칙을 삽입하기만 하면 됩니다.

# 후행 슬래시 추가
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
RewriteRule ^(.*)$ $1/ [L,R=301]

후행 슬래시를 추가하면 CPU 리소스를 절약하는 WordPress로 이동하기 전에 올바른 URL로 301 리디렉션을 실행합니다.

WP 슈퍼 캐시에서 버그를 찾았습니다.

대부분의 사람들과 달리 저는 public_html 디렉토리의 루트에 WordPress 블로그를 설치하지 않았습니다. 또한 내 블로그의 첫 페이지는 내 "게시물"페이지도 아닙니다. 블로그를 나와 같은 방식으로 구성한 경우 캐시를 미리 로드하더라도 모든 캐시 파일이 조기에 삭제될 수 있는 버그가 WP Super Cache에 있습니다.

플러그인 작성자가 이 문제를 알고 있는지 확실하지 않지만 기본적으로 내 블로그에 스팸 댓글이 발행될 때마다 내 전체 캐시가 잘못 플러시된다는 것을 알았습니다. 항상 댓글과 트랙백 스팸을 받기 때문에 캐시가 계속 비워져 캐시 효율성이 훨씬 떨어졌습니다.

그래서 주말에 이 문제를 디버깅하고 마침내 해결 방법을 개발했습니다. 같은 문제를 겪고 계신 분이 계시다면 알려주시면 해결 방법을 알려 드리겠습니다. 여기서 이야기의 교훈은 캐싱 플러그인이 제대로 작동한다고 가정하지 않는다는 것입니다. 로그를 확인해야 합니다!

CPU 집약적 플러그인 비활성화

위의 모든 단계를 수행했더라도 WordPress 블로그에 도달하기 전에 모든 악성 액세스를 필터링하는 것은 불가능합니다.

따라서 효율적으로 처리되지 않는 사이트에 대한 조회수를 항상 받게 됩니다. 방법이 없습니다.

그러나 알아야 할 중요한 점은 대역폭 문제가 없을 가능성이 높으며 CPU 문제가 있다는 것입니다.

결과적으로(직관에 반할 수 있음) 실제로 페이지를 즉석에서 "축소" 또는 "압축"하는 것과 같이 CPU 집약적인 작업을 수행하고 싶지 않습니다. 축소 및 압축은 CPU 사용량을 희생시키면서 대역폭에 도움이 됩니다.

마지막으로 하고 싶은 일은 악성 액세스를 축소하고 캐싱하는 것입니다. 사실 GET 매개변수를 사용하여 URL을 축소하거나 압축하지 않는 것을 고려해야 합니다.

가장 중요한 것은 사이트에서 CPU를 많이 사용하는 플러그인을 실행하지 않아야 한다는 것입니다. WP-Engine에는 피해야 할 CPU 집약적인 플러그인 목록이 많이 있습니다.

내 플러그인 목록을 정독하면서 "유사한 게시물" 플러그인을 사용하고 있음을 알았습니다. 그리고 소스 코드를 살펴보았을 때 플러그인이 전체 텍스트와 비교하여 CPU 소모가 크고 확장 가능하지 않은 유사한 기사를 찾는 것을 발견하고 소름이 돋았습니다.

적절한 대체품을 찾으면 이 플러그인은 확실히 휴지통에 들어갈 것입니다.

이야기의 교훈

온라인 속도 테스트가 귀하의 블로그가 빠르다고 알려준다고 해서 크게 의미가 있는 것은 아닙니다.

오해하지 마세요. 페이지 로드 속도는 검색 엔진과 일반 고객에게 중요하지만 캐시를 우회하고 서버를 무릎 꿇게 할 수 있는 악성 액세스도 고려해야 합니다.

따라서 캐싱 및 기타 속도 향상 플러그인을 맹목적으로 설치하지 마십시오. 시간을 내어 트래픽을 분석하고 가능한 한 많은 .htaccess 규칙을 작성하여 WordPress가 수행해야 하는 작업을 최소화하십시오. 행운을 빕니다!