링크모음 링크세상
링크세상 링크모음 링크 애니 웹툰 링크 드라마 영화 링크 세상의모든링크

벤치마크 서버를 사용하여 사이트 속도 향상 – SEO 이론

벤치마크 서버로 무엇을 합니까? 이를 사용하여 전 세계의 다른 서버에 최소한의 콘텐츠를 제공하고 웹 서버의 응답 속도를 확인합니다. 웹 서버가 뉴욕시에 있고 로스앤젤레스에서 페이지를 가져오는 경우 가져오기와 렌더링 사이의 지연 시간에 영향을 미치는 것은 무엇입니까?

최소한 당신의 술책 머신의 요청은 최소한 하나의 라우터로 전달되어야 합니다. 하지만 해당 라우터에 도달하려면 모뎀이나 멀티플렉서를 거쳐야 할 수도 있습니다. 가정 사용자는 모뎀을 사용합니다. T-1 이상의 회선을 사용하는 비즈니스 사용자는 멀티플렉서를 통과합니다.

인터넷 패킷의 평생 여정

귀하의 물리적 위치에서 모든 IP 요청 {패킷}은 인터넷 서비스 제공업체가 관리하는 근처 노드로 이동해야 합니다. 해당 노드는 주변에 있는 수백, 심지어 수천 명의 트래픽으로 인해 막힐 수 있습니다. 이는 모든 인터넷 사용자를 주요 간선으로 연결하는 이른바 ‘라스트 마일(Last Mile)’이다.

요청이 마지막 마일 노드를 통과하면 ISP 네트워크를 통해 가장 가까운 데이터 센터로 확대됩니다(여러 홉이 필요할 수 있음). 여기에서 귀하의 요청은 인터넷 교환 지점(IEP 또는 IXP)으로 이동됩니다. 예전에는 북미 지역에 아주 적은 수의 IXP가 있었지만 지금은 많아졌습니다.

MAE West, MAE Central 및 MAE East는 가장 오래되고 잘 알려진 북미 IXP입니다. 나는 MAE 거래소가 몇 년 동안 모두 폐쇄되었다고 생각합니다.

주요 ISP는 이러한 교환을 통해 서로 “피어링”합니다. 대략적으로 거대한 슈퍼 멀티플렉서라고 설명할 수 있을 것 같습니다. 멀티플렉서는 디멀티플렉서에 연결됩니다. 기본적으로 많은 라인을 모아서 멀티플렉서를 통해 해당 신호를 하나의 라인으로 결합하고 신호를 분리하여 DE멀티플렉서를 통해 여러 라인에 걸쳐 분할합니다. 멀티플렉서는 크거나 작을 수 있습니다.

어떤 경우든 우리의 가져오기 요청은 결국 인터넷 서비스 제공업체가 요청을 다른 사람에게 전달하는 하나 이상의 IXP로 끝나게 됩니다. 그들은 어느 것이 웹 서버에 최대한 가깝게 요청을 가장 잘 받을 수 있는지 알아낼 것입니다. 가져오기 요청이 여러 IXP를 통과하는 것은 드문 일이 아닙니다.

결국 요청은 마지막 IXP를 떠나 서버가 있는 곳으로 연결되는 트렁크를 처리하는 주요 서비스 제공자에게 전달됩니다. 이는 일반적으로 데이터 센터이며 데이터 센터에는 막대한 I/O 용량이 필요하기 때문에 해당 인터넷 연결은 일반적으로 소규모 고객 “라스트 마일” 연결과 그룹화되지 않습니다.

눈 깜짝할 사이에 핑이 울리다

따라서 모든 사람이 물어봐야 할 질문은 “가져오기 요청이 웹 서버에 도달하는 데 얼마나 걸리나요?”입니다.

옛날에는 연결 테스트를 요청합니다. 당신은 또한 추적 경로 (또는 트레이서트 O/S에 따라 다름) 기본 요청이 서버에 도달하는 데 걸리는 시간을 살펴보세요. 문제는 그러나 경로를 추적하고 추적하는 것은 완전한 기능을 갖춘 요청을 웹 서버에 보내는 것이 아니라는 것입니다. 브라우저가 웹 페이지를 요청할 때 더 정교한 요청을 보내고 훨씬 더 강력한 응답을 기대합니다. 또한 하드웨어는 다음 사항에 응답합니다. 하지만 웹 서버 애플리케이션은 얻다 또는 놓다 (기본 페이지 가져오기).

브라우저가 웹 서버에서 무엇이든 요청할 때 브라우저와 서버가 정보를 주고받으며 먼저 TCP 연결을 설정한 다음 암호화가 관련되어 있는지, 누군가 인증이 필요한지 여부 등을 결정하는 많은 핸드쉐이킹이 진행됩니다. 서버는 각 패킷(“봉투”)과 함께 메타 정보를 보내고 웹 문서 자체에도 메타 정보가 있습니다(서버 구성에 따라 다르며 때로는 다른 응용 프로그램에 따라 다름).

이 모든 작업에는 시간이 얼마나 걸리나요? 이것이 바로 Benchmark Server를 만드는 데 약간의 시간을 투자하고 싶은 이유입니다. 하위 도메인(또는 루트 호스트의 전용 폴더)을 설정한 다음 특수 문서를 만드는 것 외에 다른 작업을 수행할 필요가 없습니다.

벤치마크 문서에는 가능한 한 적은 데이터가 포함되어야 합니다. 자바스크립트나 CSS를 사용하지 말고, 그림도 삽입하지 마세요. 간단하고 기본적인 HTML 문서를 전달하고 싶을 뿐입니다.

루트 벤치마크 문서는 기준선을 설정합니다.

기준선은 벤치마크를 생성할 때 까다로운 작업입니다. 일반적으로 사람들은 벤치마크를 설정하기 위해 “한 번의 좋은 캡처”만 필요하다고 가정합니다. 실제로는 평균 응답 시간을 찾으려면 여러 이미지나 데이터 포인트를 캡처해야 합니다. 표준편차를 계산하는 것은 나쁠 것이 없습니다. SD는 허용 오차를 설정합니다. 향후 벤치마크 테스트가 이러한 허용 범위를 벗어나면 가져오기 경로 어딘가에 문제가 있다는 것을 알 수 있습니다.

타겟 고객이 어디에 있는지에 따라 전 세계에서 여러 벤치마크를 설정하는 것이 가장 좋습니다. 미국 이외의 많은 기업은 여전히 ​​미국에서 사이트를 호스팅하는 것을 선호합니다. 그러나 콘텐츠 전달 네트워크(Content Delivery Networks)와 주요 클라우드 호스팅 네트워크의 인기는 아마도 전 세계 대부분의 주요 웹사이트가 검색해야 하는 위치에 더 가깝게 미러링된다는 것을 의미할 것입니다.

두 대륙에서 비즈니스를 수행하는 경우 대륙당 2~3개의 액세스 포인트에서 벤치마크를 설정하는 것이 좋습니다. 액세스 포인트와 웹 서버 데이터 센터 사이의 물리적 거리는 액세스 포인트와 서버 사이에 존재하는 복잡성의 대략적인 근사치를 제공합니다.

여러 벤치마크 문서를 사용하여 요소 응답 시간 테스트

Reflective Dynamics 벤치마크 서버에 여러 문서를 추가하는 것을 고려했지만 {위치가 유출된 경우} 누군가가 이에 대해 크롤러를 실행하려는 유혹을 받을까 두렵습니다. 당신은 SEO와 크롤러입니다. 이는 웹사이트를 측정하는 잘못된 방법이지만 이 기사에서는 크롤러에 대해 더 이상 강의하지 않겠습니다.

벤치마크 서버에서 여러 문서를 생성하여 복잡성을 더할 수 있습니다. 예를 들어 문서 2의 HEAD 섹션에 있는 스타일시트에 대한 호출을 추가합니다. 문서 3의 HEAD 섹션에 있는 분석 스크립트에 대한 호출을 추가합니다. 문서 4에서 이러한 호출을 결합합니다.

지루하게 들린다면, 그렇습니다. 테스트해야 할 것을 테스트하십시오. 벤치마크 서버에 모든 것을 항상 보관할 필요는 없습니다. 실제로 개발자만 서버를 사용해야 합니다. 그러나 사이트 속도를 감사하려는 SEO는 벤치마크 서버를 요청해야 합니다. 귀하의 고객이나 고용주가 이를 제공하지 않을 수도 있지만 요청하는 것이 좋습니다.

페이지 응답 시간이 10초를 초과하는 경우에만 벤치마크 서버를 요청합니다. 과거에는 응답 시간이 30초 이상인 사이트에 대해서만 벤치마크를 사용했습니다.

페이지 속도에 영향을 미치는 것은 무엇입니까?

철저하지는 않지만 이 목록의 모든 항목은 특정 가져오기에서 인지된 페이지 속도에 영향을 미칠 수 있습니다(모두 함께 또는 일부만).

  1. 요청 장치의 사용 가능한 처리 능력
  2. 요청 장치에서 사용 가능한 메모리(저장 장치로 교체됩니까?)
  3. 사용 중인 브라우저(Chrome은 더 이상 가장 빠르지 않습니다. http://tinyurl.com/hmylnhz 참조)
  4. 요청 장치에 악성 코드 존재
  5. 장치-라우터 연결 품질
  6. 로컬 라우터의 상태
  7. 라스트 마일 연결 품질
  8. 로컬 ISP 네트워크 상태
  9. 사용자의 DNS 확인자
  10. 모든 주요 피어링 핸드오프(IXP 전송)
  11. 데이터센터 로컬 ISP 네트워크 상태
  12. 데이터센터 네트워크 상태
  13. 사용 가능한 서버 연결
  14. 사용 가능한 서버 처리 능력
  15. 사용 가능한 서버 메모리(스토리지로 교체하고 있습니까?)

지금까지 우리는 웹 문서 로딩을 시작하지도 않았습니다. 매월 100만 개의 경로를 보유할 수 있으며 각 경로는 필요에 따라 동적으로 구성됩니다. 천만 개가 있을 수도 있고, 1억 개가 있을 수도 있습니다. 귀하의 웹 사이트를 방문하는 모든 방문자는 위 목록에 있는 성능 취약점의 전부는 아니더라도 대부분을 포함하는 고유하게 구성된 데이터 경로를 나타냅니다. 이는 단지 기계 간 성능 포인트일 뿐입니다.

가져오는 기계에 많은 문제가 있을 수 있지만 편의를 위해 가능성 목록을 무시하겠습니다.

웹 서버 수준에서는 다음 사항이 응답 시간에 영향을 미칠 수 있습니다.

 

  1. 활성 연결 수
  2. 활성 프로세스 수
  3. 데이터베이스 작업 수(“숫자”는 올바른 단어가 아님)
  4. 서버 구성 품질
  5. 데이터베이스 구성 품질(“쓰레기” 및 “클러터” 포함)
  6. 정책 및 기타 메타 구성 항목 수(페이지당)
  7. 페이지당 리소스 수
  8. 각 리소스의 크기
  9. 각 해외 자원의 위치(다른 서버에 있음)
  10. 보안 프로토콜

페이지 개발자가 일반적으로 제어하는 ​​것

일반적인 웹 사이트는 메타 정보(보안 정책, X-whatever 헤더 및 페이지 외부의 기타 “HEAD” 정크 등), 소스 문서 자체 및 일반적으로 CSS 파일, Javascript 파일, 이미지 등과 같은 여러 지원 문서를 게시합니다.

페이지 개발자는 무엇을 사용하고 어떻게 제공할지 결정할 책임이 있습니다. 대부분의 사람들이 페이지 속도를 향상시키는 데 노력을 집중하는 곳입니다. 속도 문제의 대부분이 웹사이트 디자인에서 발생한다고 생각하는 것은 당연합니다. 때로는 이 가정이 정확할 때도 있습니다. 속도 문제를 직관적으로 진단할 수 있는 감각을 키워야 합니다. 이를 수행할 수 있는 체크리스트는 없습니다.

브라우저는 문서에 필요한 모든 외부 리소스에 대해 요청을 발행해야 합니다. 예를 들어 다음과 같은 요청이 표시될 수 있습니다.

  1. HTML 문서
  2. CSS 파일 1
  3. CSS 파일 2
  4. 분석 스크립트
  5. 글꼴 스크립트 1
  6. 글꼴 스크립트 2
  7. 메인(헤더) 이미지
  8. 광고 위젯(소스 코드 + 이미지)

그리고 우리 모두는 페이지당 이러한 요청이 수십 또는 수백 개 있을 수 있다는 것을 알고 있습니다. 브라우저는 각 리소스를 별도로 요청해야 하며 이는 각 요청과 다시 전송되는 모든 응답이 위에서 설명한 모든 felgercarb를 통과해야 함을 의미합니다.

페이지에 가져올 수 있는 요소를 하나 이상 제공하는 모든 호스트에는 사용자 브라우저가 추가 DNS 조회를 수행해야 합니다. DNS 정보는 캐시될 수 있으므로 방문자가 Google Fonts, Google Analytics, 다양한 소셜 미디어 버튼, 원격 비디오 호스팅 플랫폼 등과 같이 귀하가 참조하는 동일한 외부 호스트에서 리소스(방문하는 다른 사이트에 대한)를 검색하는 경우 이점을 얻을 수 있습니다. .

이제 벤치마크 서버가 도움이 되는 이유가 더 명확해졌습니다.

2017년에 일반적인 웹 문서에 얼마나 많은 리소스가 포함되어 있는지를 고려하면 디자인의 복잡성 때문에 느린 사이트가 모두 느리다고 가정할 이유가 없습니다. 이러한 사이트는 페이지당 20-50개의 1-2MB 이미지를 제공할 수 있지만 문제는 어딘가에 잘못된 라우터가 있을 수 있습니다. 사용자가 결함이 있는 DNS 확인자에 연결하고 있을 수도 있습니다.

벤치마크 서버는 다음 사항을 알려줍니다. 연결 느리거나 페이지가 너무 복잡해요.

시스템이 느린 클라이언트와 작업할 때 나는 대개 거의 빈 문서를 생성해 달라고 요청합니다. 그 베어본 문서는 나에게 가난한 사람의 벤치마크 서버 역할을 합니다. 벤치마크 서버가 무엇인지, 왜 벤치마크 서버로 작업하고 싶은지 설명하는 것보다 이를 요청하는 것이 더 쉽습니다. 외부 요청이 없는 문서를 가져오는 데 시간이 오래 걸린다면 웹사이트 디자인에 문제가 있는 것은 아닙니다.

HTTP 요청과 HTTPS 요청을 비교하여 상당한 지연이 확인된다면 이는 많은 핸드쉐이킹이 진행되고 있음을 나타낼 수 있습니다. 서버가 제대로 구성되지 않았을 수 있습니다. 없을 수도 있겠네요 충분한 이전 TLS 암호화 프로토콜이 설치되었습니다. 그것은 단지 예시적인 예일뿐입니다. 다른 곳에서 문제를 발견할 가능성이 더 높습니다.

결론

적절한 벤치마크 문서나 서버 없이 사이트 속도 문제를 진단하는 경우 거의 어둠 속에서 촬영하는 것과 같습니다. 전 세계 20개 위치의 모든 것을 벤치마킹할 시간과 자원이 없을 수도 있지만 값비싼 솔루션이 필요하다는 결론을 내리기 전에 “깨끗한” 웹 문서를 제공하는 서버의 능력을 테스트할 수 있어야 합니다.

이 기사는 원래 SEO 이론 프리미엄 뉴스레터 6권 25호(2017년 7월 7일)에 게재되었습니다. 지금 $25/월 또는 $200/년으로 구독하고 매주 새로운 기사를 받아보세요.



Leave A Reply

Your email address will not be published.