WordPress용 페이지 속도 최적화에 대한 궁극적인 가이드

이 가이드에 따라 WordPress 사이트 속도를 크게 높이는 모든 기술을 배우게 됩니다. 다음은 WordPress에서 뛰어난 페이지 속도 로딩 시간이 비즈니스에 도움이 되는 가장 중요한 이유입니다. 사용자는 웹사이트를 버리지 않고 그곳에서 더 많은 시간과 돈을 지출하며 검색 엔진은 검색 결과에서 웹사이트 순위를 더 높일 것입니다. 준비가 된?

소개

인터넷 사용자는 페이지 로딩 시간과 관련하여 인내심이 많지 않습니다. 링크를 클릭하거나 URL을 입력하고 1초, 2, 3초만 기다리면 됩니다. Google 통계에 ​​따르면 사용자의 50%는 모바일 사이트가 2초 안에 로드될 것으로 예상하고 53%의 사용자는 페이지가 3초 이상 로드되는 경우 페이지를 떠날 가능성이 있습니다. 모바일에서 홈페이지가 로딩되는 평균 시간이 19초(3G 네트워크에서)라는 점을 감안하면 매우 짧은 시간이다. 컴퓨터의 로딩 시간은 더 빠르고 평균 로딩 시간은 5초이지만 여전히 너무 깁니다.

데스크톱 웹사이트 벤치마크를 참조로 사용하는 것은 더 이상 변명이 아닙니다. 오늘날 대부분의 웹사이트에서 트래픽의 대부분은 모바일 장치에서 발생합니다. 이 기사에서는 WordPress 사이트의 페이지 속도 최적화를 위한 최신 기술을 전체적으로 살펴보겠습니다. 이 가이드를 따르면 WordPress 사이트의 속도를 높이고 모바일 및 데스크톱 로드 시간을 크게 줄여 훨씬 더 사용자 친화적으로 만들 수 있습니다.

워드프레스 사이트가 없다면 아직 가이드를 닫지 마세요. 이 단계별 가이드에서 설명하는 대부분의 속도 최적화 기술은 모든 유형의 웹사이트에 적용할 수 있습니다.

귀하의 사이트가 수익 창출을 염두에 두고 구축된 경우 온라인 전자 상거래 상점이든 온라인/오프라인 서비스를 판매하든 상관없이 잠재 고객을 놓치는 것은 결코 좋은 일이 아닙니다. 당신은 기본적으로 테이블에 돈을 남겨두고 있습니다. 페이지 속도를 개선하면 수입에 긍정적인 영향을 미칩니다. 재미있는 사실: Obama 기금 마련 캠페인은 사이트 최적화를 통해 기부 전환율을 14% 증가시키고 페이지 로드 시간을 5초에서 2초로 줄였습니다.

웹사이트 소유자 또는 개발자로서 우리는 방문자가 최고의 경험을 하기를 바랍니다. 우리는 멋진 기능으로 멋진 사이트를 만들지만 일반적으로 빠른 웹사이트의 중요성을 잊습니다. 빠른 웹사이트는 방문자의 신뢰를 구축하고 방문자가 페이지에 더 오래 머물게 되어 더 많은 비용을 지출할 가능성을 높입니다. 반면에 우리 웹사이트가 느리다면 방문자는 포기할 수 있으며 똑같이 멋진 제안과 함께 우리의 멋진 웹사이트를 보지도 못할 것입니다.

위의 이유가 충분히 설득력이 없다면 하나 더 있습니다. Google 및 기타 검색 엔진(SE)에 따르면 웹사이트 속도가 느리면 검색 엔진 순위가 낮아져 방문자 수가 훨씬 더 적습니다. 따라서 빠른 웹사이트를 갖는다는 것은 Google이 당신을 더 좋아할 것이고 이것은 당신의 SE 순위를 당신에게 유리하게 크게 바꿀 수 있음을 의미합니다.

물론 로딩 시간은 방문자의 인터넷 속도, 방문자의 위치, 당사 웹사이트가 얼마나 "무거워" 또는 부풀려졌는지 등 몇 가지 이유로 인해 다릅니다. 방문자의 인터넷 속도에 대해 우리가 할 수 있는 일은 없지만 다른 측면을 돌보고 모든 사람의 경험을 개선할 수는 있습니다. 이 가이드에서는 WordPress 웹 사이트 속도를 최적화하여 빠르고 간결하게 만드는 방법을 살펴보겠습니다. 이제 시작하겠습니다!

목차

• 기초
  • 워드프레스 호스팅
    • 공유 호스팅
    • 관리 호스팅
    • VPS 또는 전용 서버
  • 워드프레스 테마
  • 워드프레스 플러그인
• WordPress 페이지 속도 최적화 단계
  • 페이지 속도 도구
    • Google PageSpeed ​​인사이트
    • GTMetrix
    • Pingdom 웹사이트 속도 테스트
    • 웹페이지 테스트
  • 이미지 최적화
    • 이미지 최적화를 위한 미니 가이드
    • Google PageSpeed ​​최적화 이미지
    • 기타 이미지 개선 사항
    • 사례 연구 개선 사항
  • 브라우저 캐싱
  • 리소스 압축(Gzip 또는 Deflate)
  • 불필요한 JS 또는 CSS 파일 제거
  • 스크롤 없이 볼 수 있는 콘텐츠의 렌더링 차단 JavaScript 및 CSS
  • 서버 측 캐싱
    • WP Rocket(서버 측 캐싱 플러그인)
  • 콘텐츠 전송 네트워크
    • 클라우드플레어
• 최종 결과
• 결론

기초

귀하의 웹사이트를 최대한 빠르게 만들려면 좋은 기반 위에 구축해야 합니다. 집을 짓는 것과 마찬가지로 모래 위에 집을 짓고 싶지 않고 처음부터 문제가 발생합니다. 튼튼한 기초 위에 짓고 싶기 때문에 문제 없이 오래 지속됩니다. 확인해야 할 세 가지 주요 사항은 다음과 같습니다.

• 호스팅
• 워드프레스 테마
• 워드프레스 플러그인

워드프레스 호스팅

호스팅은 WordPress 웹사이트의 기초이므로 이미 호스팅이 있더라도 간과해서는 안 되는 중요한 구성 요소입니다. 더 나은 호스팅 제공업체로 전환하면 최대 몇 초 동안 WordPress 로딩 속도가 빨라집니다.

올바른 웹 호스트를 선택하는 것이 중요하며 호스팅 가격을 기준으로 결정해서는 안 됩니다. 일반적으로 낮은 가격으로 낮은 성능을 얻을 수 있으며 이는 우리가 피하고자 하는 것입니다. 사용 가능한 호스팅 옵션을 살펴보고 차이점이 무엇인지 설명하겠습니다.

공유 호스팅

이것은 저렴하기 때문에 가장 널리 사용되는 호스팅 솔루션입니다. 그러나 우리가 말했듯이 낮은 가격으로 낮은 성능을 얻을 수 있습니다. 공유 호스팅에는 하나의 물리적 서버에 수천 개의 계정이 있습니다. 즉, 이러한 호스팅 계정으로 생성된 모든 웹사이트 간에 서버 리소스가 공유됩니다.

큰 피자(흠?...)를 상상해 보세요. 공유 호스팅의 각 웹사이트는 아주 작은 조각을 얻습니다. 그러나 귀하의 사이트에는 방문자가 많기 때문에 더 많은 피자가 필요합니다! 아직 배고픈데 더 이상 피자가 없어요 :(, 다른 사이트들도 배고파서...

피자 한 조각만 먹어도 충분히 나쁘지 않은 경우 잠재적인 보안 위험으로 인해 공유 호스팅 사례가 더욱 악화될 수 있습니다. 공유 호스팅의 감염된 웹사이트는 전체 서버에 속도 및 성능 문제를 일으키고 WordPress 사이트도 위험에 빠뜨릴 수 있습니다.

공유 호스팅의 서버 구성은 매우 제한적이며 원하는 대로 구성할 수 있는 여유 공간이 많지 않습니다. 서버는 일반적으로 매우 일반적인 특정 설정으로 미리 구성되어 있으며 문제 없이 WordPress를 실행해야 합니다. 나중에 메모리 부족 또는 제한된 PHP 설정의 형태로 플러그인이 제대로 작동해야 하는 문제가 발생합니다.

어떤 비즈니스 웹사이트에도 공유 호스팅을 추천할 수는 없지만, 꼭 해야 한다면 트래픽이 매우 적은 사이트에 가장 적합하다고 말하고 싶습니다.

관리 호스팅

웹사이트가 더 큰 피자 조각(전체 피자 조각, 예!)을 가져오기 때문에 공유 호스팅에서 크게 업그레이드되지만 비용이 더 많이 듭니다.

관리 호스팅의 서버는 덜 채워져 사이트에 대한 더 많은 서버 리소스로 변환됩니다. 이러한 서버는 일반적으로 WordPress를 최대한 원활하게 실행하도록 최적화되어 있으며 더 많은 메모리, 처리 능력 및 캐싱 시스템을 갖추고 있습니다.

이러한 관리 호스팅 서버의 하드웨어 및 소프트웨어 설치 및 구성은 호스팅 회사에서 수행합니다(따라서 "관리"라는 단어). 백업, 로드 밸런서, 재해 복구 및 보안 검사/예방과 같은 기타 서비스도 호스팅 회사의 제공에 따라 관리 호스팅의 일부가 될 수 있습니다.

관리형 WordPress 호스팅은 트래픽이 낮거나 중간 정도인 웹사이트에 권장됩니다.

VPS 또는 전용 서버

피자 비유에 충실하면 VPS(가상 사설 서버)를 사용하면 몇 조각의 피자를 얻을 수 있지만 전체 피자가 아닌 전용 서버를 사용하면 전체 피자를 얻을 수 있습니다.

즉, 전용 서버를 사용하면 모든 리소스가 있는 전체 서버를 제어할 수 있고 VPS를 사용하면 물리적 서버 시스템을 다른 사람과 계속 공유하고 있기 때문에 서버의 일부를 얻을 수 있습니다. WordPress의 페이지 속도 최적화와 관련하여 VPS 또는 전용 서버에서 WordPress를 설정할 때 서버 측 제한이 없습니다. 웹 사이트에 사용할 수 있는 리소스의 양을 정확히 알고 원하는 대로 구성할 수 있습니다. 표준 호스팅 공급자가 지원하기 전에 최첨단 기능을 구현할 수 있습니다(서버 소프트웨어 기술보다 몇 년 뒤쳐질 수 있음).

이 두 가지 옵션은 모두 더 나은 제어와 리소스를 제공하지만 장기적으로 설정하고 유지하려면 더 높은 가격과 더 많은 기술이 필요합니다. VPS/전용 서버도 관리할 수 있으므로 서버 전문가가 아니어도 사용할 수 있습니다. 트래픽 양이 많은 웹 사이트에 적합합니다.

어떤 호스팅을 선택해야 할지 잘 모르겠다면 필요한 경우 확장(서버에서 더 많은 리소스를 할당)할 수 있어야 하는 관리형 WordPress 호스팅 옵션을 제안합니다.

모든 괜찮은 호스팅이 현재 제공하는 무료 웹사이트 최적화는 PHP 버전을 7.x로 업그레이드하는 것입니다. WordPress 사이트가 PHP 7 미만(예: 5.6 또는 그 이전 버전)에서 실행 중인 경우 호스팅 지원팀에 연락하여 안정적인 최신 버전으로 업데이트하도록 요청하세요. 새로운 호스팅을 찾고 있다면 PHP 버전 7.x가 있는 경우 지원을 요청할 수 있습니다. 그들은 모두 "예"라고 단호하게 응답해야 하지만 PHP 7.x를 사용할 수 있는 옵션이 없다면 사용하지 않는 것이 좋습니다. PHP 7은 이전 버전과 비교할 때 속도와 성능 면에서 크게 개선되었으며 전환하기가 매우 쉽기 때문에 이점을 활용하십시오.

좋은 호스팅을 선택하면 앞으로의 수고를 덜 수 있습니다. 문제가 발생하면 훌륭한 고객 지원이 도움을 줄 수 있어야 하므로 좋은 지원을 제공하는 호스트를 선택하는 것도 염두에 두어야 합니다. . 활용할 수 있는 한 가지 빠른 방법은 구매 전 질문을 하고 응답 시간, 태도 및 전문성 수준을 모니터링하는 것입니다.

워드프레스 테마

사이트에 대한 WordPress 테마를 선택할 때 항상 테마 디자인으로 시작하며 괜찮습니다. 우리는 사이트가 훌륭하고 방문자가 가장 먼저 보는 것이 훌륭한 디자인을 원하기 때문에 먼저 마음에 드는 몇 가지 테마를 선택해야 합니다. 두 번째는 아마도 테마의 기능일 것입니다. 테마 또는 테마 권장 플러그인이 우리가 원하는 기능을 제공합니까? 그렇다면 훌륭합니다! 우리는 사업에 있습니다! 우리가 거의 항상 잊어버리는 것은 테마가 얼마나 빨리 로드되는지 확인하는 것입니다.

테마 데모 페이지의 로딩 시간을 테스트할 수 있으며 테마가 속도에 최적화되어 있는지 빠르게 확인할 수 있습니다. 아래 섹션에서 사용할 페이지 속도 도구와 사용 방법을 확인하지만 지금은 구매하기 전에 이 추가 테마 확인 단계에 대해 알려드리고자 합니다. 물론 데모 페이지의 로딩 시간은 개선될 수 있으므로 만점을 받지 못하더라도 걱정하지 마십시오. 콘텐츠가 매우 적은 경우를 제외하고 어떤 WordPress 테마도 완벽한 100% 점수를 받을 수 없습니다. 데모 페이지에서. 일반적으로 빨간색 숫자에 없는 테마를 찾아야 합니다(페이지 속도 도구에서 50점 이하).

테마 디자인과 기능 대 테마 속도 간의 균형이 잘 잡혀 있습니다. 예를 들어, 약간의 텍스트가 있는 빈 WordPress 테마는 매우 빠르게 로드되지만 많은 멀티미디어 콘텐츠와 함께 많은 기능(대부분 필요하지 않을 수 있음)이 있는 부풀려진 테마는 훨씬 느리게 로드됩니다. 훌륭하고 성능이 좋은 WordPress 테마를 선택할 때 최적의 위치에 도달하는 것이 목표입니다.

워드프레스 플러그인

내가 자주 보는 질문은 "플러그인이 너무 많습니까?"입니다. WordPress 플러그인 수의 문제가 아니라 코드 품질과 플러그인이 시스템에 미치는 영향입니다. 50개 이상의 활성 플러그인을 가질 수 있으며 각 플러그인이 작은 특정 기능(좋은 코드 포함)을 처리하면 사이트가 정상적으로 실행됩니다. 반면에 5개의 활성 플러그인이 있을 수 있으며 그 중 하나가 시스템을 막히게 하여 WordPress를 느리게 만들 수 있습니다.

각 플러그인의 코드를 살펴보는 것은 좋은 생각이지만 "아무도 그럴 시간이 없다"는 것과 더불어 그렇게 하려면 좋은 프로그래밍 지식이 필요합니다. 그 길을 간다면 조심해야 할 것은 많은 외부 리소스를 대기열에 추가하고, 많은 HTTP 요청을 하고, 불필요한(최적화되지 않은) 데이터베이스 쿼리를 만드는 등의 플러그인입니다(기본적으로 WordPress 웹사이트 속도를 저하시키는 모든 것, 정당한 이유 없이).

내가 권장하는 것은 필요하다고 생각되는 각 플러그인을 설치하고 활성화하지 않는 것입니다.

먼저 생각해보십시오. 귀하의 사이트에 이 추가 기능이 정말로 필요합니까? 예를 들어 버튼 단축 코드가 필요한 경우 테마 문서를 확인하세요. 테마에 단축 코드가 있을 수 있으며 단일 버튼 단축 코드를 사용하기 위해 전체 단축 코드 번들 플러그인을 설치하고 활성화할 필요가 없습니다. 이것은 사소한 예이지만 새 플러그인을 설치하고 활성화하기 전에 생각해 보시기 바랍니다. 확인되지 않은 각 플러그인은 사이트를 더 무겁게 만들고 속도를 늦출 수 있으며 플러그인이 제대로 코딩되지 않았거나 유지 관리되지 않은 경우 보안 위반으로 이어질 수 있습니다.

마지막으로, 플러그인을 선택할 때 활용할 수 있는 한 가지 좋은 점은 WordPress 글로벌 공유 및 결과적으로 거대한 커뮤니티입니다. 코딩 지식이 부족하면 활성 설치가 많고 평균 평점이 좋고 긍정적인 리뷰가 많은 인기 있는 플러그인을 사용하는 것이 좋습니다. 동료 워드프레스 사용자가 선택을 훨씬 더 쉽게 만들어 줄 것입니다!

WordPress 페이지 속도 최적화 단계

최적화를 시작하기 전에 몇 가지 사항을 언급하고 싶습니다.

먼저 WordPress 사이트의 백업을 만들어야 합니다. 여기 WordPress 플러그인을 사용하여 백업하는 방법에 대한 안내입니다. 죄송합니다보다 더 안전!

둘째, 가이드에서 사용할 페이지 속도 도구에서 100/100 점수를 기대하지 말라고 경고합니다. 100/100 점수를 추구하는 것은 좋은 생각이 아니며 일부 사이트에서는 불가능합니다. 사이트에 표시되는 콘텐츠의 종류에 따라 다릅니다. 사이트에 약간의 텍스트와 이미지만 있다면 당연히 만점을 받을 수 있습니다. 그러나 멀티미디어 콘텐츠가 많고 Google 지도 등과 같은 기타 타사 앱 통합이 포함된 긴 페이지가 있는 경우 100점은 눈에 띄지 않으며 추구해서는 안 됩니다.

왜 100/100으로 가는 것이 좋지 않습니까? 페이지 속도 도구의 지침에 따라 모든 것을 최적화하면 사이트가 제대로 작동하지 않을 수 있습니다. 모든 차단 JS 또는 CSS 파일을 바닥글로 이동하면 CSS 깜박임이 나타납니다(스타일이 지정되지 않은 콘텐츠가 먼저 나타나고 CSS가 로드될 때 사이트가 제자리에 "깜박임"). JS 코드에서도 동일한 일이 발생합니다. , JS 코드가 로드된 후 DOM 요소를 수정합니다.

맹목적으로 지침을 따르고 완벽한 점수를 얻기 위해 더 나은 로딩 시간을 위해 WordPress 사이트를 계속 최적화하면 사이트가 손상될 수 있습니다. 완벽한 페이지 속도 점수는 숫자에 불과하며 방문자가 사이트가 손상되는 경우 실제로는 중요하지 않습니다. 우리는 페이지 속도와 사용자 경험의 균형을 찾아야 합니다.

WordPress 페이지 속도 최적화 시연을 위해 공유 호스팅 계정과 의료용 WordPress 테마(테마 권장 플러그인 포함)를 사용합니다. 예, 예, 기본적으로 공유 호스팅을 사용하지 말라고 말한 것을 압니다. 그러나 우리는 그것이 무엇을 할 수 있는지, 어떤 제한이 있는지 알게 될 것입니다. 게다가 이것은 실제 비즈니스 WordPress 웹사이트가 아닌 페이지 속도 최적화 테스트일 뿐입니다.

최신 버전의 WordPress, MedicPress 테마, 모든 테마 권장 플러그인을 설치하고 데모 콘텐츠를 가져왔습니다. 이것은 테스트 사이트의 출발점입니다.

페이지 속도 도구

페이지 속도 최적화는 어려울 수 있지만 고맙게도 웹 사이트 속도를 향상시키기 위해 우리의 삶을 더 쉽게 만들고 무엇을 해야 하는지 조언하는 온라인 도구가 있습니다.

속도를 위해 WordPress를 최적화하는 첫 번째 규칙은 다음과 같습니다. 항상 측정하십시오!

각 최적화 단계 후에 아래 섹션에서 살펴볼 도구(또는 그 중 하나 이상)를 실행하고 개선 사항을 추적하세요. 이렇게 하면 어떤 작업이 가장 크게 개선되는지 알 수 있습니다. 또한 실제 평균 로딩 시간을 보려면 테스트를 여러 번 실행해야 합니다.

페이지는 호스팅 서버의 위치에 따라 다르게 로드됩니다. 예를 들어, 서버가 북미에 있고 방문자가 유럽에서 온 경우 캐나다 방문자보다 페이지가 느리게 로드됩니다. 이 문제는 CDN(Content Delivery Network)으로 해결할 수 있지만 이 기사의 뒷부분에서 조금 더 살펴보겠습니다. 현재로서는 이 문제가 전 세계 방문자와 페이지 속도 최적화 도구에 존재한다는 점을 지적하고 싶었습니다. 또한 일부 도구를 사용하면 다른 위치에서 테스트를 수행할 수 있으므로 이것이 로딩 시간에 어떤 영향을 미치는지 확인할 수 있습니다.

우리가 살펴볼 페이지 속도 도구는 다음과 같습니다.

• Google PageSpeed ​​인사이트
• GTmetrix
• Pingdom 웹사이트 속도 테스트
• 웹페이지 테스트

다른 도구가 있지만 이것이 가장 인기 있는 도구이며 계속 사용하겠습니다.

Google PageSpeed ​​인사이트

이 도구의 제목에서 알 수 있듯이 이것은 Google의 제품입니다. 점수(데스크톱과 모바일로 분할) 및 페이지 로딩 시간을 개선하기 위해 해야 할 일에 대한 유용한 지침 옆에 Google이 웹사이트에서 보고 싶어하는 내용에 대한 결론을 도출할 수도 있습니다. 검색 엔진 결과에서 좋은 순위를 매기기 위해 웹 사이트에서 최적화하려는 항목.

최적화되지 않은 이미지 또는 리소스 파일(JS 또는 CSS)이 있는 경우 최적화된 파일과 함께 zip 파일을 생성하여 서버에서 대체할 수 있습니다. 꽤 깔끔하죠? 나중에 이미지 및 코드 최적화를 살펴보겠습니다. Google PageSpeed가 도움이 될 수 있다는 것만 알아두세요.

Google PageSpeed ​​Insights는 다른 도구와 같이 자세한 정보가 많지 않지만 페이지 속도 최적화의 모든 중요한 측면을 다루는 좋은 출발점입니다. 사이트를 가장 개선할 수 있는 단계를 나열합니다.

테스트 사이트의 URL을 사용하여 이 도구를 실행했고 데스크톱에서 71점, 모바일에서 67점을 얻었으므로 개선의 여지가 있습니다. 가능한 최적화 제안 목록은 다음과 같습니다.

• 압축 활성화(gzip 또는 deflate로 리소스 압축)
• 이미지 최적화,
• 서버 응답 시간 감소,
• 스크롤 없이 볼 수 있는 콘텐츠에서 렌더링 차단 JavaScript 및 CSS 제거,
• 자바스크립트를 축소합니다.

GTmetrix

이 도구는 최적화된 항목과 최적화되지 않은 항목에 대한 자세한 정보를 제공합니다. 각 최적화 세부 정보가 나열되고 0-100의 척도로 평가됩니다. 목록은 중요도에 따라 정렬되므로 위에서 아래로 작업을 따르고 100% 점수가 없는 작업을 최적화하면 WordPress 사이트 속도를 최대한 빨리 높일 수 있는 좋은 경로에 있게 됩니다.

PageSpeed ​​및 YSlow 테스트 도구를 사용하여 GTmetrix는 페이지에 대한 점수를 생성하고 개선해야 할 작업을 표시합니다. 이 도구의 멋진 기능은 또한 사이트가 로드되는 방식을 그래픽으로 표시하고 병목 현상을 더 빨리 발견할 수 있는 폭포 보고서입니다. 아래 이미지에서 느린 공유 호스팅이 첫 번째 정보에 응답하는 데 1.13초가 걸렸음을 알 수 있습니다. 너무 길지만 개선할 수 있습니다.

또한 전 세계 7곳의 다른 위치에서 페이지를 테스트할 수 있습니다. 이는 이 기사의 뒷부분에서 볼 수 있는 훌륭하고 중요한 테스트입니다.

테스트 사이트에서 GTmetrix 도구(위치: 캐나다 밴쿠버)를 실행했으며 PageSpeed ​​점수는 77점, YSlow 점수는 71점입니다. 이 도구를 사용하면 다음과 같은 유용한 정보도 얻을 수 있습니다.

• 완전히 로드된 시간: 3.1초,
• 총 페이지 크기: 803KB
• 요청: 54

저는 GTmetrix 도구를 가장 좋아합니다. 한 곳에서 많은 관련 정보를 얻을 수 있기 때문입니다. 이 가이드에서는 최적화 진행 상황을 측정하기 위해 주로 GTmetrix 도구를 사용할 것입니다.

Pingdom 웹사이트 속도 테스트

Pingdom은 최적화 정보를 약간 다르게 표시하는 또 다른 도구입니다. GTmetrix 도구에서와 동일한 기본 요약 데이터를 얻을 수 있습니다(YSlow 점수 제외). Pingdom을 사용하면 4개의 다른 위치에서 페이지 속도를 테스트할 수 있습니다. 결과는 위치마다 모두 다르며 서버 위치가 중요하다는 것을 보여주지만 이 부분도 개선할 수 있습니다(이 기사 뒷부분의 CDN 사용). Pingdom 테스트가 더 빨리 완료되므로 Pingdom 도구를 사용하여 사용 가능한 4개 위치에서 페이지 로딩 시간을 테스트할 것입니다.

Pingdom은 또한 콘텐츠 유형 또는 도메인별로 필터링된 콘텐츠 크기 또는 요청 수와 같은 흥미로운 테이블을 표시하며 폭포식 보고서도 있습니다.

웹페이지 테스트

WebPageTest 도구에는 이전 도구보다 훨씬 더 많은 구성 옵션이 있습니다. 선택할 수 있는 위치가 더 많고 인터넷 속도를 선택할 수 있으며 몇 가지 브라우저 옵션을 활성화/비활성화하고 특정 장치를 테스트할 수 있습니다.

각 실행에 대한 자세한 폭포수 보고서를 표시하는 좋은 도구이며(기본적으로 3회 실행되지만 설정에서 변경할 수 있음) 이러한 각 속도 최적화 요소에 대해 A~F 등급을 표시합니다.

• 첫 번째 바이트 시간(응답 시간),
• 연결 유지 활성화,
• 압축 전송(gzip),
• 이미지 압축,
• 캐시 정적 콘텐츠,
• CDN의 효과적인 사용.

많은 유용한 정보를 찾을 수 있는 모든 결과 탭을 확인하여 세부 정보로 이동할 수 있습니다. 자세한 보고서가 필요하거나 사이트에서 사용 가능한 위치를 테스트해야 하는 경우 이 도구를 사용합니다. 그렇지 않으면 GTmetrix에 더 간결한 정보가 있다고 생각합니다.

테스트 사이트에서 이 도구를 실행했습니다. 아래 스크린샷에서 결과를 볼 수 있습니다.

더 인기 있는 페이지 속도 도구를 살펴보고 초기 페이지 속도 테스트를 수행했으므로 이제 WordPress 사이트 최적화를 시작할 준비가 되었습니다. 참고로 다음은 속도 최적화 진행 상황을 측정하는 데 사용할 페이지 속도 도구의 시작점 결과입니다.

• Google PageSpeed ​​인사이트
  • 모바일: 67
  • 데스크탑: 71
• GTmetrix
  • 페이지 속도: 77
  • Y슬로우: 71

이미지 최적화

이것은 아마도 사이트 성능에서 가장 무시되는 측면이며 동시에 사이트 속도를 가장 크게 향상시킬 수 있습니다. 이미지를 WordPress 사이트에 업로드하기 전에 최적화하는 것에 대해 생각해 본 적이 없다면 이것은 WordPress 로딩 시간 최적화를 위한 훌륭한 첫 번째 단계입니다.

웹 사이트의 작은 위치에 사용되는 최적화되지 않은 큰 이미지를 업로드하는 것은 큰 "노 아니오"입니다. 예: 사이트에 600 x 400픽셀보다 크지 않은 이미지 슬롯이 있고 1920 x 1080픽셀(또는 더 큰 이미지)을 업로드합니다. 이제 이 실수를 몇 번 반복하면 사이트가 매우 느려집니다.

가장 먼저 할 일은 이미지의 크기를 적절한 크기로 조정하는 것입니다. 이 예에서 이미지 슬롯은 600 x 400픽셀보다 크지 않으므로 이미지 크기를 해당 크기로 조정해야 합니다.

"그게 다야, 일 끝났어, 그렇지?" 아니요. 이미지를 더욱 향상시킬 수 있습니다. 품질 손실 없이 이미지를 최적화(압축)하는 많은 도구가 있습니다(우리의 눈은 이러한 도구로 품질 손실을 감지할 수 없음). 이렇게 하면 이미지 파일 크기가 크게 줄어들어 로드 속도가 빨라집니다.

이미지 압축은 수동으로 또는 WordPress 플러그인을 사용하여 수행할 수 있습니다. 제 동료인 Marko는 이미지 최적화를 위한 놀라운 가이드를 작성했습니다. 따라서 그의 기사에서 얻은 지식을 사용하여 이미지를 최적화하는 데 사용할 수 있는 기술을 빠르게 살펴보겠습니다.

이미지 최적화를 위한 미니 가이드

올바른 이미지 형식을 선택하십시오. 온라인에서 가장 많이 사용되는 이미지 형식은 JPEG와 PNG입니다. 올바른 이미지 형식을 선택하면 이미지 파일 크기를 많이 절약할 수 있습니다(Marko는 기사에서 45%를 절약했습니다). 다음을 사용해야 합니다.

• 사진, 그라디언트가 있는 이미지 및 수백만 가지 색상이 있는 이미지를 위한 .jpg 형식입니다.
• 제한된 색상(로고)이 있는 이미지 및 투명도가 있는 이미지의 .png 형식입니다.

이미지 크기 조정 – 위에서 언급했듯이 이미지를 WordPress 사이트에 업로드하기 전에 항상 이미지 크기를 조정해야 합니다. 먼저 이미지를 사용할 공간의 크기를 확인하고 그에 따라 크기를 조정합니다. GIMP나 Photoshop과 같은 이미지 조작 프로그램을 사용하여 이미지의 크기를 조정할 수 있습니다.

이미지 압축 – 온라인 이미지 압축 도구 또는 WordPress 플러그인을 사용하여 수행할 수 있습니다.

온라인 압축 도구 : Marko는 Optimizilla 온라인 도구를 권장합니다. 이미지를 Optimizilla 앱에 업로드하고 프로세스가 완료되면 최적화된 이미지를 다운로드한 다음 WordPress 사이트에 업로드해야 합니다. 이것은 약간 지루하게 들리므로 물론 이 프로세스를 단순화할 수 있는 WordPress 플러그인이 있습니다.

WP 이미지 압축 플러그인 : Marko는 가장 인기 있는 이미지 압축 플러그인을 다시 테스트하여 승자를 선언했습니다. ShortPixel Image Optimizer. 플러그인을 설치한 후 플러그인을 사용하려면 API 키를 요청해야 합니다(매우 간단한 프로세스). 플러그인의 기본 설정은 훌륭하므로 아무 것도 설정할 필요가 없습니다. 미디어 -> Bulk ShortPixel 로 이동하여 "최적화 시작" 버튼을 클릭하기만 하면 됩니다. 새로 업로드된 이미지도 최적화됩니다. 참고: 이 플러그인의 무료 버전은 한 달에 100개의 이미지 최적화만 허용합니다. 더 필요하면 유료 플랜으로 전환해야 합니다. 우리는 고객이 최고의 도구에 액세스할 수 있기를 원하므로 ShortPixel과 파트너 관계를 맺었으며 이제 ProteusClub 회원 도 ShortPixel WordPress 플러그인과 함께 사용할 수 있는 1,000크레딧을 무료로 받습니다.

마지막으로 WordPress의 이미지 최적화에 대한 전체 기사를 읽을 만큼 추천할 수 없습니다.

Google PageSpeed ​​최적화 이미지

이것은 WordPress 사이트에서 기존 이미지를 최적화하는 방법에 대한 대안입니다. 이미지 최적화를 위한 미니 가이드 섹션의 위 단계를 따랐다면 이미 이미지를 최적화했을 것이므로 Google PageSpeed에 이미지가 없을 것입니다. 잘 했어! 정보 제공을 위해 이 섹션을 읽을 수 있습니다.

Google PageSpeed ​​도구 소개에서 Google은 귀하의 사이트에서 사용할 수 있는 최적화된 파일로 zip 파일을 생성한다고 언급했습니다. 다음 링크를 클릭하여 zip 파일을 다운로드할 수 있습니다.

이 zip 파일에는 최적화된 이미지가 있는 image 라는 폴더가 있습니다. FTP 또는 호스팅 파일 업로더를 통해 업로드할 수 있습니다. 올바른 업로드 폴더(…/wp-content/uploads/…)의 이미지를 교체/덮어씁니다. 그런 다음 WordPress 사이트에서 이러한 이미지의 더 작은 버전(썸네일)도 생성해야 합니다. Regenerate Thumbnails 플러그인을 사용하면 가능합니다.

기타 이미지 개선 사항

이 섹션에서는 추가 성능을 끌어내기 위해 활용할 수 있는 이미지와 관련된 몇 가지 추가 개선 사항을 살펴보겠습니다.

이미지 로딩 지연

Lazy Loading은 이미지가 비동기식으로 로드되는 이미지를 로드하는 기술입니다. 스크롤 없이 볼 수 있는 부분이 아닌 이미지는 페이지 로드 시 로드되지 않습니다(필요한 경우에만 또는 나중에 로드됨). 즉, 페이지 상단에서 볼 수 있는 이미지가 로드되고 페이지가 로드된 후 또는 사용자가 페이지 아래로 스크롤할 때(요청 시) 다른 이미지(보이지 않음)가 로드됩니다. 이미지가 많은 긴 페이지가 있는 경우 이 기술을 사용하면 초기 페이지 로드 시간을 많이 절약할 수 있습니다.

지연 로딩은 일부 사용자 정의 코드 또는 WP 플러그인으로 구현할 수 있습니다. 우리는 나중에 WP Rocket 캐싱 플러그인을 사용할 것이며 지연 로드 기능도 있습니다.

이미지 핫링크

핫링크란 무엇입니까? 다른 서버에서 호스팅되는 이미지를 표시하고 있습니다. 예를 들어 매우 인기 있는 게시물이 있고 해당 게시물에 좋은 이미지가 있는 경우입니다. 방문자(도둑)가 이미지 소스 URL을 복사하여 자신의 사이트에서 사용할 수 있습니다. 즉, 이미지가 서버에서 요청되고 제공됩니다. 도둑에 100을 곱하면 서버가 응답해야 하는 수천 개의 외부 요청이 있어 서버 속도가 느려질 수 있습니다.

이것은 직접적인 페이지 속도 최적화가 아니라 서버 최적화입니다. .htaccess 파일의 일부 코드로 핫링크 문제를 해결할 수 있습니다. 한 단계 더 나아가(약간 사악해질 수 있음) 도난당한 이미지를 다른 이미지로 교체할 수 있습니다. 아마도 그다지 좋은 이미지는 아닐 것입니다. :). .htaccess 파일에서도 가능합니다. 서버에서 .htaccess 파일을 열고 이 코드를 추가하십시오. your-website.com 을 귀하의 도메인으로, google.com 을 귀하의 이미지에 대한 액세스를 허용할 다른 도메인으로 바꾸고 http://replacing-stolen-image-url-goes-here.jpg를 바꾸십시오. 도난당한 이미지에 대해 표시하려는 이미지 URL로

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ http://replacing-stolen-image-url-goes-here.jpg [NC,R,L]

도난당한 이미지를 사용자 지정 이미지로 교체하지 않으려면 이 코드를 사용하십시오. 이렇게 하면 웹사이트에서 이미지가 비활성화됩니다.

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

사례 연구 개선 사항

이미지를 최적화한 후 지금까지 테스트 사이트에서 진행한 사항을 살펴보겠습니다. 아시다시피, 테스트 사이트로 사용 중인 의료 테마에 대한 데모 데이터를 가져왔습니다. 이 데모 이미지는 올바른 파일 형식을 사용했고 이미 크기가 올바르게 조정되었으므로 이 두 단계를 건너뛸 수 있습니다. 내가 새로운 이미지를 업로드한다면, 나는 그것을 건너 뛰지 않을 것입니다!

그래서 ShortPixel 플러그인을 설치하고 대량 최적화 프로그램을 실행했습니다. 플러그인은 평균 38%의 이미지 최적화를 보고했습니다. 대단해!

PageSpeed ​​Insights 도구를 실행했는데 Google에서 일부 이미지를 더 압축할 수 있다고 지적했기 때문에 내 조언에 따라 Google에서 준비한 이미지를 사용하고 FTP를 통해 내 서버에 업로드했습니다.

이미지를 정렬한 후 페이지 속도 도구 결과는 다음과 같습니다.

• Google PageSpeed ​​인사이트
  • 모바일: 72
  • 데스크탑: 77
• GTmetrix
  • 페이지 속도: 81
  • Y슬로우: 71

데모 데이터에 사용된 이미지가 이미 상당히 최적화되어 있기 때문에 큰 개선은 아니지만 여전히 목표에 한 걸음 더 다가섰습니다. 사이트에 최적화되지 않은 이미지가 있는 경우 이 이미지 최적화 단계를 수행하면 점수가 크게 증가하고 페이지 로딩 시간이 단축됩니다.

브라우저 캐싱

사용자가 브라우저를 통해 사이트를 방문하면 방문자에게 사이트를 표시하기 위해 서버에서 모든 리소스(HTML, 이미지, JS, CSS 등)를 다운로드해야 합니다. 동일한 사용자가 사이트의 다른 페이지를 방문할 때 CSS 및 JS 파일은 일반적으로 동일하게 유지되지만 적절한 서버 구성이 없는 경우 브라우저는 여전히 서버에서 파일을 다시 다운로드할 수 있습니다.

정적 리소스(JS, CSS 및 기타 파일)를 브라우저 캐시에 저장할 수 있도록 서버에 적절한 캐싱 헤더와 만료 날짜를 설정해야 합니다. 이렇게 하면 재방문자나 사이트에서 둘 이상의 페이지를 보는 방문자의 실적이 크게 향상됩니다.

일반적으로 호스팅 서버에는 이미 구성되어 있습니다. If the page speed optimization tools report that you are missing the “Leverage browser caching” optimization or something like that, then it's best to contact your hosting company and let them know that you want to set-up browser caching for your site. They will be able to sort that out for you or at least point you to the right direction on how to do that yourself.

If you want to do things yourself, then you have to know that these browser caching settings vary, depending on the server type your hosting company is using. A good starting point for Apache servers is the .htaccess file of the HTML5 Boilerplate project (check out the “Expires headers” section). An nginx configuration is available as well.

My shared hosting account has browser caching already configured, so there is nothing for us to do on our test site.

Resource Compression (Gzip or Deflate)

Files sent from your server (HTML, JS, CSS, …) to your visitors can be compressed, so that they can be transferred faster, which improves your page speed. This can be done by enabling Gzip or Deflate compression on your server.

You can contact your hosting support and ask them, if they can enable resource compression for your site or you can configure it yourself, but be sure you know which server type your hosting is using. We can again look at the HTML5 Boilerplate project for some tips, they have default server configs for each of the major server types. For example, my hosting is using Apache server, so I found this compression config. I've copied the content of this config, I've located the .htaccess file for my WordPress site via the FTP (it's in the root of your WP installation) and I copied it at the end of the file.

I've re-run the page speed tools, after I've enabled the resource compression for my WordPress site and here are the results:

• Google PageSpeed Insights
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 96
  • YSlow: 82

As you can see, we've improved our scores by a fair amount and all we did, was enable the resource compression, which did not take a lot of time. By compressing resources, we change the total page size from 803KB to 476KB, which is awesome! We made another step towards an optimized site, so let's continue.

Remove unneeded JS or CSS files

If you are using plugins, which include JS or CSS files on all your pages and you actually are not using the plugin features on those pages, then it's best to remove them. This can be done with custom code in your child theme, but I would recommend that you use a plugin for that. It's much easier!

The plugin that will help us do that is WP Asset CleanUp. After you install and activate this plugin, go and edit your home page. Home pages are usually the “heavier” pages, so we will look at it for our example, but you can do that for other pages as well.

Under the page content editor, you will see a section called WP Asset CleanUp . This section will list all CSS and JS files that are included on your front page. Now, your job is to find out, which of these files are not needed on your WordPress front page.

For example, in our test site, we are using the Contact Form 7 plugin, but we are only using the contact form on our “Contact Us” page, so we can safely remove (unload) its CSS and JS files from our home page. I can do the same with WooCommerce assets, since we are not using them on our home page as well. You should look at each asset in the list and check, if you can unload it. Watch out for the files with the red exclamation icon, you should probably never unload these, since they are core WordPress files and they are needed for the site to work properly. This is how my home page Assets CleanUp settings looks like:

I was able to safely remove 11 assets, which will save 11 resource requests when a page loads and that will improve the page speed.

Re-run of page speed test tools showed, that Google PageSpeed Insights score did not change (because it also did not list this as a recommended optimization), but the GTmetrix score did improve:

• Google PageSpeed Insights
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 97
  • YSlow: 86

Our site also loads faster, it now needs 2.7 seconds to load the whole site (in the beginning it took 3.1 seconds). We are improving the WordPress site speed slowly but surely. Bear in mind, I'm using one of our WordPress themes for the test, which are built from the ground up to be performing out of the box. If you're using some other WordPress theme, where the author didn't put any efforts to optimize it for speed, your improved loading speed results will most probably be much greater at this point.

With removing unneeded JS and CSS files from our home page, we improved our scores, load time, number of request and the total page size as well. 잘 했어!

Render-blocking JavaScript and CSS in above-the-fold content

One of the optimizations that Google PageSpeed Insights suggests is also: “Eliminate render-blocking JavaScript and CSS in above-the-fold content”. This is a tricky one. Remember when I said, that it's not good to chase a perfect score in the page speed tools? This is one of the reasons for that.

If we look at our example, the Google tool suggests that the Page Builder front-flex.css should be deferred or loaded asynchronously. We are using the Page Builder by SiteOrigin plugin for building content in our pages. So, if this file is responsible for making our layout of the page look good, then I might not respect Google suggestion and simply ignore it.

“But why would you disrespect Google? 어떻게 감히!” Well, this is only a tool and it gives you suggestions on what to do, but it does not know, if implementing some of these changes will break your site or ruin good user experience (UX) for your visitors. For example, if the tools had suggested that we load the style.css file with all the theme styles asynchronously, then it would have created the FOUC: Flash of unstyled content:

This is a bad UX, so I would ignore the suggestion from the tool and keep a good UX instead of improving our score. After all, Google is also using other factors it can gather from your website to rank it in the search results and user experience is one of them. When optimizing the website for speed, don't follow the recommendations blindly and forget about all the other aspects and goals your WordPress website has.

If the files that the tool suggests to be loaded asynchronously are valid candidates and they don't break anything, then of course we can implement that change. The best way is to just try to asynchronously load each suggested file and see, if the page still loads ok. Don't forget to reload the page without browser cache, so that a fresh copy of the page loads. You can do that by hard refreshing your site.

We will look at how to load files asynchronously in the WP Rocket plugin section below. There are other standalone plugins that offer this functionality, but since the WP Rocket has it build in, we don't need to pollute our WP installation with more plugins.

Server Side Caching

We've already talked about browser cache, but now we also have to take care of the server side cache. To understand server side caching we have to know the basics of how WordPress works, so let's look at that first.

When a visitor opens a WordPress page, the following things happen (basic explanation):

1. Server receives a page request.
2. WordPress PHP code begins to execute.
3. WordPress access the database to get the information it needs to build the requested page.
4. WordPress produces the HTML.
5. Server responds with the HTML for the browser to display it to the visitor.

These 5 steps have to be repeated for each page view, for each visitor. That's a lot of repetitive work for content that stays the same for each visitor (if your site is displaying mostly static content, which majority of websites is).

Server side caching eliminates pretty much all the server's hard work. It removes the need for repeating steps 2,3 and 4. So, when we enable server side caching, the process of a page request looks like this:

1. Server receives a page request.
2. Server retrieves the page HTML from the cache (if a cached version is available).
3. Server responds with the HTML for the browser to display it to the visitor.

As you can see, the hard work of running the WordPress code and accessing the database is bypassed, which means that the page loading time should be much faster.

If we look at the Google PageSpeed Insights tool suggestions, we will spot the “Reduce server response time” task. The tool says that our server responded in 0.98 seconds, which is not good. The slow shared hosting I'm using is definitely to blame for some chunk of that 1 second response time, but we'll be able to shorten it with server side caching.

Each page cache is usually saved with an expiration time of 24 hours, but that setting can be changed. This means that instead of thousands of page requests running the whole WordPress HTML building process, it will only be run once a day, to generate that cached page and the server will serve that cached page to other visitors. So, not only the page will be quicker, but the server will also have to do less work.

If you are updating a page in WordPress and an old cached version of the page is still available on your server, then you would have to clear that cache manually (usually with the click of a button) or some tools would do that for you automatically.

Some hosting companies already have a server side caching in place for their users, but this feature is usually available for managed WordPress hosting packages. So, before you follow instructions below, on how to setup server side caching, you should make sure that your server is not doing that for you already.

We will look at how to setup the WP Rocket plugin to enable server side caching and other features that it has (like lazy loading images, loading assets asynchronously, minification of JS and CSS files and much more). WP Rocket is a premium (paid) plugin, but I believe it's worth the investment. If you don't agree with me, that's fine WP Super Cache is a good free alternative, but it does not have the same extra features as WP Rocket and it's a little bit more cumbersome to setup.

WP Rocket (server side caching plugin)

As soon as we install and activate the WP Rocket plugin it will have some basic features enabled out of the box:

• Caching of all the pages for quick viewing.
• Decrease bandwidth usage with our GZIP compression.
• Management of the headers (expires, etags…).

The WP Rocket plugin default settings are a good starting point.

I've run the page speed tools a couple of times, so that they picked up the cached version of the site and these are the new results:

• Google page speed insights
  • Mobile: 91
  • Desktop: 97
• GTmetrix
  • PageSpeed: 97
  • YSlow: 87

The Google PageSpeed Insights tool no longer displays the “Reduce server response time” optimization suggestion, because we reduced it from 1 second to 121ms, that's a 88% improvement in server response time, just by activating the WP Rocket plugin! With this improvement, our fully loaded time is now 1.9 seconds, but we are not stopping here

WP Rocket 플러그인이 제공해야 하는 설정을 살펴보겠습니다. WP Rocket에는 상단 WP 관리 메뉴 모음에 멋진 바로 가기 메뉴가 있습니다. 거기에서 설정 페이지에 액세스하고 캐시를 지우고 이 플러그인과 관련된 기타 유용한 정보에 액세스할 수 있습니다.

계속해서 다른 WP Rocket 설정을 시도하기 전에 모든 변경 후에는 시크릿/비공개 브라우저 탭 에서 사이트를 확인해야 한다는 점을 말씀드리고 싶습니다. WordPress 사이트에 로그인하면 캐시된 버전의 사이트가 표시되지 않습니다. 시크릿 브라우저 탭에서 로그인하지 않고 사이트의 캐시된 버전을 가져오므로 제대로 작동하는지 확인할 수 있습니다.

또한 각 WP Rocket 설정을 활성화하면 사용 중인 테마 또는 플러그인에 따라 WordPress 속도에 다른 결과 또는 부정적인 영향이 있을 수 있으므로 모든 WP Rocket 설정을 활성화하는 것은 올바른 방법이 아닙니다. 각 설정을 시도하고 페이지 속도 도구로 측정하여 차이점을 확인해야 합니다. 보시다시피 일부 기술은 페이지 속도를 향상시키지 않으므로 사용하지 않습니다.

캐시 지우기

서버 측 캐싱은 WP Rocket 플러그인을 활성화하는 즉시 작동하기 시작하므로 어떻게 지울 수 있는지 살펴보겠습니다. WP Rocket 바로 가기 메뉴에서 "캐시 지우기" 메뉴 항목을 클릭하면 수동으로 캐쉬를 지울 수 있습니다. 플러그인은 또한 사용자 정의 설정을 업데이트하고 위젯, 카테고리 등을 변경/업데이트할 때 자동으로 캐시 지우기를 처리하며 페이지를 업데이트할 때 캐시를 부분적으로 지웁니다. 자동 캐시 지우기가 발생하는 시기에 대한 자세한 내용은 이 WP Rocket 질문을 참조하세요.

캐시에는 WP Rocket 설정의 "기본" 탭에서 설정할 수 있는 수명이 있습니다. 이것을 1일로 설정하는 것이 좋습니다.

캐시 미리 로드

WP Rocket의 멋진 기능은 "캐시 미리 로드"로, 홈 페이지의 캐시와 링크되는 페이지를 미리 로드하여 사용자가 항상 페이지의 캐시된 버전을 받게 됩니다. 페이지 속도 도구를 실행하기 전에 이 기능을 사용할 수 있었고 캐시된 버전 결과를 얻기 위해 도구를 여러 번 실행할 필요가 없었습니다.

사전 로드 캐시 설정은 "Preload" 탭의 설정 페이지에서 액세스할 수 있습니다. "봇 미리 로드" 옵션을 찾으면 수동 및 자동 옵션이 ​​있습니다. 자동 봇 옵션을 활성화하면 페이지를 업데이트하거나 생성할 때마다 또는 캐시가 만료될 때마다 사전 로드 캐시가 실행됩니다. 이 옵션은 서버의 성능에 영향을 줄 수 있으므로 사용하도록 설정한 경우 성능 로그를 주시하십시오. 많은 게시물/페이지를 업데이트 및 생성하고 공유 호스팅이 있는 경우 이 옵션을 활성화하지 않는 것이 좋습니다. 대신 수동 봇 옵션만 활성화해야 합니다. 그러면 "캐시 미리 로드"라는 다른 WP Rocket 바로 가기 메뉴 항목이 생성되며 이를 클릭할 때만 캐시를 미리 로드합니다(게시물 및 페이지 편집을 완료한 후).

"사전 로드" 설정 탭에는 사이트맵에서 캐시를 사전 로드하는 설정도 있으므로 사이트맵을 정의하면 사이트맵의 URL을 사용하여 해당 페이지의 캐시를 사전 로드합니다.

레이지로드

이미 이 기사의 이미지 최적화 섹션에서 지연 로딩 이미지에 대해 설명했지만 이제 WP Rocket이 설치되었으므로 이 기능을 실제로 활성화할 수 있습니다. WP Rocket 설정의 "기본" 탭으로 이동하여 이미지에 대해 LazyLoad를 활성화하고 비디오 또는 iframe을 사용하는 경우에도 활성화할 수 있습니다.

이 기능을 활성화한 후에는 항상 사이트를 확인하고 이미지가 어떻게 로드되는지 확인해야 합니다. LazyLoad는 사이트 레이아웃을 깨뜨릴 수 있거나 이미지가 로드되는 방식(콘텐츠 점프)이 마음에 들지 않을 수 있으므로 항상 페이지를 확인하십시오. 이 기능은 스크롤 없이 볼 수 있는 부분에 많은 이미지가 있고 원본 페이지 로드 시 이미지 요청 수를 줄이는 데 도움이 될 때 정말 유용합니다. 테스트 사이트에는 스크롤 없이 볼 수 있는 부분에 이미지가 5개뿐이므로 5개의 이미지 요청을 저장했고 페이지 로딩 시간은 이제 1.7초로 줄었지만 페이지 속도 도구의 점수는 그대로 유지되었습니다. 이것은 도구가 제안하지 않는 특정 작업으로 페이지 속도를 향상시킬 수 있다는 좋은 지표입니다.

파일 축소

여전히 개선할 수 있는 GTMetrix 제안 중 일부는 HTML, CSS 및 JS 파일을 축소하는 것입니다. WordPress 테마와 대부분의 권장 플러그인이 이미 JS/CSS 파일용으로 축소된 버전을 사용하고 있고 서버에서 Gzip을 활성화하고 있기 때문에 이 WP Rocket 최적화는 테스트 사이트에 큰 개선을 가져오지 않지만 귀하의 경우는 다른. WP Rocket 설정의 "정적 파일" 탭으로 이동하여 파일 축소 옵션에서 3가지 옵션을 모두 선택합니다. 설정을 저장하고 시크릿/비공개 탭에서 웹사이트를 확인하면 이러한 옵션이 사이트에 가져올 수 있는 문제를 찾을 수 있습니다. 내 테스트 WordPress 사이트에서 CSS 축소로 인해 페이지 빌더 flexbox CSS 파일 대기열이 중단되었으므로 CSS 축소 파일 옵션을 비활성화해야 했습니다. HTML 및 JS 옵션이 제대로 작동했습니다.

나는 WP Rocket 지원에 문제가 무엇인지 물었고 그들은 내 사이트에서 이 문제를 디버그하기에 충분했습니다. 이 문제는 내 공유 호스팅에서 사용된 Varnish 캐시로 인해 발생했습니다. 그들은 내 호스팅 서버 에서 Varnish 구성 을 변경할 것을 제안했습니다 . 호스팅 지원팀에 문의했으며 의심되는 대로 공유 호스팅에서 Varnish 구성을 변경할 수 없지만 VPS 호스팅 패키지로 업그레이드하면 변경할 수 있습니다. 보시다시피 공유 호스팅을 사용하는 것은 좋은 생각이 아닙니다.

CSS 또는 JS 축소에 문제가 있는 경우 제외된 JS 또는 CSS 파일 상자에 문제를 일으킨 파일 URL을 추가할 수 있습니다. 문제의 원인이 되는 파일을 찾는 것은 까다로울 수 있지만 일반적으로 어떤 기능이 손상되었고 어떤 플러그인이 해당 기능을 담당하는지 알고 있으므로 페이지 소스 코드를 확인하고 해당 플러그인에 의해 포함된 파일을 검사합니다. 플러그인에 여러 JS 또는 CSS 파일이 있는 경우 제외 목록에 추가하고 문제가 해결되는지 확인할 수 있습니다.

JS와 CSS 파일 결합

GTmetrix 도구의 YSlow 탭은 "더 적은 HTTP 요청 만들기"를 알려줍니다. 그것은 우리 워드프레스가 9개의 외부 JS 스크립트를 사용하고 있으며 1개로 결합하려고 시도하고 페이지가 4개의 외부 CSS 파일을 사용하고 있으며 그것들을 1개의 파일로 결합해야 한다고 말합니다. 이 문서의 불필요한 JS 또는 CSS 파일 제거 섹션에서 불필요한 JS 및 CSS 파일을 이미 제거했음을 기억하고 있습니다.

모든 JS 및 CSS 파일을 하나의 파일에 결합하는 것은 좋은 생각이 아닙니다. 브라우저는 1-2개의 큰 파일보다 빠르게 6개의 작은 파일을 병렬로 다운로드할 수 있기 때문입니다. 또 다른 이유는 일부 파일은 HTML 문서의 헤드에 포함되고 다른 일부는 문서 끝에 포함되어 최소 2개의 파일로 분할해야 하기 때문입니다.

WP Rocket과 파일을 결합하려면 플러그인 설정의 "정적 파일" 탭으로 이동하여 파일 결합 아래의 옵션을 활성화하십시오. 항상 그렇듯이 시크릿/비공개 브라우저 탭에서 사이트를 확인하여 문제가 있는지 확인하세요.

이 예에서는 위에서 언급한 공유 호스팅 Varnish 구성 문제로 인해 WP Rocket에 다시 문제가 발생하여 JS 파일 결합 옵션을 비활성화해야 했습니다.

다시 말하지만 CSS 또는 JS 연결에 문제가 있는 경우 위의 축소 단계에서와 같이 문제를 일으킨 파일 URL을 제외된 JS 또는 CSS 파일 상자에 추가할 수 있습니다.

정적 리소스에서 쿼리 문자열 제거

일부 프록시 서버는 쿼리 문자열로 리소스를 캐시하지 않기 때문에 GTMetrix는 정적 리소스에서 쿼리 문자열을 제거할 것을 권장합니다.

정적 리소스(일반적으로 JS 또는 CSS 파일)의 쿼리 문자열은 해당 파일의 버전을 표시하는 URL 속성입니다. 다음과 같습니다: ?ver=2.5.8 그리고 URL 끝에 추가됩니다: http://domain.com/css/front-flex.css?ver=2.5.8

WP Rocket을 사용하여 이러한 쿼리 문자열을 쉽게 제거할 수 있습니다. 플러그인 설정의 "정적 파일" 탭으로 이동하여 쿼리 문자열 제거 옵션을 활성화합니다.

이 옵션을 활성화한 후 GTmetrix PageSpeed ​​점수는 98로 변경되었지만 페이지 로딩 시간은 변경되지 않았습니다.

렌더링 차단 CSS/JS

유일한 Google PageSpeed ​​Insights 도구 제안은 "스크롤 없이 볼 수 있는 콘텐츠에서 렌더링 차단 JavaScript 및 CSS 제거"입니다. 이는 스크롤 없이 볼 수 있는 콘텐츠에서 페이지 로드를 차단하는 일부 JS 또는 CSS 파일이 있음을 의미합니다. 도구가 우리에게 원하는 것은 이러한 차단 리소스를 지연하거나 비동기식으로 로드하는 것입니다.

다시 한 번 WP Rocket 플러그인이 구출됩니다. "정적 파일" 탭으로 이동하여 렌더링 차단 CSS/JS 옵션을 찾습니다. 여기에서 이 문제를 해결할 수 있는 JS 및 CSS 옵션을 활성화할 수 있습니다. JS 옵션을 활성화하면 안전 모드(권장) 옵션이 나타납니다. 이 안전 모드는 페이지 헤드에 jQuery 라이브러리(WP 기본 대기열에 추가된 라이브러리)를 로드하여 차단 파일로 남겨두지만 페이지에 인라인 jQuery 코드가 있는 페이지는 손상되지 않습니다. jQuery가 여전히 헤드에 로드되어 있기 때문에 PageSpeed ​​도구는 여전히 렌더링 차단 JS 파일이 있다고 불평합니다.

따라서 테스트 사이트의 안전 모드를 비활성화하면 Google PageSpeed ​​도구가 모바일에서 100점, 데스크톱에서 100점 만점을 줍니다. 좋아, 그렇지? 설마! 우리 웹사이트는 여전히 제대로 작동하지만 웹사이트가 어떻게 로드되는지 살펴보겠습니다.

스타일이 지정되지 않은 콘텐츠의 플래시(FOUC)는 WP Rocket 설정(렌더 차단 CSS/JS 옵션 바로 아래)에서 중요 경로 CSS 옵션을 사용하여 수정할 수 있습니다. 이론은 페이지의 스크롤 없이 볼 수 있는 부분에 필요한 CSS 코드를 추가하여 스타일이 지정되지 않은 텍스트의 플래시 효과가 페이지 로드 시 나타나지 않도록 한다는 것입니다. 이것은 소리보다 어렵습니다. 여러분을 위해 이 중요한 CSS를 생성해야 하는 도구가 있지만 저는 그 도구로 많은 성공을 거두지 못했습니다.

중요 경로 CSS 코드를 생성하려면:

1. 사이트에서 WP Rocket 플러그인을 비활성화하십시오.
2. 중요 경로 CSS 생성기 도구로 이동합니다.
3. 사이트 URL을 입력하고 실행합니다.
4. 중요 경로 CSS 코드를 복사합니다.
5. WP Rocket 플러그인을 활성화합니다.
6. CSS 코드를 WP Rocket 설정의 "Critical path CSS" 상자에 붙여넣습니다.
7. 중요한 CSS 코드에 상대 URL 경로가 있는지 확인하고 절대 경로로 변경합니다.

WordPress 테스트 사이트의 로딩은 다음과 같습니다.

낫긴 한데 아직도 마음에 안든다. 예, 100/100의 Google PageSpeed ​​점수는 훌륭하지만 총 로딩 시간이 더 느리고 이 렌더링 차단 CSS/JS 옵션을 활성화했기 때문에 요청이 2개 더 있습니다. 나에게 주요 문제는 여전히 페이지 로드의 사용자 경험이므로 이 WP Rocket 옵션을 비활성화했습니다.

WP Rocket은 사이트 속도를 높이는 모든 기능을 갖추고 있기 때문에 각 WordPress 웹사이트 소유자가 사용해야 하는 플러그인입니다. 플러그인을 활성화하는 것만으로도 엄청난 효과를 볼 수 있습니다. 각 테마와 플러그인이 고유한 문제를 믹스할 수 있기 때문에 모든 웹사이트에 대해 다른 기능을 테스트해야 합니다.

최적화 단계가 거의 막바지에 다다랐습니다. 남은 것은 웹 사이트 자산에 CDN을 사용하는 것뿐입니다.

콘텐츠 전송 네트워크(CDN)

이 기사에서 이미 몇 번 언급했지만 페이지 로딩 시간은 서버의 위치와 방문자의 위치에 따라 다릅니다. 예를 들어 테스트에 사용하는 공유 호스팅 서버는 미국 텍사스주 오스틴에 있으며 이 기사의 Pingdom 페이지 속도 도구 섹션 시작 부분에서 4개 위치를 테스트했습니다. 결과는 다음과 같습니다.

• 댈러스, 텍사스(미국) = 1.65초
• 캘리포니아 산호세(미국) = 2.53초
• 스웨덴 스톡홀름(EU) = 3.06초
• 멜버른(AUS) = 5.38초

이 문서에 언급된 모든 단계를 통해 사이트를 최적화했으므로 로드 시간은 다음과 같습니다.

• 댈러스, 텍사스(미국) = 0.63초
• 캘리포니아 산호세(미국) = 0.76초
• 스톡홀름, 스웨덴(EU) = 1.21초
• 멜버른(AUS) = 2.24초

이 시간을 사용하여 사이트에서 CDN을 사용하도록 설정할 때 WordPress 로딩 시간을 비교할 것입니다.

우리는 이 시대가 매우 다르다는 것을 알 수 있습니다. 데이터가 달라스에 있는 방문자보다 우리 서버 위치에서 호주 방문자에게 더 먼 거리를 이동해야 하기 때문입니다. CDN은 이러한 로딩 시간을 줄이는 데 도움이 될 것입니다.

CDN은 지리적으로 분산된 서버 프록시 및 해당 데이터 센터의 네트워크입니다. 그들의 주요 목표는 방문자에게 가장 가까운 서버에서 방문자에게 사이트 콘텐츠를 배포하는 것입니다. 즉, 웹사이트의 정적 콘텐츠(이미지, JS, CSS 등)가 전 세계에 퍼져 있는 해당 서버에서 제공되므로 모든 사용자가 사이트를 더 빠르게 로드할 수 있습니다.

WordPress CDN을 활용하면 다음과 같은 다양한 이점이 있습니다.

• 이동해야 하는 시간 및/또는 지연인 지연 시간을 줄입니다.
• 브라우저가 서버에서 데이터의 첫 번째 바이트를 수신하기 전에 기다려야 하는 시간을 측정하는 첫 번째 바이트까지의 시간(TTFB)을 줄입니다.
• 더 빠른 페이지 로드 시간과 호스팅(원본) 서버의 부담을 줄이기 위해 캐시에서 콘텐츠를 제공합니다.
• 멀티플렉싱, 병렬 처리, 서버 푸시 및 HPACK 압축을 활용하기 위해 보안 연결을 통해 HTTP/2를 활용합니다.
• 더 작은 HTML, 스타일시트 및 JavaScript 파일을 보장하기 위해 GZIP 또는 Brotli로 데이터를 압축합니다.

요즘 CDN은 특히 보안 부서에서 많은 다른 기능을 제공합니다. 일반적으로 DDoS 보호, 봇 탐지/방지 등을 제공합니다.

Cloudflare라고 하는 가장 인기 있는 CDN 중 하나를 살펴보겠습니다. 그들은 글로벌 CDN 사용을 포함하는 무료 패키지를 제공하며 그것이 바로 우리가 필요로 하는 것입니다.

클라우드플레어

먼저 cloudflare.com으로 이동하여 새 무료 계정에 가입하세요. 계정을 만든 후 정적 콘텐츠(자산)를 제공하려면 Cloudflare에서 웹사이트를 설정해야 합니다.

새 Cloudflare 계정에 로그인하면 DNS 레코드를 자동으로 검색하기 위해 웹사이트(도메인)를 추가하라는 메시지가 표시됩니다.

도메인을 입력하고 "스캔 시작"을 클릭하십시오. 하위 도메인( speed.gregorcapuder.com )을 사용하고 있지만 루트 도메인인 gregorcapuder.com 만 입력해야 했습니다. 스캔 부분을 완료하는 데 약 1분이 걸렸으며 그 동안 진행 상황을 설명하는 짧은 비디오를 볼 수 있습니다. 스캔이 완료되면 "계속" 버튼을 클릭할 수 있습니다.

다음 단계에서는 Cloudflare가 도메인에 대해 찾을 수 있는 모든 DNS 레코드를 볼 수 있습니다. 여기에 누락된 레코드를 추가해야 하므로 목록을 살펴보고 누락된 항목이 있는지 확인합니다. 이 예에서는 speed 하위 도메인이 누락되어 목록에 추가했습니다. 이름 입력에 "speed"(내 하위 도메인 이름)를 입력하고 IPv4 주소 에 기본 도메인(gregorcapuder.com)과 동일한 IP 주소를 입력한 다음 "레코드 추가"를 클릭했습니다. 아래 스크린샷에서 볼 수 있듯이, 저는 기본 도메인과 속도 하위 도메인에 대해 Cloudflare를 활성화했습니다(구름 뒤에 화살표가 있는 주황색 구름으로 표시됨). 즉, 이 두 웹 사이트에서 트래픽이 Cloudflare에 의해 처리되고 보호됩니다.

DNS 레코드 작업이 끝나면 "무료 웹 사이트" 계획을 선택하고 계속 진행하는 다음 단계로 계속 진행할 수 있습니다.

웹사이트에서 Cloudflare를 활성화하는 마지막 단계는 도메인 등록기관의 대시보드(도메인을 구입한 곳)에 로그인하고 도메인의 네임서버를 변경하는 것입니다. 새 네임서버가 적용되기까지 최대 48시간이 걸린다고 명시되어 있지만 제 경우에는 1시간 만에 업데이트 되었습니다. 그 동안에는 웹사이트 다운타임이 없으므로 걱정하지 마십시오.

사이트의 네임서버가 업데이트되면 Cloudflare 웹사이트의 상태가 "활성"으로 변경되는 것을 볼 수 있습니다.

대시보드의 모든 Cloudflare 설정은 기본적으로 그대로 두고 변경한 것은 보안 수준뿐입니다. 방화벽 탭으로 이동하여 "보안 수준"을 낮음 으로 조정합니다. 방문자가 잘못된 공격자 탐지에 대해 "도전 페이지"를 받는 것을 원하지 않기 때문입니다.

이제 Cloudflare 측을 설정했으므로 WP Rocket 플러그인에서 Cloudflare 설정도 활성화해야 합니다.

WordPress 관리자 대시보드에 로그인하고 WP Rocket 플러그인 설정으로 이동합니다. "CDN" 탭으로 이동하여 Cloudflare 설정 표시 탭을 활성화하고 설정을 저장합니다. 그러면 WP Rocket 설정에 새로운 "Cloudflare" 탭이 표시되며 열어야 합니다. 거기에 Cloudflare 계정 이메일, 도메인을 입력해야 하며 Cloudflare 글로벌 API 키도 복사하여 붙여넣어야 합니다. 전역 API 키를 검색하려면 Cloudflare 대시보드(개요 탭)로 이동하여 "API 키 가져오기" 링크를 클릭하십시오. 이 새 페이지에 "API 키" 섹션이 표시되며 "글로벌 API 키" 행에 대한 "API 키 보기" 버튼을 클릭해야 합니다. 글로벌 API 키를 WP Rocket 설정에 붙여넣으면 WP Rocket에서 "최적 설정" 옵션을 활성화하는 것이 좋습니다. 설정을 저장한 다음 "Cloudflare 캐시 지우기" 버튼을 클릭하여 모든 것이 제대로 작동하는지 확인합니다.

이제 CDN이 구성되었으므로 다른 위치에서 로드 시간을 다시 테스트하고 개선 사항을 확인할 수 있습니다(Pingdom 테스트).

• 댈러스, 텍사스(미국) = 0.54초
• 캘리포니아 산호세(미국) = 0.70초
• 스웨덴 스톡홀름(EU) = 0.91초
• 멜버른(AUS) = 1.16초

예상대로 유럽과 호주의 로딩 시간이 가장 많이 개선되었습니다. 그리고 모든 로딩 시간은 약 1초 이하입니다. 그것은 좋은 로딩 시간입니다!

사이트를 테스트할 때 한 위치에 대해 페이지 속도 도구를 한 번만 실행하여 테스트하지 마십시오. 몇 번이고 테스트해야 합니다. 특정 위치에 대해 도구를 처음 실행할 때 캐시된 파일은 가장 가까운 Cloudflare 서버에 먼저 저장되어야 하며, 각 후속 테스트는 캐시된 버전의 실제 로드 시간을 보여주어야 합니다. 특정 위치에서 페이지가 얼마나 빨리 로드되는지에 대한 좋은 평균을 얻으려면 3-5번 테스트하는 것이 좋습니다.

최종 결과

최종 페이지 속도 도구 점수는 다음과 같습니다.

• Google PageSpeed ​​통계
  • 모바일: 91
  • 데스크탑: 97

• GTmetrix
  • 페이지 속도: 98
  • Y슬로우: 91

다음은 스크린샷입니다.

최적화 전후의 GTmetrix 데이터를 비교해 보겠습니다.

모든 면에서 웹사이트 성능을 개선했습니다. 웹사이트는 더 빠르게 로드되고, 사용자에게 사이트를 표시하는 데 더 적은 요청이 필요하며, 더 적은 대역폭을 사용하고 전 세계 방문자에게 빠르게 로드됩니다. 동시에 웹사이트의 모든 기능과 스타일을 처음과 동일하게 유지했습니다. 엄청난!

끝으로 우리는 완료한 각 개별 최적화 단계에 대한 결과를 시각적으로 멋지게 표현했습니다.

결론

이 궁극적인 WordPress 페이지 속도 최적화 가이드에서는 웹사이트 성능을 획기적으로 개선하기 위해 수행할 수 있는 더 중요한 단계를 살펴보았습니다. 이 기사의 조언을 따르면 사이트가 간결하고 빨라져 페이지 로딩 시간과 사용자 경험이 향상됩니다. 이러한 개선 사항은 또한 더 많은 돈을 가져오고 서버 비용을 절약하는 데 도움이 될 수 있으므로 모두에게 윈-윈입니다!

속도가 전부가 아니라 웹사이트 퍼즐의 또 다른 조각이라는 말로 이 기사를 마무리하고 싶습니다. 우리는 인간, 잠재 고객을 위한 웹사이트를 구축하므로 항상 염두에 두십시오. 콘텐츠, 멀티미디어, 디자인, 사용자 경험 및 페이지 속도 사이에서 적절한 균형을 찾으십시오. 페이지 속도와 페이지 속도 도구 점수에 집착하지 마십시오. 방문자 경험을 개선하는 한 목표는 달성될 것입니다.

페이지 로드 시간을 크게 개선할 수 있는 웹사이트 최적화 단계를 놓쳤습니까? 아래 의견에 알려주십시오!

우리 기사가 유용하고 단계를 따랐다면 아래 의견에 어떤 종류의 개선 사항을 달성했는지 알려주십시오.