Google Analytics는 성능에 어느 정도 영향을 미칩니 까?
다음을 찾고 있습니다.
사이트에서 Google Analytics (GA)를 테스트하는 (가능한) 방법 :
이것이 클라이언트 웹 서버와 GA 서버 간의 통신을 줄이는 방법에 관심이 있습니다.
이 테스트를 수행 한 사람이 있습니까? 그렇다면 결과를 제공 할 수 있습니까? 그렇지 않은 경우 GA 사용에 대한 성능 저하 (또는 부족)를 테스트하는 더 좋은 방법이 있습니까?
답변:
2018 업데이트 : Analytics를 탑재하는 위치와 방법이 계속해서 바뀌 었습니다. 현재 gtag.js 코드는 몇 가지 작업을 수행합니다.
window.datalayergtag()던지는 것을 그 배열에 밀어 넣는 작은 함수를 정의하십시오 .기본 gtag 스크립트가로드되면이 배열을 Google과 동기화하고 변경 사항을 모니터링합니다. 좋은 시스템이며 이전 시스템 (예 : 직전에 코드 채우기)과 달리 </body>DOM이 렌더링되기 전에 이벤트를 호출 할 수 있으며 먼저 정의하는 한 스크립트 순서는 중요하지 않습니다 gtag().
여기에 성능 오버 헤드가 없다는 말은 아닙니다. 우리는 여전히 스크립트를로드 할 때 대역폭을 사용하고 있으며 (15 분 동안 로컬로 캐시 됨) 사용자에게 던지는 작은 스크립트 더미가 아니므로 처리하는 데 CPU 시간이 약간 걸립니다.
그러나 현대적인 프런트 엔드 프레임 워크와 비교하면 무시할 수있는 수준입니다.
가능한 절대적이고 가장 잘린 웹 사이트를 찾고 있다면 완전히 피하십시오. 사용자의 개인 정보를 보호하려는 경우 타사 스크립트를 사용하지 마십시오.하지만 평균적인 최신 웹 사이트에 대해 이야기하고 있다면 gtag.js보다 매달린 과일 이 훨씬 적습니다. 타격 성능 문제.
Steve Souders (클라이언트 측 성능 전문가)의 다음과 같은 멋진 슬라이드 가 있습니다.
나는 멋진 자동 테스트 또는 프로그래밍 방식 번호 처리를 수행하지 않았지만 Firebug 플러그인과 한 쌍의 JS 변수와 함께 좋은 오래된 Firefox를 사용하여 모든 GA 코드가 실행되기 전후의 시간 차이를 알려줍니다.
두 가지가 다운로드됩니다.
ga.js는 코드가 포함 된 자바 스크립트 파일입니다. 이것은 9kb이므로 초기 다운로드는 무시할 수 있고 파일 이름은 동적이 아니므로 첫 번째 요청 후에 캐시됩니다.
동적 URL (쿼리 문자열 인수를 통해)이있는 35 바이트 gif 파일이므로 매번 요청됩니다. 35 바이트도 무시할 수있는 다운로드입니다 (방화범이 다운로드하는 데 70ms가 걸린다고합니다).
실행 시간에 관해서는 깨끗한 브라우저 캐시를 사용한 첫 번째 요청이 매번 평균 약 330ms 였고 후속 요청은 35 ~ 130ms였습니다.
내 경험상 Google-Analytics를 추가해도로드 시간이 변경되지 않았습니다.
FireBug에 따르면 1 초 미만 (평균 648MS)에로드되므로 다른 테스트 중 일부는 해당 시간의 60 %-80 %가 서버에서 데이터를 전송하는 것이 었습니다. 물론 사용자마다 다를 수 있습니다.
위의 이유로 분석 코드를 로컬로 캐싱하면로드 시간이 많이 변경 될 것이라고는 특별히 생각하지 않습니다.
저는 40 개가 넘는 웹 사이트에서 Google-Analytics를 사용합니다. 그 이유가 작은 속도 저하의 원인이되지 않고 일반적인 크기로 인해 이해할 수있는 이미지를 얻는 데 가장 많은 시간이 소요됩니다.
문제없이 서버에서 ga.js를 호스팅 할 수 있지만 사용자 가 방문했을 수있는 다른 사이트 에서 ga.js를 캐시 할 수 있다는 생각이 있습니다. 따라서 ga.js를 다운로드하면 인기가 높기 때문에 많은 경우에 오버 헤드가 거의 발생하지 않습니다 (즉, 이미 캐시되어 있음).
또한 네트워크 토폴로지로 인해 DNS 조회 비용이 다른 장소에서 동일하지 않습니다. 캐싱 동작은 사용자가 ga.js를 포함하는 다른 사이트를 사용하는지 여부에 따라 달라집니다.
자바 스크립트가로드되면 ga.js는 Google 서버와 통신하지만 이는 비동기 프로세스입니다.
도움이 되었기를 바랍니다.
서버 측에는 최소한의 사이트 오버 헤드가 없습니다.
Google Analytics 용 HTML은 웹 페이지 하단에 배치하는 세 줄의 자바 스크립트입니다. 실제로는 아무것도 아니며 저작권 고지보다 더 많은 서버 리소스를 소비하지 않습니다.
클라이언트 측에서는 페이지 표시를 완료하는 데 약간 (최대 2 초) 시간이 걸릴 수 있습니다. 그러나-내 경험상로드되지 않은 페이지의 유일한 부분은 Google 항목이므로 사용자는 페이지를 완벽하게 볼 수 있습니다. 페이지 상단의 두근 거림이 조금 더 욱신 거립니다.
(참고 : Google 애널리틱스 코드 블록을 게재 된 페이지의 맨 아래에 배치해야합니다. 코드 블록이 HTML 상단에 배치되면 어떻게되는지 모르겠습니다.)
사용 을 포함 하는 방법에 대한 Google 의 기존 지침 입니다 . 따라서 브라우저가 일부 코드가 실제로 실행될 때까지 외부 JavaScript 라이브러리를 비동기 적으로로드 하더라도 페이지로드는 여전히 차단됩니다. 이후의 비동기 명령 은 직접 사용하지 않지만 페이지로드를 차단할 수도 있습니다.ga.jsdocument.write()document.write()document.write()insertBefore
그러나 Google은 캐시 max-age를 86,400 초로 설정합니다 (1 일이며 공개로 설정 되어 프록시에도 적용 가능). 따라서 많은 사이트가 동일한 Google 스크립트를로드하기 때문에 JavaScript는 종종 캐시에서 가져옵니다. 그래도 캐시 된 경우에도 ga.js새로 고침 버튼을 클릭하기 만하면 브라우저에서 변경 사항에 대해 Google에 묻는 경우가 많습니다 . 그런 다음 ga.js아직 캐시되지 않은 경우와 마찬가지로 브라우저는 계속하기 전에 응답을 기다려야합니다.
GET /ga.js HTTP / 1.1 호스트 : www.google-analytics.com ... 수정 된 경우 : 2009 년 6 월 22 일 월요일 20:00:33 GMT 캐시 제어 : max-age = 0 HTTP / 1.x 304 수정되지 않음 최종 수정 : 2009 년 6 월 22 일 월요일 20:00:33 GMT 날짜 : 2009 년 7 월 26 일 일요일 12:08:27 GMT 캐시 제어 : max-age = 604800, 공개 서버 : Golfe
참고 것을 많은 사용자가 뉴스 사이트, 포럼 및 블로그 다시로드를 클릭 그들은 이미 구글로부터의 응답이 수신 될 때까지 많은 브라우저 블록을 만들고, 브라우저 창에 열려 . SO 홈 페이지를 얼마나 자주 다시로드합니까? Google Analytics 응답이 느리면 이러한 사용자는 즉시 알 수 있습니다. ( 스크립트 를 비동기식으로로드하기 위해 인터넷에 게시 된 많은 솔루션 이 있으며 ga.js, 특히 이러한 종류의 사이트에 유용하지만 Google의 업데이트 된 지침보다 더 이상 좋지 않을 수 있습니다.)
자바 스크립트가로드되고 실행되면 웹 버그 (추적 이미지)의 실제로드는 비동기 적이어야합니다. 따라서 페이지에서를 사용 하지 않는 한 추적 이미지로드가 다른 것을 차단해서는 안됩니다body.onload() . 이 경우 웹 버그가 즉시로드되지 않으면 다시로드를 클릭하면 If-Modified-Since위에서 설명한대로 브라우저가 스크립트를 다시 요청하기 때문에 실제로 상황이 악화됩니다 . 다시로드 하기 전에 브라우저는 웹 버그만 기다리고 있었지만 다시로드 를 클릭 한 후에 는 ga.js스크립트에 대한 응답도 필요합니다 .
따라서 Google Analytics를 사용하는 사이트는body.onload() . 대신 jQuery의 $ (document) .ready () 또는 MooTools의 domready event 와 같은 것을 사용해야합니다 .
Google Analytics가 데이터를 수집하는 방법을 설명 하는 Google의 기능 개요를 참조하십시오 . , 추적 코드 작동 방식 포함 . (이는 또한 Google이 자사 쿠키의 콘텐츠를 수집한다는 사실을 공식화합니다. 즉, 방문하는 사이트의 쿠키입니다.)
업데이트 : 2009 년 12 월 Google은 비동기 버전을 출시 했습니다 . 위의 내용은 모든 사람에게 확실하게 업그레이드하라고 알려야하지만 업그레이드로 모든 문제가 해결되지는 않습니다 .
그것은 정말로 그날에 달려 있습니다. 나는 이것을 블로그에 추가하고있다. 저는 캘리포니아에 있으며 주요 데이터 센터와 매우 가깝고 지연 시간이 짧은 비즈니스 DSL, 최신 Linux 커널 및 안정적인 파이어 폭스를 실행하는 RAM이 많은 오버 클럭 된 i5에 있습니다.
다음은 샘플 페이지로드입니다.
google-analytics만으로도 네트워크 다운로드 시간 5 초만 추가 하면 15Kb를 얻을 수 있습니다!
blogger.com이 300 밀리 초 안에 34Kb를 제공하는 것을 볼 수 있습니다 . 32 배 더 빠릅니다!
또한 Red Line (onLoad 이벤트를 나타냅니다. 즉, 페이지에서 더 이상 스크립트가 실행되지 않고 브라우저가로드 표시기 / 회전 등을 마지막으로 중지 할 수 있음을 의미합니다) ... 얼마나 오른쪽으로 이동하는지 살펴보십시오. 이다. 아마 거기에서 일어난 3 초의 쓰레기 자바 스크립트 처리 일 것입니다. 해당 라인이 리소스 다운로드 바의 끝에서 매우 멀리 떨어져있는 경우는 매우 드뭅니다. 나는 이것을 디버깅하고 1/3 분석 오류, 2/3 블로거 오류입니다. ... Google 물건이 빠르다고 생각할 것입니다.
편집하다:
더 많은 데이터. 모든 것이 캐시 된 요청이 있습니다. 위의 것은 첫 방문이었습니다.
나는 두 가지 이유로 위에서 googleplus 쓰레기를 제거했습니다. 저는 그들이 느린 onLoad 이벤트에서 어떤 역할을하고 있는지 (그들은 그렇지 않습니다) 대부분 쓸모가 없기 때문에 확인하려고했습니다.
따라서이를 통해 네트워크 시간이 걱정 되는 것이 가장 적음을 알 수 있습니다. 최신 소프트웨어를 사용하는 빠른 컴퓨터에서도 Google 애널리틱스 + 블로거가 처리하는 데 걸리는 시간은 7 초가 지나도 페이지로드를 덤프합니다. 블로거가 없으면 바로이 사이트를 확인하십시오. 리소스가로드되고 빨간색 선이 시작된 후 0.5 초의 지연이 발생합니다.
추가 자바 스크립트를 페이지에로드하면 클라이언트의 관점에서 다운로드 시간이 늘어납니다. GA가로드되지 않은 경우에도 페이지가 렌더링되도록 페이지 하단에로드하여이 문제를 개선 할 수 있습니다. 페이지에 대한 클라이언트 캐시의 이점을 잃을 수 있으므로 캐싱을 피할 것입니다. 클라이언트가 다른 페이지에서 캐시 한 경우 페이지의 요청은 클라이언트 자체에서 채워집니다. 사이트에서로드하도록 변경하면 클라이언트에 이미 코드가있는 경우에도 다운로드가 필요합니다. Google에서 파일을로드하는 것을 방지하기 위해 소프트웨어 프로세스에 작업을 추가하는 것은 불필요한 최적화 일 수있는 이유가 아닙니다. 항상 로컬에서 더 빠르게 서비스를 제공하므로 테스트하기가 어려울 수 있지만 실제로 중요한 것은 고객에게 얼마나 빠르게 작동하는지입니다.
FireBug 및 YSlow를 사용하여 자신을 확인하십시오. 그러나 당신이 발견하게 될 것은 GA의 크기가 약 9KB이고 (실제로는 그것이하는 일에 상당히 상당 함) 때로는 매우 빠르게로드되지 않는다는 것입니다 (어떤 이유로 인해 때때로 "질식"하는 서버)
우리는 제거 로 인해 우리에 대한 성능 문제에 아약스 샘플 , 그러나 다시 우리가 되 초고속 및 반응은 우선 순위 1, 2, 3이었다
눈에 띄는 것이 없습니다.
Google에 대한 호출 (DNS 조회, 아직 캐시되지 않은 경우 자바 스크립트로드 및 실제 추적 프로그램 자체 호출 포함)은 실제로 페이지를로드하기 위해 별도의 스레드에서 클라이언트의 브라우저에 의해 수행되어야합니다. 확실히 DNS 조회는 기본 시스템에 의해 수행되며 내가 아는 한 브라우저 내에서 조회로 간주되지 않습니다 (브라우저는 사이트 당 사용할 요청 스레드 수에 제한이 있습니다).
그 외에도 브라우저는 다른 모든 임베디드 리소스와 함께 Google 스크립트를 병렬로로드하므로 최악의 경우 모든 것을 다운로드하는 데 걸리는 시간이 극히 약간 늘어날 수 있습니다 (순서대로 밀리 초, 눈에 띄지 않습니다. Google 스크립트가 브라우저에 의해 마지막으로로드되거나 페이지에 외부 리소스가 많지 않거나 페이지의 외부 리소스가 브라우저에 의해 캐시되거나 Google 스크립트가 브라우저에 의해 캐시 된 경우 ( 대략적으로 말하면 페이지에 아주 작은 그림을 붙이는 것과 같은 효과이며 전체적으로는 절대적으로 사소한 것입니다.
유일한 시간에 대해 당신이 (부하에 외부 자원을 기다립니다) onLoad 이벤트, 화재 몇 가지 행동이있는 경우 콘크리트의 차이가 만들 수 와 Google 서버가 / 슬로우 다운을. 후자는 자주 발생하지는 않지만이 경우 스크립트가 다운로드 될 때까지 onLoad가 실행되지 않습니다. 어쨌든 다양한 "DOM로드시"이벤트를 사용하여이 문제를 해결할 수 있습니다.이 이벤트는 일반적으로 자체 스크립트 / 이미지가 이러한 방식으로로드 될 때까지 기다릴 필요가 없기 때문에 더 반응이 좋습니다.
페이지로드 시간에 미치는 영향에 대해 정말 걱정이된다면 Firebug 의 "Net speed"섹션을 살펴보십시오.이 섹션은 이를 정량화하고 예쁜 그래프를 그릴 것입니다. 다른 사람들이 당신에게 그림 및 요청 벤치 마크를 주면 내가 아니라도 어쨌든 자신을 위해이 작업을 수행하는 것이 좋습니다 것, 그것은 것입니다 당신의 자신의 위치에 대한 완전히 다른합니다.
글쎄, 나는 인터넷에서 광범위하게 검색하고 조사하고 탐구했습니다. 그러나 나는 전제에 찬성하거나 반대한다고 주장하는 통계 데이터를 찾지 못했습니다.
그러나 http://www.ga-experts.com 에서 발췌 한이 내용은 GA가 웹 사이트 속도를 늦추는 신화라고 주장합니다.
어, 괜찮아요. 약간은 밀리 세컨드입니다. GA는 페이지 태그 지정으로 작동하며 웹 페이지에 콘텐츠를 더 추가 할 때마다로드 시간이 늘어납니다. 그러나 모범 사례 (태그 앞에 태그 추가)를 따르면
</body>페이지가 먼저로드됩니다. 또한 페이지 태그 기반 웹 분석 패키지 (대부분)는 동일한 방식으로 작동합니다.
위의 답변과 다른 모든 출처에서 내가 느끼는 것은 스크립트가 페이지 하단에 포함되어 있기 때문에 사용자가 감지하지 못하는 속도 저하가 발생한다는 것입니다. 그러나 전체 페이지로드에 대해 이야기하면 페이지로드 시간이 느려진다 고 말할 수 있습니다.
있으면 더 많은 정보를 게시하고 있으면 데이터를 게시하십시오.
cPanel에서 빈번한 I / o 및 CPU 과부하를 발견했습니다.
사이트에 연결할 수 없음 오류
그리고 WP Analytics 플러그인을 비활성화 한 후 중지되었습니다. 그래서 나는 그것이 약간의 영향을 미친다고 생각합니다.