행복한 사용자, 더 높은 순위를 위한 서버 응답 시간 단축

페이지 속도 향상과 관련하여 서버 응답 시간은 종종 간과됩니다.

그러나 사이트의 순위를 높일 수 있습니다. 사용자는 빠른 사이트를 좋아하므로 Google은 빠른 사이트를 좋아합니다. 이 기사에서는 서버 응답 시간을 줄이는 방법을 보여줍니다. 또한 페이지 속도를 향상시키는 몇 가지 다른 방법도 제공합니다.

서버 응답 시간이 얼마나 중요합니까?

SRT(서버 응답 시간)는 웹 클라이언트가 요청(예: 링크 클릭 또는 주소 표시줄에 URL 입력)을 하고 서버가 해당 요청에 응답하는 시간입니다.

우수한 SRT와 속도에 최적화된 사이트를 사용하면 웹사이트가 거의 즉시 로드되는 것처럼 보입니다. 그렇지 않으면 페이지를 로드하는 데 시간이 더 오래 걸리므로 사용자 경험과 궁극적으로 검색 엔진 순위가 손상될 수 있습니다.

SRT는 TTFB(Time to First Byte)라는 단위로 측정됩니다. TTFB는 HTTP 클라이언트가 요청을 하고 데이터의 첫 번째 바이트를 수신하는 사이의 시간 길이를 측정합니다. 밀리초 단위로 측정됩니다.

좋은 것, 나쁜 것, 수용 가능한 TTFB를 구성하는 것은 다양합니다. 다음은 몇 가지 일반적인 규칙입니다.

• 100ms보다 빠를수록 좋습니다.
• 100~200ms가 좋습니다. Google PageSpeed ​​Insights는 SRT를 200ms 미만으로 유지할 것을 권장합니다.
• 200ms–1초는 허용되지만 개선의 여지가 있습니다.
• 1초 이상이면 문제가 됩니다.

시간의 작은 변화가 큰 변화를 가져올 수 있습니까? 1초 지연으로도 전자상거래 사이트에서 연간 $25,000–$125,000... 또는 그 이상의 비용이 발생할 수 있습니다!

서버 응답 시간이 SEO에 어떤 영향을 미칩니까?

Google은 약 10년 동안 SRT를 순위 요소로 사용해 왔습니다. 보다 최근에 Google Search Console은 사용자 경험에 중점을 둔 일련의 웹사이트 성능 측정항목을 추적하는 핵심 성능 평가 섹션을 출시했습니다.

Forrester Research의 연구에 따르면 웹 사용자의 절반 이상이 사이트가 2초 이내에 로드될 것으로 기대합니다. 로딩하는데 3초 이상 걸리면 사용자의 40%가 포기하고 떠납니다.

로드 시간이 더 오래 걸리는 사이트는 일반적으로 이탈률이 더 높고 평균 방문 시간이 더 짧습니다. Pingdom 연구에 따르면 "로드하는 데 3초 미만이 소요되는 웹 사이트의 경우 이탈률이 10% 미만이었지만 로드 시간이 4초인 경우 24%, 로드 시간 5초인 경우 38%로 급증했습니다. "

느린 사이트는 열악한 사용자 경험을 의미하며 검색 엔진은 그에 따라 응답합니다.

서버 응답 시간을 줄이는 것은 세 단계로 요약됩니다.

1. 서버 응답 시간을 측정합니다.
2. 개선이 필요한 영역을 식별합니다.
3. 팀과 협력하여 이러한 영역을 해결하십시오.

SRT를 확인하는 방법

사용할 수 있는 도구가 많이 있습니다.

GTMetrix

GTMetrix에는 무료 버전과 유료 버전이 있습니다. SRT를 분석하고, 페이지를 모니터링하고, 모바일 장치에서 사이트 속도를 테스트할 수 있습니다. URL을 입력하기만 하면 SRT 데이터도 포함된 페이지 로드 시간에 대한 전체 점수를 볼 수 있습니다.

그런 다음 폭포 차트를 사용하여 로드된 순서대로 모든 요소를 ​​볼 수 있습니다. 이를 통해 사이트 속도를 저하시키는 요청을 정확히 표시하여 문제 영역을 식별하고 디버그할 수 있습니다.

물론 서버 응답 시간은 페이지 속도에 기여하는 많은 요소의 일부일 뿐입니다.

폭포 차트에서 개별 항목 위로 마우스를 가져가면 각 요청에 대한 자세한 정보를 얻을 수 있습니다. 여기에서 서버에서 대기한 결과 로딩 시간이 얼마나 되는지 확인할 수 있습니다.

무료 계정을 설정하면 타이밍 탭을 사용하여 가장 중요한 TTFB를 비롯한 기타 관련 측정항목을 볼 수 있습니다.

Google PageSpeed ​​Insights(PSI)

이 무료 도구에 URL을 입력하면 전체 점수와 몇 가지 유용한 측정항목을 볼 수 있습니다. 다음은 모양의 예입니다.

PSI는 사이트의 모바일 및 데스크톱 버전에 대한 통찰력을 제공하고 개선할 수 있는 사항에 대한 중요한 정보를 제공합니다. Chrome 사용자 경험 보고서를 기반으로 하는 실제 "현장" 데이터와 Lighthouse의 실험실 데이터를 혼합하여 사용하여 페이지의 성능을 추정합니다.

다음은 특히 SRT와 관련된 Google 페이지 인사이트가 측정하는 측정항목입니다.

• FCP( First Contentful Paint ): 이 측정항목은 페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정합니다.
• 누적 레이아웃 이동 : CLS는 페이지의 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동에 대한 모든 개별 레이아웃 이동 점수의 합계를 측정합니다.
• TTI( Time to Interactive ): 페이지가 완전히 상호작용하는 데 걸리는 시간을 측정합니다. Google에 따르면 페이지는 페이지에 유용한 콘텐츠가 표시되고 이벤트 핸들러가 가장 눈에 잘 띄는 페이지 요소에 등록되고 페이지가 50밀리초로 사용자 상호작용에 응답할 때 완전한 대화형 페이지입니다.
• 총 차단 시간 : 총 차단 시간(TBT) 메트릭은 입력 응답을 방지할 수 있을 만큼 충분히 오랫동안 메인 스레드가 차단된 FCP와 TTI 사이의 총 시간을 측정합니다.

높은 점수의 경우 PSI는 200ms 미만의 서버 응답 시간을 예상합니다. SRT가 그보다 느린 경우 "기회" 섹션에서 알림을 받게 됩니다.

서버 응답 시간을 줄이는 방법

궁극적으로 서버 응답을 느리게 할 수 있는 수십 가지 잠재적 요인이 있습니다. 느린 애플리케이션 논리, 느린 데이터베이스 쿼리, 느린 라우팅, 프레임워크, 라이브러리, 리소스 CPU 부족 또는 메모리 부족입니다.

모든 문제를 해결할 수는 없지만 개발 팀과 협력하여 더 많은 기술 영역을 찾고 수정할 수 있습니다.

• 느린 애플리케이션 논리 : 코드 프로파일링 도구를 사용하여 사이트에서 사용 중인 종속성과 이러한 종속성 각각을 로드하는 데 걸리는 시간을 결정하는 데 도움이 됩니다.
• 느린 데이터베이스 쿼리 : 데이터베이스 쿼리가 효율적으로 실행되지 않을 때 발생합니다. 설상가상으로, "underthe hood"를 확인하지 않는 한 그들이 저조한 실적을 내고 있는지조차 모를 수 있습니다. 느린 데이터베이스 쿼리는 더 많은 작업이 필요하고 더 많은 CPU 리소스를 사용합니다.
• 느린 라우팅 : 일반적으로 가장 많이 방문한 페이지와 콘텐츠를 라우팅 대기열의 맨 위에 배치하여 해당 위치를 높은 우선 순위로 지정하려고 합니다. 느리게 실행되는 경우 특정 위치에 더 많은 경로를 추가할 수도 있습니다.
• 리소스 CPU 기아 : 사이트에서 너무 많은 플러그인 또는 스크립트를 실행하면 리소스 CPU 기아가 발생할 수 있습니다. 팀과 협력하여 자주 사용하지 않는 리소스 집약적인 플러그인을 제거하고 불필요한 스크립트를 제거하십시오.

개발자 팀과 일대일 없이 서버 응답을 개선하는 데 도움이 될 수 있는 다른 구체적인 단계가 있습니다.

빠르고 전용 호스트 찾기

현재 SRT가 느린 쪽이라면 더 빠른 호스트를 찾는 것이 좋습니다. 몇 가지 생각해 볼 것이 있습니다.

예산이 있다면 전용 호스팅을 선택하십시오. 이것은 단순히 다른 사이트와 서버를 공유하지 않는다는 것을 의미합니다. 공유 호스팅이 좋은 출발이 될 수 있지만 일부 공유 호스팅 제공업체는 서버에 과부하를 주어 수익을 극대화하지만 웹사이트에 재앙을 초래합니다.

결정을 내리기 전에 리뷰를 읽고 권장 사항을 요청하십시오. 추천을 받으면 GTMetrix 또는 PSI를 사용하여 해당 사이트의 SRT를 확인하십시오.

구매하기 전에 공급자의 서버 속도를 확인할 수도 있습니다. 몇 가지 방법이 있습니다.

속도 확인 도구를 사용하십시오. 나는 Pickuphost의 무료 속도 확인 도구를 좋아합니다:

비교사이트를 확인하세요. 많은 인기 있는 웹 호스트의 평균 응답 시간에 대한 Invigital 보고서:

또한 간단한 비교 도구를 사용하여 56개의 서로 다른 측정항목에서 최대 4개의 호스팅 제공업체를 비교할 수 있습니다.

Bitcatcha는 전 세계의 다양한 위치에서 호스팅 속도를 비교할 수 있는 또 다른 도구이므로 현재 위치에 가장 적합한 것을 선택할 수 있습니다.

대상 고객과 지리적으로 가까운 서버가 있는 호스트를 선택해야 합니다. 이를 확인하는 쉬운 방법은 CDN을 사용하는 것입니다.

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

CDN(콘텐츠 전송 네트워크)은 온라인 콘텐츠를 더 빠르게 전달하기 위해 함께 작동하는 지리적으로 분산된 서버 그룹입니다. 귀하의 비즈니스가 그 초점이 지역에 국한되어 있지 않다면 전 세계의 사람들이 한 번쯤은 귀하의 콘텐츠에 액세스하기를 원할 것입니다.

CDN을 사용하면 사이트 방문자가 어디에 있든 최고의 사용자 경험을 얻을 수 있습니다. 전 세계 인터넷 트래픽의 절반 이상이 CDN을 통해 제공됩니다.

CDN은 웹사이트의 캐시된 버전을 전 세계 여러 위치에 저장합니다. 각 지역에는 자체 서버가 있으며 사용자의 위치와 가장 가까운 서버가 요청한 콘텐츠를 전달합니다. 작동 방식은 다음과 같습니다.

귀하의 웹사이트가 미국에서 호스팅되지만 호주의 사용자가 이 웹사이트에 액세스하려는 경우 SRT는 0.2~0.4초 느릴 수 있습니다. CDN은 이 문제를 완화하고 지리적 위치에 관계없이 일관되게 빠른 SRT를 제공합니다.

SRT에서 0.5초는 그리 많지 않은 것처럼 보일 수 있지만 방문자가 인지하는 로딩 시간에 영향을 미칩니다.

설정하려면 CDN을 선택하고 사이트를 등록해야 합니다. 수백 개의 CDN 제공업체 중에서 선택할 수 있습니다. CDN을 선택할 때 예상 트래픽 양, 제공하는 주요 미디어 유형 및 예산과 같은 요소를 고려하십시오.

CDN 제공업체에 등록하면 귀하 또는 귀하의 웹 개발자가 귀하의 웹사이트에서 이를 활성화해야 합니다. 호스팅 제공업체 및 콘텐츠 관리 시스템(CMS)에 따라 C 패널이나 플러그인을 사용하여 활성화합니다.

사이트를 호스팅하는 데 사용하는 제공업체가 아닌 다른 제공업체에서 도메인을 구입한 경우 해당 제공업체에서도 업데이트해야 합니다. 귀하 또는 귀하의 도메인 이름 등록 기관은 귀하의 도메인이 CDN 서버를 가리키도록 DNS 이름 서버 레코드를 수정해야 합니다.

SRT를 최적화한 후(하지만 아직 개발 팀의 관심이 있는 동안) 큰 영향을 미칠 수 있는 몇 가지 다른 페이지 속도 문제를 해결하고 싶을 수 있습니다.

사이트 속도를 향상시키는 더 많은 방법(SRT 이상)

스크립트 축소 및 최적화

사이트 로드 시간을 늘리는 가장 효과적인 방법 중 하나는 사이트에서 실행되는 스크립트를 감사하는 것입니다. 아직도 그 추적 스크립트를 사용하고 있습니까? 누군가 그 데이터로 뭔가를 하고 있습니까?

모든 작은 폐기물이 추가될 수 있습니다. PSI는 사이트에서 로드하는 스크립트와 로드하는 데 가장 많은 시간이 걸리는 스크립트를 보여줍니다. 종종 스크립트를 제거하는 것은 Google 태그 관리자에서 태그를 비활성화하는 것만큼 간단합니다.

WordPress를 사용하는 경우 스크립트 및 스타일 최적화 또는 자산 정리와 같이 불필요한 스크립트를 제거하는 데 도움이 되는 몇 가지 플러그인이 있습니다.

이미지 크기 조정 및 최적화

이미지를 최적화하는 가장 간단한 방법 중 하나는 이미지가 올바른 파일 형식인지 확인하는 것입니다. 일반적으로 PNG는 JPEG 파일에 비해 더 많은 공간을 차지합니다. 단순함을 위해 로고 및 차트와 같은 간단한 그래픽에는 PNG를 사용하고 다른 모든 항목에는 JPEG 형식을 사용하는 것이 좋습니다.

Google은 JPEG 2000이라는 형식을 권장하기 시작했습니다. 그러나 아직 많은 시스템이나 브라우저(Chrome 제외)와 호환되지 않기 때문에 일반적으로 이 형식을 사용하지 않습니다.

JPEG보다 약간 작은 파일 크기를 제공하는 WEB.P라는 형식도 있습니다. 그러나 그 차이는 미미합니다. 캐싱을 활성화하면(분 안에 자세히 설명) 눈에 띄는 차이가 없습니다.

지금은 대부분의 경우 기본 JPEG 형식을 60% 압축으로 사용합니다. JPEG 품질을 95%에서 80% 또는 75%로 줄이면 이미지가 보이는 방식에 거의 차이가 없을 수 있습니다. 이미지 품질과 파일 크기 사이의 적절한 균형을 찾기 위해 실험합니다.

많은 도구(일부 무료)도 이미지를 업로드하기 전에 최적화하는 데 도움이 될 수 있습니다. Jpeg.io와 Compressor는 두 가지 좋은 옵션입니다. WordPress, Smush 또는 Kraken.io 플러그인은 업로드할 때 이미지를 최적화합니다. 다른 CMS 플랫폼에서도 유사한 옵션을 사용할 수 있습니다.

캐싱 사용

캐싱은 품질이나 콘텐츠 측면에서 어떤 것도 희생하지 않으면서 사이트 속도를 향상시키는 가장 좋은 방법 중 하나입니다.

사용자가 사이트를 처음 방문할 때 서버는 JavaScript 파일, 이미지, HTML 문서 등을 다운로드해야 합니다. 캐싱은 사용자가 다음에 방문할 때 콘텐츠를 더 빨리 검색할 수 있도록 이러한 측면 중 일부를 기억하는 임시 저장소입니다.

캐싱을 활성화하려면 웹사이트의 .htaccess 파일에 작은 코드를 추가해야 합니다. 일반적으로 호스팅 사용자 영역 내의 파일 관리자를 통해 이 작업을 수행합니다. 이 코드는 사용자의 브라우저에 캐시할 대상과 회수 기간을 알려줍니다.

다음은 GTMetrix의 코드 예입니다.

다른 시간 동안 사이트의 여러 측면을 캐시하도록 코드를 변경할 수 있습니다. 더 자주 업데이트되는 파일 형식의 경우 더 짧은 캐싱 시간을 설정합니다.

상당히 정적인 경우 캐싱 시간이 더 길어질 수 있습니다. 자주 변경되거나 업데이트되는 파일에 대한 캐싱 시간이 너무 길면 재방문 사용자에게 사이트의 이전 캐시 버전이 표시될 수 있습니다.

(주의: .htaccess 파일에 문제가 발생하면 전체 사이트가 손상될 수 있습니다.)

일부 CMS 플랫폼에서는 플러그인을 사용하여 코딩 없이 캐싱을 활성화할 수도 있습니다. 가장 인기 있고 높은 평가를 받은 제품에는 WordPress용 W3 Total Cache 및 WP Rocket, Joomla용 SpeedCache가 있습니다.

CMS, 플러그인 및 테마를 최신 상태로 유지

CMS, 플러그인 또는 웹사이트 테마를 업데이트하라는 알림을 얼마나 자주 보십니까? 나중에 확인하고 모든 것을 잊어버릴 것이라고 생각하고 닫으십니까? 당장 그만둬!

CMS, 플러그인 및 웹사이트 테마의 오래된 버전은 페이지 속도를 크게 감소시킬 수 있습니다. 이러한 도구 및 플랫폼의 제작자는 이유가 있어 업데이트를 생성합니다. 대개 효율성과 속도를 개선하기 위한 것입니다.

(또 다른 문제도 있습니다. 오래된 CMS 플랫폼, 플러그인 및 테마는 웹사이트를 보안 침해에 취약하게 만들 수 있습니다. Malcare는 오래된 테마와 플러그인이 WordPress 사이트 해킹의 가장 흔한 원인 중 하나라고 보고했습니다.)

사이트의 스크립트와 마찬가지로 저장된 플러그인과 테마를 마지막으로 지운 것이 언제였습니까? 사용하지 않는 다운로드가 몇 개 있을 수 있습니다. 다운로드 및 설치한 모든 항목에 대해 정기적으로 빠른 감사를 실행하십시오.

결론

서버 응답 시간을 줄이면 사이트 방문자에게 더 나은 경험을 제공하고 이탈률을 줄이며 궁극적으로 검색 순위를 높일 수 있습니다.

• 작업 중인 위치에 대한 기준선이 있도록 먼저 SRT를 확인하십시오.
• 올바른 호스팅 제공업체와 서버를 선택하세요.
• CDN을 사용하여 지리적으로 더 가까운 서버의 사용자에게 콘텐츠를 제공합니다.
• 올바른 파일 유형을 선택하고 이미지 품질을 약간 낮추고 플러그인을 사용하여 파일 크기를 줄여 이미지를 최적화하십시오.
• 브라우저 캐싱을 사용하여 재방문자에게 더 나은 경험을 제공하십시오.
• CMS, 플러그인 및 웹사이트 테마가 모두 최신 상태인지 확인하십시오.

SRT와 SEO는 초와 밀리초가 정말로 중요한 영역입니다. 1초 1초 간격으로 방문자를 사이트에 더 오래 머물게 하고, 방문자가 계속 재방문하도록 하며, 사이트가 결과 페이지에서 탐나는 상위 위치에 오르는 데 도움이 됩니다.