웹사이트 속도 테스트 실행: 모범 사례

오늘날과 같이 빠르게 변화하는 세상에서는 느린 웹사이트가 문제입니다. 인터넷 속도의 발전과 함께 빠른 로딩 웹사이트에 대한 수요가 생겼습니다.

웹사이트의 속도는 사이트의 사용자 경험에 큰 영향을 미칩니다. 사실 사용자 경험에 가장 큰 영향을 미치는 것은 아마도 하나일 것입니다. 사용자는 웹사이트가 로드되는 시간이 길어질수록 더욱 짜증이 나고 짜증이 나고 로드 시간이 너무 오래 걸리면 웹사이트를 포기할 것입니다.

느린 웹사이트는 이탈률이 더 높고 전환율이 낮으며 일반적으로 방문자가 사용하기에는 불편합니다.

사이트 속도와 관련하여 사이트의 위치를 ​​이해하려면 실제 환경과 관련하여 사이트의 성능을 정확하게 측정할 수 있어야 합니다.

이 가이드에서는 사이트 속도 테스트를 정확하게 구성하고 결과를 해석하여 WordPress 사이트 성능에 대한 의미 있는 통찰력을 얻는 방법을 보여줍니다.

사이트 속도와 관련하여 방문자의 경험을 이해하려는 경우 두 가지 유형의 모니터링이 있습니다.

• 각 실제 방문자에 대해 사이트를 로드하는 데 걸리는 시간을 기반으로 한 실제 사용자 데이터(예: Pingdom 실제 사용자 모니터링).
• 대부분의 속도 테스트 도구가 실행되고 우리가 집중하는 종합 속도 테스트입니다.

합성 속도 테스트는 실행하기가 훨씬 쉽고 속도 테스트를 적절하게 구성하면 방문자가 경험하게 될 실제 로드 시간과 매우 정확한 결과를 얻을 수 있습니다.

또한 종합 테스트를 통해 웹사이트를 구축하는 동안에도 사이트의 성능을 측정할 수 있으므로 사이트를 완성하고 공개적으로 시작하기 전에 잠재적인 문제에 플래그를 지정할 수 있습니다.

예를 들어, 클라이언트 웹사이트를 구축하는 경우 합성 속도 테스트를 통해 클라이언트에게 웹사이트를 넘기기 전에 최적화할 수 있습니다.

다시 말하지만, 합성 테스트는 유용한 데이터를 얻을 수 있는 방식으로 구성하는 경우에만 가치가 있습니다. 방법은 다음과 같습니다.

모든 속도 테스트 도구가 동일한 것은 아니므로 실행하려는 테스트 유형에 가장 적합한 옵션을 선택하는 것이 좋습니다.

다양한 도구는 다양한 데이터/메트릭 및 더 많거나 적은 구성 옵션을 제공합니다. 다음 몇 섹션에서 이러한 구성 옵션이 중요한 이유를 다룰 것입니다.

다음은 가장 인기 있고 유용한 도구입니다.

• GTmetrix – 잘 설계된 인터페이스를 갖춘 유연한 도구입니다. 구성 옵션에 액세스하려면 무료 계정에 등록해야 합니다. 그러나 무료 버전은 더 이상 모바일 장치에 대한 테스트를 허용하지 않습니다.
• WebPageTest – 가장 구성 가능한 속도 테스트 도구. 다양한 시나리오를 테스트하는 데 적합합니다. 그러나 인터페이스는 약간 구식입니다. MachMetrics를 사용하여 자동화된 일일 테스트를 실행할 수 있습니다.
• Google PageSpeed ​​Insights – Lighthouse의 합성 테스트 데이터와 Google의 실제 성능 데이터가 포함됩니다(실제 데이터는 사이트 트래픽이 충분한 경우에만 사용할 수 있음).
• Lighthouse – 웹 성능 분석을 위한 오픈 소스 도구입니다. Google PageSpeed ​​Insights는 Lighthouse를 기반으로 하거나 Chrome 개발자 도구 또는 web.dev에서 Lighthouse를 실행할 수도 있습니다.
• Pingdom 도구 – 무료 도구에는 구성 옵션이 없습니다. 그러나 인터페이스는 잘 설계되었습니다. 또한 위에서 언급한 유료 실제 사용자 모니터링 서비스를 제공합니다.
• Uptrends – 모든 중요한 구성 옵션을 지원하는 잘 설계된 도구입니다.
• 빠름 또는 느림 – Wordfence에서 전역 로드 시간을 평가하기 위한 훌륭한 도구입니다. 하나의 테스트에서 18개국의 테스트를 실행합니다.

하나의 도구만 고집할 필요는 없습니다. 각 옵션은 특정 상황에서 유용할 수 있습니다. 예를 들어 WebPageTest는 매우 유연하기 때문에 한 번에 한 위치를 테스트하는 데 적합하고 Fast 또는 Slow는 전 세계에서 사이트의 로드 시간이 어떻게 변하는지 빠르게 측정하는 데 유용합니다.

속도 테스트를 실행하는 물리적 위치는 결과에 영향을 미칩니다. 이러한 이유로 대상 고객과 최대한 가까운 테스트 위치를 선택하려고 합니다.

여러 위치 또는 전 세계의 방문자를 대상으로 하는 경우 사이트의 글로벌 로드 시간을 더 잘 파악하기 위해 여러 위치에서 여러 테스트를 실행하고 싶을 것입니다.

방문자가 사용하는 장치는 성능에 큰 영향을 줄 수 있습니다.

예를 들어, 저전력 스마트폰은 JavaScript를 처리하는 데 시간이 더 오래 걸립니다. 즉, JavaScript를 많이 사용하는 웹 사이트는 고성능 데스크톱 컴퓨터에서보다 해당 장치에서 훨씬 느리게 로드됩니다.

이러한 이유로 최소한 여러 장치를 테스트하고 있는지 확인하고 싶습니다. 여러 웹 브라우저를 테스트하여 브라우저 간에 차이점이 있는지 확인할 수도 있습니다.

현실 세계에서 모든 방문자가 동일한 연결 속도를 가지는 것은 아닙니다. 일부는 고속 인터넷에 연결되어 있고 다른 일부는 3G 또는 4G 네트워크에서 검색할 수 있습니다.

Pingdom과 같은 일부 테스트 도구는 모든 테스트에 초고속 무제한 연결을 사용합니다. WebPageTest 및 GTmetrix와 같은 다른 도구를 사용하면 실제 상황을 더 가깝게 모방하는 제한 연결을 선택할 수 있습니다.

이러한 이유로 귀하의 사이트는 종종 Pingdom에서 더 빨리 로드되는 것으로 "나타납니다". 그러나 실제 사용자의 경험을 정확하게 측정하려면 사용자의 실제 속도를 모방하는 제한 연결을 사용하는 것이 좋습니다.

마지막으로, 결과를 왜곡할 수 있는 단일 테스트 변동성을 피하기 위해 여러 테스트를 실행해야 합니다. 일회성 테스트에서는 대부분의 방문자가 볼 때보다 사이트가 더 느리거나 빠르게 보이는 이상치 결과를 얻을 수 있습니다.

일부 도구를 사용하면 여러 테스트를 쉽게 실행할 수 있습니다. 예를 들어 한 번에 최대 9개의 개별 테스트를 실행하고 중간 값을 사용하도록 WebPageTest를 구성할 수 있습니다.

이제 위의 속도 테스트 도구에서 볼 수 있는 다양한 메트릭을 이해하는 방법에 대해 알아보겠습니다.

Core Web Vitals는 사이트의 사용자 경험을 포착하는 데 중점을 둔 세 가지 측정항목을 포함하는 Google의 새로운 이니셔티브입니다.

사이트 속도 측면에서 가장 중요한 지표는 LCP(Large Contentful Paint)입니다. LCP는 사이트의 "주요" 콘텐츠가 로드되는 데 걸리는 시간을 측정합니다. 사이트의 주요 콘텐츠가 빠르게 로드되는 경우 방문자는 나머지 콘텐츠를 로드하는 데 시간이 더 오래 걸리더라도 사이트가 빠르게 로드되는 것으로 인식할 것입니다.

"주요" 콘텐츠는 페이지마다 다르지만 일반적으로 사이트의 영웅 섹션에 있는 헤더 텍스트 또는 이미지입니다. 예를 들어 다음은 데스크톱 방문자를 위한 Elementor 홈페이지의 LCP 요소입니다.

PageSpeed ​​Insights를 사용하여 사이트의 "주요" 콘텐츠를 찾을 수 있습니다. 요소가 각각 다를 수 있으므로 모바일과 데스크톱을 모두 테스트해야 합니다.

Google 은 LCP 시간을 2.5초 미만으로 권장 합니다 .

LCP를 개선하려면 Time to First Byte(이 목록의 또 다른 메트릭) 속도를 높이고 캐싱을 사용하고 다른 WordPress 성능 모범 사례를 구현해야 합니다. 중요한 CSS를 인라인하고 JavaScript 렌더링 차단을 피하는 것도 이 지표의 속도를 높이는 데 특히 유용할 수 있습니다.

페이지 로드 시간은 페이지 로드의 의미에 대한 여러 정의가 있기 때문에 이해하기 까다로운 측정항목입니다. 더 혼란을 더하기 위해 다른 속도 테스트 도구는 다른 페이지 로드 정의를 사용합니다. 이것이 두 개의 다른 도구를 비교할 때 약간 일치하지 않는 데이터가 표시될 수 있는 이유 중 하나입니다.

여기서 핵심 질문은 "페이지 로딩이 언제 완료됩니까?"입니다.

다음은 가장 일반적인 두 가지 정의입니다.

• 문서 완료 – 모든 정적 콘텐츠가 로드된 지점입니다. 기술적인 측면에서 onLoad 이벤트가 발생할 때입니다.

• 완전히 로드됨 – 모든 네트워크 활동이 2초 동안 중지된 지점입니다.

완전히 로드된 시간은 모든 정적 콘텐츠가 로드된 후에도 계속 로드될 수 있는 추가 비하인드 스크립트를 고려하기 때문에 거의 항상 더 높습니다.

WP Rocket과 같은 올인원 성능 플러그인을 사용하면 모든 중요한 모범 사례를 구현하여 로드 시간을 개선할 수 있습니다.

TTFB(Time to First Byte)는 서버 응답성의 일반적인 측정이며 SRT(서버 응답 시간)라고도 합니다. 서버에 대한 연결을 생성하고 콘텐츠의 첫 번째 바이트를 다운로드하는 데 걸리는 시간을 측정합니다.

Google 은 TTFB가 200ms 미만일 것을 권장 합니다.

TTFB는 백엔드 성능의 영향을 많이 받습니다. 높은 TTFB의 두 가지 가장 큰 원인은 느린 호스팅 및/또는 느린 DNS 공급자입니다.

First Contentful Paint(FCP) 및 First meaningful Paint(FMP)는 위의 Largest Contentful Paint 메트릭과 몇 가지 유사점을 공유합니다.

첫 번째 콘텐츠가 포함된 페인트 는 첫 번째 텍스트 또는 이미지를 그리는 데 걸리는 시간을 측정합니다. 이것과 가장 큰 콘텐츠가 포함된 페인트의 주요 차이점은 FCP가 해당 콘텐츠의 "중요도"를 측정하려고 하지 않는다는 것입니다. 대신 "모든" 콘텐츠의 첫 번째 부분만 찾습니다.

첫 번째 의미 있는 페인트 는 페이지의 주요 콘텐츠가 사용자에게 표시되는 시점을 측정합니다. 그러나 몇 가지 기술적인 문제로 인해 Google은 Lighthouse 6.0에서 첫 번째 의미 있는 페인트를 더 이상 사용하지 않고 가장 큰 콘텐츠가 있는 페인트로 대체했습니다. 그럼에도 불구하고 일부 도구에서는 여전히 FMP를 볼 수 있습니다.

Google은 FCP 및 FMP 시간이 모두 2초 미만일 것을 권장합니다 .

LCP를 최적화하면 이러한 측정항목도 개선됩니다.

TTI(Time to Interactive)는 사이트가 방문자와 완전히 상호작용하는 데 걸리는 시간을 측정합니다.

예를 들어, Accordion 위젯을 사용하여 아코디언 섹션을 추가했다고 가정해 보겠습니다. TTI는 방문자가 아코디언 토글을 클릭하고 아코디언 섹션을 확장하여 사이트가 응답하도록 하는 데 걸리는 시간을 측정합니다.

Google 은 TTI가 3.8초 미만인 것을 권장 합니다 .

페이지를 로드하려면 방문자의 브라우저가 사이트의 모든 단일 리소스에 대해 사이트 서버(또는 타사 리소스의 서버)에 HTTP 요청을 해야 합니다.

• 하나의 이미지 = 하나의 HTTP 요청
• 하나의 JavaScript 스크립트 = 하나의 HTTP 요청
• 하나의 CSS 스타일시트 = 하나의 HTTP 요청
• 등.

사이트에 얼마나 많은 HTTP 요청이 있어야 하는지에 대한 확고하고 빠른 규칙은 없습니다. 그러나 일반적으로 사이트에 필요한 HTTP 요청이 적을수록 로드 속도가 빨라집니다.

그러나 모든 HTTP 요청이 동일한 것은 아닙니다. 일부는 다른 요청보다 크거나 로드하는 데 더 오래 걸립니다. 대부분의 속도 테스트 도구가 제공하는 폭포수 분석 에서 각 HTTP 요청이 로드되는 순서를 볼 수 있습니다. Uptrends에서는 다음과 같이 표시됩니다.

CSS/JavaScript 파일을 결합하고, 이미지 사용을 제한하고, Asset CleanUp 또는 Perfmatters와 같은 스크립트 관리 플러그인을 사용하여 HTTP 요청을 줄일 수 있습니다. 또한 대부분의 플러그인이 자체 HTTP 요청을 추가하므로 플러그인 사용을 제한해야 합니다. Elementor Pro는 단일 플러그인에서 다양한 기능(예: 양식, 슬라이더, 갤러리 등)에 대한 액세스를 제공하여 플러그인 사용을 제거하는 데 도움이 될 수 있습니다.

페이지 크기는 페이지의 전체 크기를 나타냅니다. 페이지의 모든 코드, 이미지, 스크립트 등의 파일 크기를 집계한 것입니다.

일반적으로 사이트의 페이지 크기가 작을수록 방문자의 브라우저가 사이트를 로드하기 위해 더 적은 데이터를 다운로드해야 하므로 로드 속도가 빨라집니다.

페이지 크기를 줄이기 위한 몇 가지 일반적인 전술은 Gzip 또는 Brotli와 같은 서버 수준 압축을 사용하여 이미지를 압축하고 코드를 축소하는 것입니다.

사이트의 성능을 이해하는 것은 웹사이트를 최적화하는 데 필수적입니다. 데이터가 없으면 사이트의 현재 위치와 개선할 수 있는 부분을 알 수 없습니다.

그러나 의미 있는 데이터를 수집하려면 사이트의 URL을 단일 속도 테스트 도구에 연결하고 하루에 한 번 호출하는 것만큼 간단하지 않습니다.

테스트의 특정 구성에 주의를 기울이는 것이 중요합니다. 위치, 장치 및 연결 속도를 조정하여 다양한 유형의 사용자에 대해 사이트가 수행되는 방식에 대한 정확한 그림을 얻을 수 있습니다.

데이터가 있으면 다양한 측정항목과 의미도 이해해야 합니다. 느린 시간을 첫 번째 바이트로 수정하는 것은 가장 큰 콘텐츠가 포함된 페인트 시간을 개선하는 것과 다른 전술이 필요할 수 있지만 성능 모범 사례 측면에서 항상 일부 중복이 있습니다.

WordPress에서 웹 사이트 속도를 테스트하는 방법에 대해 여전히 질문이 있습니까? 댓글로 문의주세요!