HTML이로드되기 전에 '대기'시간의 원인은 무엇입니까?

웹 사이트가 매우 느리게로드되는 것 같습니다. 속도 테스트를 실행하면 HTML 이로 드되기 전에 6 secound gap이있는 것으로 보입니다. 이 시점 이후 이미지와 JS 스크립트는 매우 빠르게로드됩니다.

아래 그림에서 노란색 '대기 시간'막대를 볼 수 있습니다.

이것은 페이지의 HTML 내용이 무엇이든간에 일관된 것으로 보입니다.

이 사이트는 CMS (ModX Revo)를 사용하므로 HTML은 실제로 SQL 데이터베이스에 저장되어 PHP에서 발생하지만이 문제는 이전에 본 적이 없습니다.

누구 든지이 문제의 원인과 속도를 어떻게 알 수 있습니까?

대기에 대한 기술 용어는 첫 번째 바이트까지의 시간으로 지칭되며 웹 서버 또는 기타 네트워크 리소스의 응답 성을 결정합니다.

첫 바이트에 높은 시간이 표시되는 몇 가지 일반적인 이유는 다음과 같습니다.

• 과부하 된 네트워크 (일반적으로 공유 호스팅)
• 잘못된 구성 서버
• 귀하와 서버로부터의 거리 (지리적 위치는 작은 역할을합니다)
• 서버 오류 (홉)

일반적으로이 문제는 종종 웹 사이트와 웹 사이트를 방문하는 사람들이 많기 때문에 공유 호스팅에서 볼 수 있는데, 이는 물론 네트워크 바이트 시간을 증가시킵니다. 또 다른 가능한 원인은 홉과 같은 네트워크 어딘가에 있거나 서버가 대상 사용자의 위치에 있지 않기 때문에 발생합니다. 예를 들어 'GOOD'UK 서버는 미국 서버보다 바이트 시간이 짧습니다. 영국은 데이터를 송수신해야하는 거리 때문에 (일반적으로 약 100-200ms 증가)

아마 새로운 호스트를 얻을 시간

과거에는 첫 바이트까지의 시간이 지연되어 서버에서 서버로 이동해야했습니다. 새로운 웹 호스트를 선택하거나 현재 패키지를 업그레이드해야 할 수도 있습니다.

신뢰할 수있는 테스트

홈 광대역에서 웹 사이트의 속도를 테스트하는 것은 광대역이 웹 사이트에 응답하지 않는 문제 일 수 있으므로 매우 편향되어 있습니다. 여러 서버에서 여러 연결을 사용하여 웹 사이트를 테스트해야합니다. 웹 페이지 테스트 와 여러 지역에서 여러 지역을 대상으로 여러 테스트를 한 번에 여러 번 실행하는 것이 좋습니다 . 이렇게하면 무슨 일이 일어나고 있는지에 대한 더 나은 개요를 얻을 수 있습니다. 첫 번째 바이트라면 웹 호스트에 먼저 문의하는 것이 좋습니다.

서버 핑 및 추적 경로

서버에서 ping을 실행하려고하면 결과가 표시되거나 표시되지 않을 수 있습니다. ping은 UDP 또는 TCP 대신 ICMP를 사용하므로 httpd가 실행될 포트 80에서 서버를 쿼리하는 것과는 다릅니다. 추적 경로를 사용하여 경로에서 첫 번째 바이트가 증가 할 수있는 서버를 식별 할 수 있습니다. 포트 80에서 httpd 서버를 쿼리하지 않으며 Windows를 사용하는 추적 경로 인 경우 ICMP 및 Mac / Linux를 사용합니다. 머신은 UDP를 사용합니다. 빠르고 쉽게 할 수 있기 때문에 테스트 할 가치가 있지만 결과가 제대로 돌아 온다고해서 어딘가에 문제가 없다는 것을 의미하지는 않습니다.

1) 현재 코드와 함께 비동기 적으로로드되지 않는 Adobe TypeKit이 있습니다. 고급 비동기 코드 ( http://help.typekit.com/customer/portal/articles/649336-embed-code)로 바꾸십시오 .

이 표준 임베드 코드는 태그가 페이지의 추가 렌더링을 차단하여 FOUT [스타일이없는 텍스트의 플래시]를 방지하는 데 도움이됩니다. Typekit 스크립트가로드되는 동안 페이지 렌더링이 차단되므로 텍스트가 대체 글꼴로 렌더링되지 않습니다.

2) 새로운 TypeKit으로 테스트하십시오. 지금 로딩 시간은 어떻습니까? 보다 나은? 3 단계로 이동하십시오.

3) Google Analytics를 최신 비동기 구문을 제공하는 업데이트 된 JavaScript ( https://developers.google.com/analytics/devguides/collection/gajs/ )로 바꿉니다.

4) 시험. 여전히 페이지가 더 잘로드됩니까?

5) 마지막으로 pattern.jpg와 같은 이미지 최적화를 고려하십시오. PNG로 변환하여 파일 크기를 199kB에서 56kB로 줄일 수있었습니다. 이렇게하면 파일을받는 시간이 줄어 듭니다. https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

이게 도움이 되길 바란다.

PHP와 비 PHP 요소

비 PHP 자산로드 시간을 PHP 기반로드 시간과 비교하면 PHP가 관련되지 않은 경우 서버가 빠르게 응답하는 것을 볼 수 있습니다.

이것은 일반적으로 PHP 스크립트 내부의 문제를 나타냅니다.

PHP 레이어 나 데이터베이스에 문제가있을 수 있습니다. XDebug 또는 NewRelic과 같은 고급 디버깅 도구를 사용하면 병목 현상을 신속하게 파악할 수 있습니다.

첫 바이트 시간 문제는 하드웨어 제약, 구성 불량 또는 비효율적 인 코드로 인해 발생할 수 있습니다. 공유 호스팅에서는 하드웨어 제약과 구성 불량이 가장 많습니다.

어쨌든 문제 해결은 일반적으로 다음 중 하나 또는 모두를 의미합니다.

• 더 많은 하드웨어
• 더 나은 프로그래밍
• 캐싱 추가

이미 전용 리소스를 사용하고 있다면 더 빠른 하드웨어가 분명하지만 비용이 많이 드는 솔루션입니다.

개발자 리소스를 유지 관리하지 않거나 부족한 코드 내부에서 문제가 발생하면 더 나은 프로그래밍이 불가능할 수 있습니다.

캐싱은 성능이 저하 된 기본 리소스에 도달해야하는 요청 수를 줄임으로써 도움이됩니다.

테스팅

테스트 도구를 사용할 때는 여러 번 실행해야합니다. 네트워크 및 임시 서버 급등으로 인해 잘못된 경로로 쉽게 넘어갈 수 있으므로 평균값을 평균화하려고합니다.

호스팅

공유 호스팅 계정을 사용하는 경우 클라우드 또는 VPS 유형 서비스로 전환하여 성능 문제에 대한 통찰력을 향상 시키십시오. 캐싱 기술 (CDN 또는 Cloudflare 유형 서비스)을 사용하지 않으면 서버를 충분히 제어 할 수 없기 때문에 대량 공유 호스팅 시스템의 성능 문제를 해결하는 것이 매우 어려울 수 있습니다.

타사 쿠키 만 방문하도록 설정하십시오.