페이지 로딩 속도를 확인하는 방법. 포괄적인 WP 최적화. Google이 속도를 그토록 중요하게 여기는 이유
안녕하세요, 독자 여러분! 블로그 홍보에 대한 실제 사례를 계속해서 오늘 가장 중요한 것 중 하나에 대해 이야기합시다. 중요한 요소웹 리소스의 성능에 대한 순위입니다. 웹사이트 페이지 로딩 속도-페이지 로딩 속도가 무엇인지 배울 기사의 주제, 어떻게그녀의 확인하다그리고 물론 그 사람 이름이 뭐죠? 증가하다. 평소와 마찬가지로 웹 리소스 성능의 중요성에 대한 가장 기본적인 사항을 설명하고 이 매개변수를 평가하기 위한 가장 기본적인 서비스를 보여 드리겠습니다. 내 SEO 치트 시트 독자를 위해 블로그 속도 확인에 대한 문서를 준비했습니다. 구글애널리틱스.
웹 리소스 페이지 로딩 속도
웹사이트 성능의 중요성
2010년 4월 9일 검색 엔진 구글 시스템공식 성명을 통해 모든 웹마스터에게 사이트 속도의 중요성을 분명히 밝혔습니다. 따라서 오늘날 그들은 모든 페이지의 로딩 속도를 평가합니다. 그리고 이 지표가 높을수록 웹마스터나 블로거의 사이트가 검색 엔진에서 더 높은 순위를 차지할수록 검색 결과에서도 더 높은 순위를 차지할 수 있습니다. 이것이 정말 그렇게 중요하다고 생각하시나요?
페이지 로딩 속도가 느림 - 두통모든 검색 엔진 사용자. 그리고 그러한 지연의 원인이 부풀어 오른 웹사이트 페이지나 문제가 있는 블로그 플러그인 때문일 수도 있다는 점은 중요하지 않습니다. 검색 방문자는 오랫동안 웹 리소스의 게시물과 문서를 여는 데 시간을 낭비하고 싶지 않습니다. 그리고 5-7년 전에는 그가 그것을 용인할 수 있었지만 오늘날 이것은 의문의 여지가 없습니다. 검색 엔진 사용자에게 답변을 제공할 수 있는 사이트의 수가 증가했습니다.
2009년 9월 Akamai Technologies가 의뢰한 Forrester Consulting의 연구에 따르면 검색 엔진 사용자가 상업용 웹사이트 페이지를 로드하는 데 걸리는 최대 시간은 2초입니다.
2006년에 유사한 연구에서 완전히 다른 수치인 4초가 나타났습니다. 웹마스터와 블로거 여러분, 그들이 말했듯이 스스로 결론을 내리십시오. 매년 검색 엔진 사용자는 느린 사이트에 대한 관대함이 줄어들고 있습니다.
따라서 검색 엔진에서 성공적인 블로그 홍보를 위해서는 성능이 매우 중요합니다. 블로거가 로딩 속도의 중요성을 이해하는 데 도움이 되는 가장 중요한 매개변수와 지표를 나열하겠습니다.
- 독자의 부정적/긍정적 태도. 검색 사용자가 블로그 게시물이 열릴 때까지 기다리는 시간이 길어질수록 블로그 게시물을 더 자세히 탐색하는 데 관심이 줄어듭니다. 그가 정규 독자가 되기 어려울수록 그에게 귀하의 서비스, 정보 제품 등을 제공하는 것이 더 문제가 됩니다.
- 검색결과 하위 순위. 동일한 다른 순위 매개변수가 주어지면 느린 블로그는 빠른 웹 리소스에 비해 초승달 모양의 낮은 위치를 차지합니다.
- 점점 악화되고 있다 행동 요인 . 응답률이 낮을수록 사용자 행동에 대한 주요 지표는 이상적이지 않습니다. 즉, 블로그 페이지 보기 깊이가 낮을수록 문서 상호 작용 시간이 짧을수록 파일 다운로드 속도가 낮아집니다.
사이트 로딩 속도는 어떻게 결정되나요?
각 검색 엔진에는 인터넷에서 사이트를 검색할 때 특정 기능을 수행하는 특수 로봇(또는 검색 스파이더라고도 함)이 있습니다. 예를 들어 Google 검색 엔진에서 이러한 스파이더는 Google-bot입니다. 그는 모든 블로그 페이지를 돌아다니며 모든 정보를 수집합니다. 내부 링크. 그는 이 정보를 데이터베이스로 보내서 처리하고 분석합니다.
로봇 자체는 스캔된 정보를 평가하지 않습니다. 그러나 이는 블로그 속도에 대해 검색 엔진에 신호를 줄 수 있습니다. 인터넷에 게시된 게시물과 페이지 수가 많기 때문에 엄청난 양, 수십억 개의 문서로 구성된 이 문서는 엄격하게 할당된 보기 시간 동안 각 사이트에 표시됩니다. 이 시간 동안 전체 페이지를 검사하는 경우 사이트 성능은 별개입니다. 결국, 로봇은 천천히 열리는 페이지를 무기한 기다릴 수 없습니다. 아직 살펴봐야 할 다른 문서가 너무 많습니다. 따라서 검색 엔진에는 Google-bot이 웹 리소스 페이지의 정보를 얼마나 오랫동안, 얼마나 완전히 스캔하는지에 대한 정보가 있습니다.
사이트 페이지 로딩 속도 확인
사이트의 로딩 속도를 확인하려면 많은 수의다양한 서비스와 프로그램. 그러나 이들 모두가 블로그 성능에 대한 완전하고 포괄적인 정보를 제공할 수 있는 것은 아닙니다. 그럼 이제 가장 많은 것을 보여드리겠습니다. 대중적인 방법내가 직접 사용하는 속도 추정치. 그리고 정확히 무엇을 선택할지 결정하는 것은 당신에게 달려 있습니다.
구글 페이지 속도
블로그 로딩 속도를 확인하는 가장 좋은 도구 중 하나는 Google의 PageSpeed입니다. FireFox 및 Chrome용 특수 플러그인을 사용하거나 별도의 페이지에서 분석하여 사이트를 확인할 수 있습니다. 이제 두 번째 옵션을 소개하겠습니다. 먼저, 위의 링크를 따라 이 서비스 페이지로 이동하세요. 여기에서 도메인 이름 입력 양식이 기다리고 있습니다.
블로그 메인 페이지의 URL을 입력하고 '분석' 버튼을 클릭하세요. 테스트 후 구글 페이지우리 사이트의 로딩 속도를 확인한 속도 결과:
결과를 보면 알 수 있듯이 제 블로그 메인 페이지는 100점 만점에 75점을 받았습니다. 예, 100 개가 전부는 아닙니다. 생각해 볼 것이 있습니다. 그리고 생각하기 쉽도록 시스템에서 친절하게 숫자를 알려줬어요 유용한 추천, 그러면 내 블로그의 로딩 속도가 빨라집니다.
각 권장 사항으로 이동하면 사이트 성능을 높이기 위해 무엇을 어떻게 해야 하는지에 대한 구체적인 조언을 볼 수 있습니다. 빨간색 문자 "H"는 다운로드 속도를 향상시키는 가장 중요한 권장 사항을 나타내고, 노란색 문자는 중간을 나타내고, 회색 문자는 작거나 작음을 나타냅니다. 그림은 서비스가 브라우저 캐싱 및 압축 활성화를 통해 내 블로그의 응답에서 가장 중요한 개선 사항을 확인했음을 보여줍니다. 이에 대해서는 다음 포스팅에서 다루겠지만 지금은 다음으로 넘어가겠습니다. 다음 서비스사이트 속도 평가.
GTmetrix
이 서비스는 첫 번째 서비스와 동일한 원리로 웹 리소스의 응답을 확인합니다. 먼저 분석을 위해 블로그를 특별한 형식으로 입력합니다.
그런 다음 페이지 로딩 속도를 확인한 결과를 얻습니다.
모든 중요한 분석 매개변수는 A(우수)부터 F(나쁨)까지 특별한 등급으로 등급이 매겨집니다. 따라서 여기서는 확인 중인 사이트의 모든 단점을 명확하게 볼 수 있으며 앞으로는 로딩 속도를 높이기 위한 조치를 취할 수 있습니다. GTmetrix는 분석을 위해 Pagespeed에서 작동하는 것과 동일한 도구를 사용합니다(이는 내 블로그의 전체 응답 점수가 75점으로 동일하다는 것을 입증합니다).
GTmetrix도 제공합니다. 상세 목록하나 또는 다른 분석된 매개변수를 개선하는 방법을 알려주는 유용한 권장 사항입니다. 이 서비스 사용의 또 다른 좋은 점은 분석 데이터를 다음으로 내보낼 수 있다는 것입니다. 별도의 파일(PDF). 이를 통해 모든 블로거, 웹마스터 및 분석가는 언제든지 분석 결과를 볼 수 있을 뿐만 아니라 향후 로딩 속도를 가속화하기 위해 수행된 작업의 성공 여부를 비교할 수도 있습니다.
Pingdom 웹사이트 속도 테스트
또 다른 인기있는 서비스사이트 로딩 속도를 평가하여 - Pingdom 웹사이트 속도 테스트. 명확한 인터페이스를 가지고 있으며 편리한 반응 분석 도구입니다. 시작하려면 특수 창에 웹사이트 주소를 입력해야 합니다.
몇 초 동안 데이터를 처리한 후(작동 원리도 PageSpeed 평가 도구를 기반으로 함) 정보 플레이트가 포함된 기성 웹사이트 로딩 속도 보고서를 받습니다. 일반 매개변수측정:
여기에서는 유익한 아이콘과 메시지를 통해 명확하게 볼 수 있습니다. 다음 매개변수사이트 속도 추정:
- 속도 테스트 장소 및 테스트 날짜
- 100점 척도로 사이트 로딩 속도 평가(내 경우에는 69점)
- 테스트를 완료하기 위해 만들어진 쿼리 수(66)
- 총 시간확인 중인 페이지 로딩(4.56 - 내 블로그 메인 페이지 로딩 시간)
- 스캔되는 페이지 크기(MB)(1.1MB)
- 테스트 중인 사이트의 로딩 속도를 다른 웹 리소스의 응답과 비교합니다(테스트에 따르면 내 블로그는 연구된 다른 모든 사이트의 34%보다 빠릅니다).
다른 서비스와 마찬가지로 Pingdom 웹사이트 속도 테스트도 로딩 속도 개선을 위한 권장 사항을 제공합니다. 이는 분석 결과의 '성능 등급' 탭으로 이동하면 확인할 수 있으며, 특정 장애물의 영향을 눈금 형태로 명확하게 보여줍니다.
위의 각 서비스를 사용하면 사이트 로딩 속도를 시각적으로 확인할 수 있을 뿐만 아니라 개선을 위한 웹마스터 권장 사항을 제공할 수 있습니다. 그리고 가장 중요한 것은 이러한 모든 도구가 완전 무료라는 것입니다. 하지만 제가 말씀드리고 싶은 또 다른 확인 옵션이 있습니다.
WEBO 사이트 속도 향상
WEBO 회사는 웹 사이트 성능 속도를 높이는 솔루션 개발을 전문으로 합니다. 그녀는 웹사이트 성능 개선 전문가입니다.
그러나 오늘 우리는 그것에 대해 이야기하지 않습니다. 이 회사의 웹사이트에서는 모든 웹사이트의 로딩 속도를 확인할 수 있는 무료 보고서를 얻을 수 있습니다. 이렇게 하려면 이 페이지로 이동하여 양식을 작성하세요. 여기에는 블로그 주소, 이름, 사서함보고를 받고 연락처(가능한 상담을 위해). 잠시 후 다운로드 보고서를 주문했음을 알리는 첫 번째 편지를 받게되고 조금 후에 확인 결과를 받게됩니다. 아마도 전체 그림을 볼 수 있는 것은 이 데이터(러시아어! 🙂) 덕분일 것입니다. 어떤 경우에도 이 분야 전문가의 훌륭한 보고서는 결코 헛되지 않을 것입니다.
그건 그렇고, 이 회사는 유료상품다양한 플랫폼을 위한 WEBO 사이트 SpeedUp. 블로그 로딩 속도를 높이는 특별한 플러그인도 있습니다. CMS 워드프레스. 나는 이 제품을 내 치아에 시험해 보기로 결정했습니다. 이 부가 기능의 압축 및 최적화 알고리즘을 통해 내 사이트가 훨씬 더 빨라지기를 바랍니다. 다음 기사 중 하나에서 사용 결과에 대해 별도로 쓸 것입니다.
그렇다면 웹사이트의 로딩 속도를 확인해야 할까요?
사이트 응답속도가 매우 중요한 요소그의 성공적인 프로모션검색 엔진에서. 웹 리소스의 페이지가 더 빨리 표시될수록 더 많은 검색 사용자를 얻을 수 있습니다. 하나는 다른 하나와 분리될 수 없습니다. 더 나쁜 속도- 블로그 독자 수가 적습니다. 더 적은 클라이언트서비스의 경우 온라인 상점 상품 구매자가 적습니다.
사이트 속도를 분석하면 모든 것이 괜찮은지, Yandex 및 Google 방문자가 콘텐츠에 얼마나 빨리 액세스하는지 항상 알 수 있습니다. 분석된 매개변수가 포함된 수신된 보고서 덕분에 항상 약하고 강점사이트의 모든 페이지. 따라서 계속해서 최신 정보를 확인함으로써 다양한 순위 요소의 저하에 영향을 미치지 않는 페이지 로딩 속도 문제를 방지할 수 있습니다.
블로그 성능 확인을 게을리하지 마세요! 그러면 독자를 잃지 않고 시간을 절약하며 신경 세포를 절약할 수 있습니다. 🙂
SEO 치트 시트 독자를 위한 보너스
. 가장 널리 사용되는 웹 도구 세트인 Google Analytics에는 사이트 성능에 대한 데이터를 제공하는 표준 보고서가 있습니다. 또 다른 SEO 치트시트 형식의 추가 자료로 페이지 성능 보고서에 대한 정보를 준비했습니다. 이 치트 시트를 읽는 사람은 아니지만 이를 받고 싶다면 이 게시물 뒤에 나오는 양식을 작성하기만 하면 됩니다.
웹사이트 로딩 속도가 엄청나네요 중요한 매개변수. 사이트가 더 빨리 로드될수록 사용자가 기다려야 하는 시간이 줄어들고 더 많은 사용자가 필요한 것을 찾을 수 있습니다. 결과적으로 검색 엔진은 더 빠른 사이트에 보상을 제공하고 검색에서 더 높은 순위를 보여줍니다.
하지만 사이트 속도를 최적화하려면 먼저 사이트를 확인하고 문제가 있는지, 정확히 어디에 있는지 확인한 다음 수정해야 합니다. 이 기사에서는 다양한 서비스를 사용하여 웹 사이트의 로딩 속도를 확인하는 방법과 얻은 값을 이해하는 방법 및 이를 어떻게 처리할지 살펴보겠습니다.
로드하는 데 시간이 너무 오래 걸리고 페이지가 완전히 로드되는 동안 다른 탭을 열고 다른 작업을 수행하는 웹 사이트를 접한 적이 있을 것입니다. 이렇게 되어서는 안 됩니다. 이 모든 것을 숫자로 표현할 수 있습니다.
- 0,1-0,5 초또는 100-500ms - 즉시 사용자는 지연을 느끼지 못할 것입니다. 또 다른 점은 다양한 이미지, 스크립트 및 스타일로 가득 찬 현대 사이트에서는 그러한 로딩 속도가 불가능하다는 것입니다.
- 1 - 3 초 - 최선의 선택, 사용자는 약간의 일시 중지를 느낄 수 있지만 이로 인해 짜증이 나지 않으며 사이트에서 계속 작업하게 됩니다. 이것이 우리가 노력해야 할 결과입니다.
- 5-10 초그리고 더 - 매우 나쁘다. 사용자는 기다려야 할 것이고 그는 단순히 떠날 수 있다. 또는 적어도그는 사이트에 대해 불쾌한 인상을 갖게 될 것입니다.
5초 이상이면 진지하게 최적화하고 최적화해야 하는 시간입니다. 하지만 먼저 웹사이트 속도가 무엇인지 알아내는 방법에 대해 이야기해 보겠습니다.
사이트 로딩 속도 확인 중
1. 구글 크롬
가장 먼저 사용해야 할 도구는 브라우저입니다. 여기에서 페이지 로드 속도와 생성되는 요소를 자세히 확인할 수 있습니다. 과부하. 예를 들어 홈 페이지와 같은 사이트를 열고 Ctrl+Shift+J를 누른 다음 탭으로 이동합니다. "성능":
브라우저에 F5 버튼을 눌러 페이지를 새로 고치고 세션을 기록하라는 메시지가 표시되면 로딩 속도가 표시됩니다.
페이지 하단에 결과가 나와 있는데 8.1초 만에 로딩이 돼서 아쉽지만 페이지의 첫 번째 요소가 2초 만에 등장해 사용자들이 큰 불편함을 느끼지 않았다는 뜻이다. 여기에서 많은 유용한 정보를 찾을 수 있습니다. 어떤 자료를 로드하는 데 오랜 시간이 걸렸는지, 비문을 확장하면 확인할 수 있습니다. "회로망":
예를 들어, 다양한 스타일의 로딩 시간은 약 400ms로 상당히 많습니다. 무너지다 "회로망"그리고 봐 "프레임". 파란색 표시기주요 구성요소 로드가 완료되고 사용자가 페이지의 첫 번째 요소(DOM 로드됨)를 본 시기를 표시합니다.
요소의 로딩이 그래프에 표시됩니다. "기본", 파란색 - HTML 코드, 노란색 - 스크립트, 녹색 - 미디어 데이터, 분홍색 - 스타일.
여기에서 사이트 페이지 로딩에 대한 많은 유용한 정보를 찾을 수 있지만 몇 가지 단점이 있습니다. 첫째, 인터페이스가 너무 복잡하고 둘째, 이는 인터넷에만 해당되며 다른 컴퓨터에서는 모든 것이 다를 수 있습니다. 그러므로 당신도 사용해야합니다 온라인 서비스에스.
2. 핑덤 도구
Pingdom은 매우 간단한 인터페이스를 가지고 있으며 사이트의 각 요소가 얼마나 빨리 로드되는지 확인할 수 있는 동시에 매우 간단하고 직관적인 인터페이스를 제공하는 훌륭한 서비스입니다. 검색창에 웹사이트 주소를 입력하세요:
7.22에서 로딩된 페이지는 구글 크롬과 거의 동일한 결과였으며, 동시에 해당 페이지에서 다양한 파일에 대한 요청이 115개나 전송되었고 전체 페이지 용량은 1.9MB였습니다.
다음은 사이트 로딩 속도에 대한 전체 차트입니다. 이를 사용하면 로드하는 데 시간이 오래 걸리는 리소스를 확인할 수도 있습니다.
로 정렬할 수 있습니다. "로드 시간"현장에서 "정렬 기준":
- 분홍색- DNS를 통해 IP를 수신한 시간
- 보라- SSL 연결 설정 시간
- 파란색- 서버 연결을 기다리는 중입니다.
- 주황색- 데이터 전송 시간
- 노란색- 서버 응답 대기 시간;
- 녹색- 데이터 로딩에 소요된 시간.
무엇이든 개선하기 전에 모든 것을 분석해야 합니다. 그리고 한 가지 요소에만 적용되는 것이 아니라 일반적으로 모든 요소에 적용됩니다. 사이트에서 100개 이상의 요청을 생성하는 경우 큰 문제가 발생하지 않는 한 하나를 최적화해도 속도가 크게 향상되는 것은 아닙니다.
잠시 동안 DNS 받기 SSL 핸드셰이크에는 영향을 미칠 수 없으며 한 번만 수행됩니다. 또한 서버 연결은 네트워크 로드에 따라 달라지며 한 가지 방법으로만 최적화할 수 있습니다. 즉, https를 사용하고 새로운 프로토콜 http2이면 연결은 한 번만 이루어지며 모든 데이터는 하나의 스레드로 전송됩니다.
그 다음에 시간이 흐른다서버 응답을 기다리고 있습니다. 이 매개변수는 웹 서버, PHP, 네트워크 로드 등에서 요청이 처리되는 시간 등 다양한 요소에 따라 달라집니다. 100ms의 지연 시간은 여전히 정상이지만 300ms인 경우 정적 파일- 이것은 이미 문제입니다. 한 페이지에 20장의 사진이 로드되어 있다고 가정해 보겠습니다. 20*300은 이미 6초이고, 더 많은 사진(30, 50장)이 있는 기사를 가져옵니다. 이것이 로딩 시간입니다.
데이터를 수신하는 데 걸리는 시간은 파일 크기에 따라 다릅니다. 즉석 압축을 켜서 최적화할 수 있지만 이렇게 하면 대기 시간이 늘어나거나 특수 유틸리티를 사용하여 모든 것을 미리 압축하면 됩니다.
3. 호스트 추적기
핑돔의 단점은 해외 리소스에서만 사이트 속도를 확인할 수 있다는 점입니다. 러시아에 관심이 있다면 호스트 추적기를 사용하는 것이 가장 좋습니다.
하지만 여기에는 단점이 있습니다. 페이지의 HTML 코드만 로드되고 그게 전부입니다. 이미지나 DOM 구조가 로드되지 않습니다. 예를 들어 모스크바에서는 페이지의 HTML 코드가 79ms에 로드되고 호주에서는 2.5초에 로드됩니다. 예를 들어 Pingdom에서는 동일한 수치가 약 800ms였습니다. 여기서는 사이트 페이지 속도 확인이 수행되지 않습니다. 페이지에서 개별 리소스의 로딩 속도를 확인하려면 해당 URL을 별도로 입력해야 합니다.
4. 단말기 속도 확인
사이트 속도 확인 중 리눅스 터미널당신이 최대한 많은 것을 얻을 수있게 해줄 것입니다 필요한 정보받아들이다 올바른 해결책최적화에. 우리는 가장 큰 문제문제가 있는 파일 이후는 웹 서버가 응답할 때까지 기다리는 데 걸리는 시간을 나타냅니다. 이제 우리는 그것이 어디서 왔는지 이해해야 합니다. 컬 유틸리티를 사용하면 사이트 로딩 속도를 확인하고 첫 번째 바이트가 수신될 때까지의 시간을 측정할 수 있습니다. 실제로 이는 대기 시간 + 연결 + DNS + SSL + 읽기입니다. 명령은 다음과 같습니다.
컬 "https://site" -s -o /dev/null -w "response_code: %(http_code)\n
dns_time: %(time_namelookup)\n\
total_time: %(time_total)"
각 변수의 값:
- time_name조회- 도메인에서 IP 주소로의 변환 시간
- 시간_연결- TCP 연결 설정 시간;
- time_appconnect- SSL 연결에 소요된 시간
- 시간_사전 환승- 데이터 전송을 준비하는 데 소요된 시간
- time_start환승- 서버로부터 첫 번째 바이트를 수신한 시간
- 시간_총- 총 페이지 로딩 시간, HTML만, 스크립트와 이미지 제외.
실제로 웹 서버의 지연 시간은 100ms 미만인 것으로 나타났습니다. 데이터 전송 시간을 0으로 간주하면 pingdom에서 대기하는 시간은 time_starttransfer - time-pretransfer가 됩니다. 이미지와 같은 다른 리소스를 확인할 수 있습니다.
여기서는 이미 최대 140ms의 동일한 대기 시간을 볼 수 있습니다. 그걸 고려하면 나쁘다 구글 서버이 매개변수는 최대 5ms입니다. 서버에서 추가 분석을 계속해야 합니다. tcpdump를 사용하여 웹 서버가 얼마나 빨리 결과를 반환하는지 살펴보겠습니다. 추가 지침은 VPS/VDS에서만 완료할 수 있으며 호스팅에서는 작동하지 않습니다. SSH를 통해 서버에 로그인하고 동일한 명령을 실행합니다.
$ 컬 "http://test..png" -s -o /dev/null -w "응답_코드: %(http_code)\
dns_time: %(time_namelookup)\n\
연결_시간: %(time_connect)\n\
AppCon 시간:\t%(time_appconnect)\n\
pretransfer_time: %(time_pretransfer)\n\
starttransfer_time: %(time_starttransfer)\n\
total_time: %(time_total)"
결과는 완전히 달라집니다. 내 서버가 이 요청을 처리하는 데 63밀리초가 걸렸습니다. 이를 통해 다른 모든 지연은 네트워크 문제라는 결론을 내릴 수 있습니다. tcpdump를 사용하여 패킷과 헤더가 전송되는 방식을 계속 추적할 수 있지만 SSL을 비활성화해야 합니다. 그렇지 않으면 거기에서 아무것도 이해하지 못할 것입니다.
tcpdump -n -S -s 0 -vvvvv -A "(tcp dst 포트 80 또는 tcp src 포트 80) 및 (dst 호스트 your_ip 또는 src 호스트 your_ip)"
자세한 내용은 별도의 기사에서 확인할 수 있습니다. 실제로 이 필터는 포트 80에서 수신되거나 포트 80에서 전송된 모든 패킷을 표시해야 함을 의미하며, 해당 패킷은 IP 또는 IP로 전송됩니다. 이제 다른 터미널에서 사이트의 http 버전에 대한 컬 요청을 실행하면 tcpdump에 표시됩니다. 전체 목록패키지 및 내용물:
14:30:08.392309 IP(tos 0x0, ttl 54, id 61543, 오프셋 0, 플래그, proto TCP (6), 길이 129)
95.133.238.84.landmarks > 185.22.173.108.http: Flags , cksum 0x9f58 (올바른), seq 1691128117:1691128194, ack 3071477496, win 229, 옵션, 길이 77
[이메일 보호됨]...__..T...l...Pd..5........X.....
.Laa2../GET/HTTP/1.1
호스트: test.site
사용자 에이전트: 컬/7.50.1
수용하다: */*
14:30:08.392357 IP(tos 0x0, ttl 64, id 65431, 오프셋 0, 플래그, proto TCP (6), 길이 52)
185.22.173.108.http > 95.133.238.84.landmarks: 플래그 [.], cksum 0xb483 (잘못됨 -> 0x6fa7), seq 3071477496, ack 1691128194, win 227, 옵션, 길이 0
E..4..@ [이메일 보호됨] _..T.P......디..............
2..p.라아
14:30:08.402702 IP(tos 0x0, ttl 64, id 65432, 오프셋 0, 플래그, proto TCP (6), 길이 2948)
185.22.173.108.http > 95.133.238.84.landmarks: 플래그 [.], cksum 0xbfd3 (잘못됨 -> 0x2316), seq 3071477496:3071480392, ack 1691128194, win 227, options , 길이 2896
에.....@.@.(~...l_..T.P......d......
2..(.LaaHTTP/1.1 200 확인
서버: nginx/1.13.3
날짜: 2017년 8월 18일 금요일 11:30:08 GMT
콘텐츠 유형: 텍스트/html; 문자셋=UTF-8
전송 인코딩: 청크
연결: 연결 유지
만료: 2017년 8월 18일 금요일 21:30:08 GMT
프라그마: 공개
캐시 제어: max-age=36000, 공개
X-Powered-By: W3 총 캐시/0.9.5.4
- 14:30:08.392309 - 페이지에 대한 요청이 전송되었습니다.
- 14:30:08.402702 -답변을 받았습니다.
시간은 마이크로초 단위로 표시됩니다. 실제로 웹 서버 시간 초과는 10393마이크로초 또는 10밀리초였습니다. 이제 모든 문제는 네트워크에 있고 웹 서버는 Google 서버만큼 완벽하게 작동한다는 것이 분명해졌습니다. 하지만 네트워크로 무엇을 할지는 완전히 별도의 주제, 이는 이 기사의 범위를 벗어납니다.
결론
이번 글에서는 다양한 서비스를 이용하여 웹사이트의 로딩 속도를 확인하는 방법과 웹사이트의 속도가 느린 이유를 이해하는 방법을 살펴보았습니다. 사이트가 얼마나 빨리 로드되는지에 따라 사용자가 얼마나 편안하게 사용할 수 있는지가 결정됩니다. 따라서 사이트의 로딩 속도를 정기적으로 테스트하고 속도를 높이기 위해 가능한 모든 조치를 취하십시오.
작가에 대해
창립자이자 사이트 관리자이며 오픈 소스 소프트웨어와 운영 체제리눅스. 저는 현재 메인 OS로 Ubuntu를 사용하고 있습니다. Linux 외에도 관련된 모든 것에 관심이 있습니다. 정보 기술그리고 현대 과학.
안녕하세요, 블로그 사이트 독자 여러분. 오늘 저는 웹사이트 로딩 속도와 같은 중요한 주제에 대해 이야기하고 싶습니다. 웹 프로젝트 홍보에 영향을 미치는 다른 많은 요소들과 함께 최근 검색 엔진이 이를 고려하기 시작했다는 사실을 이미 들어보셨을 것입니다. 그리고 현장의 브레이크는 방문자, 특히 이에 익숙한 사람들을 매우 짜증나게 합니다.
그럼에도 불구하고 많은 웹마스터들에게 로딩 속도는 즉시 고민해야 할 문제가 아니며 일반적으로 나중으로 미뤄집니다. 긴 상자, 자원을 독특한 재료로 채우고 개선하는 것과 관련된 긴급한 문제 내부 최적화, 그러나 영향을 미치는 전체 요인 세트. 그들이 말했듯이, 사슬은 가장 약한 고리만큼만 강합니다...
웹사이트 로딩 속도 측정을 위한 온라인 서비스
어쨌든 최근까지 리소스 속도를 높이려고 노력하는 것에 대해 제가 느낀 감정은 다음과 같습니다. 하지만 불쾌한 추세(즉, 로딩 속도가 더 중요하기 때문에 의 트래픽 감소)를 기다리지 않고 지금 당장 명백한 단점을 수정하는 것이 더 낫다는 생각이 들었습니다.
그걸 깨달아야만 해 속도, 귀하의 사이트, 블로그 또는 포럼이 로드되는 곳에서, 매우입니다 중요한 지표 . 프로젝트가 이 지표에 따라 제대로 진행되지 않으면 상당히 불쾌한 결과를 초래할 수 있습니다. 그리고 그 중 가장 중요한 것은 방문자가 귀하의 리소스 사용을 거부할 수 있다는 것입니다. 페이지를 로드하는 데 시간이 매우 오래 걸립니다. 또한 검색 엔진, 특히 Google은 특정 리소스의 전반적인 유용성을 평가할 때 이를 고려합니다.
리소스 페이지가 얼마나 빨리 로드되는지 이해하려면 제공된 링크의 기사에 자세히 설명된 기능 등을 사용할 수 있습니다. 또는 이를 위해 설계된 서비스를 사용할 수도 있습니다. 아래에서는 이에 대한 몇 가지 예를 제시하겠습니다.
- 핑덤- 여기서는 로딩 속도를 측정하려는 페이지의 주소만 표시하면 됩니다(로딩 속도가 측정되기 때문에 메인 페이지일 필요는 없습니다). 내부 페이지그 이하도 아니고 종종 훨씬 더 중요합니다).
결과적으로 개별 웹 페이지 개체의 다운로드 시간 다이어그램과 해당 URL 및 무게가 표시됩니다. 적재되는 물체의 수가 적을수록 무게는 가벼워집니다., 더욱 좋습니다. 예를 들어, 이 목적을 위해 나는:
- 사이트 테마의 일부 사진을 다음과 같이 결합했습니다.
- 그리고 가능하다면
- 그 외에는 말이 된다
실제로 Pingdom 상단 메뉴의 인접한 탭에서 몇 가지 문제와 사이트 속도 측정 기록을 추적할 수 있습니다.
팝업 창에서 완료된 테스트에 대한 영구 링크를 복사하고 이메일이나 트위터로 보내라는 메시지가 표시됩니다. 창 하단에서 이용 가능 여부를 구독할 수도 있습니다. 귀하의 리소스가 다운되면(방문자가 사용할 수 없게 되는 경우) 이메일이나 SMS를 통해 귀하의 휴대폰으로 메시지가 전송됩니다. 그러나이 서비스는 유료이지만 무료 평가판이 가능합니다.
귀하의 사이트에서 Traceroute를 보려면 페이지 맨 위에 있는 "Ping and Traceroute" 탭을 선택해야 합니다. 제공된 양식에 http가 없는 URL을 입력하고 이 양식 아래의 "Traceroute" 또는 "Ping" 확인란을 선택한 다음 "지금 테스트"를 클릭하세요.
- 웹페이지테스트— 평소와 같이 확인하고 있는 페이지의 URL을 입력하세요(반드시 메인 페이지일 필요는 없음). 서비스는 모든 사이트 요소의 로딩 속도를 계산하는 데 약간의 시간이 걸리며 그 후 매우 시각적인 다이어그램을 생성합니다(보다 정확하게는 첫 번째 패스와 두 번째 패스의 경우 일부 사이트 요소가 브라우저에서 로드될 때) 은닉처):
첫 번째 다이어그램에서 보라색 수직선의 위치에 주의하세요. 사이트 렌더링 종료 시간. 두번째 수직선(파란색)은 다음을 의미합니다 시간 완전 부하 . 첫 번째 줄은 사이트 로딩 후 1~1.5초, 두 번째 줄은 4초 전이면 좋습니다. 그러면 다음 단락을 "참고용"으로 읽을 수 있습니다. 사이트를 로드하는 데 4초 이상 걸리는 경우 이 상황을 해결하는 데 대해 걱정해야 합니다.
- Google PageSpeed 인사이트
Google 자체의 개발자를 위한 도구입니다. 이는 사이트의 로딩 속도(또는 이 속도의 최적화)를 100점 단위로 평가합니다. 100은 도달할 수 없는 이상이지만 80-90을 얻는 것은 상당히 가능합니다. 특히 서비스가 매우 자세한 권장 사항확인된 결함을 수정합니다.
위 스크린샷에서 볼 수 있듯이 Google PageSpeed Insights는 컴퓨터 브라우저와 모바일 브라우저에 대한 포괄적인 평가를 제공합니다. 또한 아래에서는 다양한 장치에서 리소스 사용 용이성에 대한 평가를 확인할 수 있습니다. 아직 신경 쓰지 않았다면 점수가 매우 낮을 것입니다. 스마트폰 창 오른쪽에 있는 웹 사이트 스크린샷에 모든 것이 명확하게 표시됩니다.
하지만 가장 중요한 것은 Google PageSpeed Insights 사이트 점수를 높이는 방법에 대한 권장 사항을 제공합니다., 즉. 속도를 높이는 방법. 이러한 수정이 속도 향상에 가장 큰 기여를 하기 때문에 자연스럽게 맨 위에서부터 시작해야 합니다.
예를 들어, Apache가 nginx와 함께 작동하기 때문에 gzip 압축을 설정하고 사용자 브라우저에서 정적 파일(이미지, CSS 파일 및 스크립트)에 대한 캐싱 시간을 설정하는 데 문제가 있었지만 어떻게 작업해야 할지 모르겠습니다. 그것. 나는 모든 것을 설정해 달라는 요청과 함께 Infobox 기술 지원에 편지를 보내야 했습니다. 그들은 그것을 해냈고 심지어 돈도 받지 않았습니다(그들 덕분입니다!). 그건 그렇고, 처음에는 캐시 저장 시간을 1시간으로 설정했지만 Google PageSpeed Insights는 여전히 불평했습니다.
나는 이 온라인 서비스에 대한 지침을 자세히 살펴보고 캐시에 정적 정보를 저장하는 데 필요한 최소 기간은 1일이라는 내용을 읽어야 했습니다. 나는 호스팅 기술 지원에 1주일의 예비금을 제공해달라고 요청했고 그들은 그렇게 했습니다. 이제 등급이 조금 올랐고 Google은 로딩 속도 측면에서 내 리소스에 대해 큰 불만이 없습니다.
- 내 사이트 테스트 — 새로운 서비스다시 Google에서. 기본적으로 그는 로딩 속도 기준을 포함하여 사이트의 모바일 버전을 평가하는 데 중점을 둡니다.
그들이 말하는 것처럼 간단하고 세련된. 변경 사항에 대한 뉴스레터를 구독할 수 있습니다.
- GTmetrix- 다시 한번 "더 이상 고민하지 말고" 원하는 페이지의 URL을 입력하고 분석이 완료될 때까지 잠시 기다리세요. 결과적으로 Page Speed(아래 작업 방법 참조)와 YSlow라는 두 가지 브라우저 플러그인의 데이터를 기반으로 생성된 보고서를 받게 됩니다. 실제로 어떤 데이터를 신뢰하고 누구의 권장 사항을 따라야 하는지는 귀하에게 달려 있습니다.
나는 이것에 대해 이미 어느 정도 자세히 썼으므로 이미 번거로운 기사를 어지럽히 지 않기 위해 반복하지 않겠습니다 (끝까지 읽으면 자신을 영웅이라고 생각할 수 있습니다).
- 핑 관리자- 비슷한 온라인 리소스광대한 행성의 여러 부분에서 서버 응답 시간을 측정합니다.
- 호스트 추적기- 국가만 다르고 거의 똑같습니다.
- 바이트체크— 최적화 과정에서 종종 주의를 기울이는 사이트의 TTFB(Time To First Byte) 값을 측정할 수 있습니다. 이는 브라우저가 서버로부터 데이터의 첫 번째 바이트를 수신하는 시간입니다. TTFB 값이 높을수록 서버가 리소스를 처리하는 속도가 느려지는데 이는 좋지 않습니다. 웹사이트 로딩 최적화를 위한 팁을 읽어보세요.
- 부하 영향- 이것은 전적으로 속도에 관한 것이 아니라 중요한 서비스. 이를 통해 사이트의 로드 용량과 페이지 로딩 속도가 감소하는지 테스트할 수 있습니다. 매우 유용한 것입니다.
- 웹 페이지 속도- 90년대 초반 디자인의 온라인 서비스이지만 사용성 부족에 적응한다면 꽤 유익합니다. 아래에 주어진다 일반적인 권장 사항상황을 바로잡기 위해.
페이지 로딩 속도를 추적하는 것이 정말 중요합니까?
하지만 속도를 측정하는 것에서 속도를 높일 수 있는 기회를 찾는 것으로 돌아가 보겠습니다. , 이전에는 사이트의 로딩 속도를 평가하는 실험적인 "사이트 성능" 탭이 있었습니다.
일반적으로 거기에 표시된 로딩 속도에는 범죄가 없지만 사실 내 블로그 사이트는 전체 로딩 속도의 84%보다 느리게 로딩됩니다. 웹 리소스인터넷에서-이것은 이미 응답해야 할 종입니다. 하지만 Google은 내 블로그가 속도 측면에서 외부인이라고 생각하기 때문에 이 문제를 진지하게 받아들이고 속도를 높이는 방법에 대한 문제를 진지하게 다룰 가치가 있습니다.
사실 특별히 고안할 필요는 없었다. 구글이 스스로 가장 최적의 솔루션을 제시해주기 때문이다. 보다 정확하게는 사이트 속도를 조금(또는 많이) 높이기 위해 수행해야 할 작업이 정확히 무엇인지 이해하는 데 도움이 되는 도구를 사용할 것을 제안합니다. 온라인 서비스에 대해 이야기하고 있어요. 페이지 속도(이전에는 제가 주로 사용했던 FireFox와 Chrome에 동일한 이름의 브라우저 확장 프로그램도 있었습니다.)
이 도구는 주로 미묘함과 뉘앙스와 관련된 매우 복잡하고 일반 웹마스터에게는 완전히 이해할 수 없는 작업에 작동한다는 점을 즉시 예약하겠습니다. 웹 작업섬기는 사람. 서버를 관리해 본 적이 없다면 어려울 것입니다.
탈출구가 있습니다- 호스트에게 스트레스를 주다 Paige Speed가 규정하는 작업을 수행하는 주제에 대해 설명합니다. 그가 동의하는지 여부는 또 다른 문제입니다. 아무에게나 서버에 대한 액세스 권한을 부여하는 것이 어색하기 때문에 감히 그렇게 하지 못했습니다. (그래서 저는 불신합니다.)
기본 페이지에서 PageSpeed는 Apache 또는 Nginx(제 경우)를 실행 중인 경우 서버에 모듈을 설치할 것을 제안하기도 합니다.
하지만 저는 서버 관리를 전혀 이해하지 못하고 Unix를 사용해 본 적이 없기 때문에 이것이 어떻게 수행되는지 아직도 이해하지 못합니다. 유사한 시스템. 이는 프로그램을 설치하거나 WordPress에 플러그인을 업로드하는 것보다 훨씬 더 어렵습니다. 또 다른 차원의 몰입감. Hoster는 또한 이것에 대해 감히 그를 괴롭히지 않았습니다. 일반적으로 저는 이 모듈을 테스트하지 않았습니다. 이미 테스트해 보시고 말씀하실 내용이 있을 수도 있습니다...
일반적으로 처음으로 Page Speed를 브라우저 확장 프로그램으로 사용했습니다. (지금은 이해한 대로 작동하지 않습니다.) 이전에는 Firefox 및 Chrome의 개발자 도구에 통합되었습니다. 사실, 처음에는 (몇 년 전) 그가 나에게 어떤 조언을 했는지 간략하게 살펴봤고 거의 아무것도 이해하지 못한 채 이것이 나에게 적합하지 않다고 판단한 후 가벼운 마음으로 PageSpeed를 삭제했습니다. 내 마음에 불필요하고 이질적인 요소로 플러그인.
사실은 이 플러그인이 무엇을 맹세하는지 이해하더라도 무엇을 해야할지 몰랐다, 이 모든 것을 제거하고 어떻게든 블로그 속도를 높이려면. 일반적으로 나는 마우스가 소란을 피우는 것에 비해 더 중요한 할 일을 즉시 발견했습니다. 웹 설정서버(특히 내가 특별히 이해하지 못하기 때문에)는 작고 중요하지 않은 것처럼 보였습니다.
사실, 한때 나도 보안 문제에 대한 해결책을 미루었고 그 결과 모든 돈을 잃고 그 대가를 치렀습니다. 무슨 일이 일어났는지 염두에 두고, 얼마 전 이 문제가 나에게 얼마나 이해하기 어렵고 어려운 문제였음에도 불구하고 나는 발 뒤꿈치를 파고 사이트 로딩 속도를 높이는 문제를 계속 진행하기로 결정했습니다.
간단히 말해서 Mazila에 Page Speed를 다시 설치하고(이제 더 이상 이 작업을 수행할 필요가 없음) 가장 불만이 많았던 부분을 정확히 살펴보았지만 여전히 몇 가지 사항을 개선할 수 있었으면 좋겠습니다. 최소한 속도를 조금 높이십시오.
추신 이제 Page Speed는 온라인에서만 사용할 수 있으며 더 이상 브라우저에 설치할 필요가 없습니다(어쨌든 이 플러그인은 새 버전의 Chrome과 호환되지 않습니다). 그러나 이것이 본질을 바꾸지는 않습니다.
따라서 이전에는 브라우저에 플러그인을 설치해야 했지만 이제는 플러그인만 설치하면 됩니다. 여기, 분석하려는 페이지의 URL을 입력하세요( 다른 유형페이지에는 로딩 속도와 관련된 다양한 문제가 있을 수 있으므로 이 도구의 모든 옵션을 확인하는 것이 좋습니다. 파란색 "분석" 버튼을 클릭하세요.
인증 결과를 기다리면 다음과 같은 창이 나타납니다. 그것과 비슷하다, 텍스트의 위 스크린샷에서 이미 인용한 내용입니다(웹 사이트 로딩 속도를 확인하기 위한 온라인 서비스 설명의 3항). 저것. 결과적으로 이 온라인 서비스가 귀하의 리소스, 즉 로딩 속도에 대해 가지고 있는 불만 사항의 전체 목록을 볼 수 있습니다. 그 후에 그는 작업을 최적화하는 방법에 대한 몇 가지 지침을 제공할 것입니다. 웹 서버사용중인 엔진과 결합됩니다.
또한 Page Speed 창 맨 위에는 보고 변경하고 싶은 의견과 권장 사항이 있습니다. 첫째로(“확실히 고치세요”) 이는 로딩 속도를 높이는 측면에서 가장 큰 효과를 주고 너무 많은 노력이 필요하지 않기 때문입니다. 제가 실제로 다루지 않는 작은 프로젝트 중 하나에 대한 분석의 예를 들어보겠습니다.
저것들. 느낌표가 있는 빨간색 직사각형으로 표시되고 목록의 맨 위에 있는 권장 사항 및 발견된 문제가 가장 중요하며 이를 통해 최적화를 시작하는 것이 좋습니다(그들이 말하는 것처럼 저렴하고 유쾌함). 가장 큰 효과.
주황색으로 표시된 문제는 수정하기 위해 더 많은 노력이 필요하지만 속도가 크게 향상되지는 않을 수 있습니다. 아, 아, 지금은 그 일을 뒤로 미루고 프로젝트 속도를 크게 높이는 데 도움이 되는 우선순위 작업을 계속할 수 있습니다.
몇 년 전 내 초기 사진(플러그인을 사용하는 경우에도 - 이제 PageSpeed API를 사용하기 때문에 http://gtmetrix.com/에서도 동일한 내용을 볼 수 있음) https://site는 다음과 같았습니다.
그런 다음 첫 번째 지점인 "브라우저 캐싱 활용"부터 시작하기로 결정했습니다. "브라우저 캐시를 사용하세요"), 왜냐하면 논리적으로 작품 페이지속도, 이러한 권장 사항은 내 블로그의 가능한 가장 빠른 속도를 가져옵니다.
이 비문 옆에 있는 스포일러를 클릭하시면 만족스럽지 못한 다양한 파일들의 목록이 나옵니다. 최적의 요구 사항 정적 객체 캐싱(스크립트, CSS 파일, 에 사용된 이미지 파일 웹페이지 f) 사용자 브라우저(예: 리더):
저것들. 로딩 속도를 높이기 위해 PageSpeed Insights는 사용자 브라우저에서 웹 페이지의 다양한 요소에 대한 캐싱을 최적으로 구성하여 다른 페이지를 볼 때 이러한 정적 요소가 서버에서 다시 로드되지 않도록 조언합니다. 이론적으로는 이 모든 것이 매우 혼란스럽게 들립니다. 왜냐하면 브라우저에서 사용하는 캐싱 메커니즘에 대해 전혀 모르기 때문입니다(이에 대한 내용과 삭제 방법을 읽어보세요).
또한 호스팅 서버 자체의 메커니즘을 사용하여 정적 개체의 캐싱을 최적화합니다. 상당히 혼란스럽습니다. 하지만 이미 여러분에게 제안하겠습니다. 기성 솔루션, 인터넷에서 찾은 내용을 실제로 사용해 보고 어느 것이 귀하의 호스팅에 가장 적합한지 결정하게 됩니다.
브라우저 캐싱 최적화 및 작동 확인
사실, 현재 호스팅에서는 작동하지 않았습니다. 이제 Apache와 nginx의 조합이 있기 때문입니다(호스터가 나에게 알려지지 않은 방식으로 수행한 후자를 구성해야 합니다). 그러나 순수 Apache를 사용하는 경우 아래 제안된 방법이 작동할 수 있습니다.
일반적으로 우리는 정적 요소의 캐싱을 최적화하기 위해 브라우저에 명령을 내리는 방식으로 프로젝트가 호스팅되는 서버에 영향을 주려고 노력할 것입니다. 우리는 꽤 잘 알려진 방법을 통해 이 작업을 수행할 것입니다. 도구 리모콘서버 - 파일 .htaccess. 그런 것의 존재에 대해 알고 계시나요?
일반적으로 루트 폴더에 있습니다. 당연히 아래에 설명된 모든 내용은 Apache를 실행하는 서버에서만 작동하지만 일반적으로 대부분의 서버에서 작동합니다. FTP()를 통해 리소스에 연결한 후 다음을 엽니다. 루트 폴더(일반적으로 PUBLIC_HTML 또는 HTMLDOCS) 그 안에 .htaccess 파일이 있는지 확인하세요.
이제부터는 모든 일을 자신의 책임 하에 수행해야 합니다. 따라서 어떤 일이 발생하면 신속하게 롤백할 수 있도록 이 파일의 복사본을 컴퓨터에 다운로드하십시오.
만약에 .htaccess보이지 않으면 시도해 보세요. FileZilla 프로그램상단 메뉴에서 "서버" - "강제 표시" 항목을 선택합니다. 숨겨진 파일" 이 후에도 루트에 나타나지 않으면 편리한 편집기에서 컴퓨터에 빈 텍스트 파일을 만들고(저는 NotePad Plus Plus를 사용합니다) 이름을 지정하고 루트에 복사합니다.
그런 다음 FileZilla에서 이 파일의 이름을 .htaccess로 바꿉니다. 이제 편집을 위해 열어서 아래 코드를 추가해야 합니다. 하지만 먼저 조금 설명하겠습니다.
Apache를 실행하는 웹 서버에서 이 옵션을 활성화하는 가장 일반적인 방법은 mod_headers 또는 mod_expires 모듈을 사용하는 것입니다. 아래 코드는 온라인 서비스에 이러한 Apache 모듈 중 하나 이상이 서버에 설치되어 있는 경우 브라우저에서 정적 캐싱을 활성화하는 데 도움이 됩니다.
먼저 내가 줄게 mod_headers 모듈에 대한 코드. 귀하의 호스팅 업체에 이 모듈이 있는지 확인하기 위해 검사를 사용한다는 점에 유의하십시오. 찾을 수 없으면 코드가 실행되지 않으며 오류가 발생하지 않습니다. 그러나 사고를 방지하려면 먼저 원본(아래 코드를 추가하기 전에) .htaccess 파일을 컴퓨터에 복사하는 것이 좋습니다.
주석(해시 기호로 시작하는 줄)을 삭제할 수 있지만 코드 작동에는 어떤 영향도 미치지 않습니다.
더 추가될 수도 있겠네요 mod_expires용 모듈용으로 설계된 코드 블록, 서버에 해당 코드가 있는지 다시 확인하여 이 코드 조각이 사용하기에 안전한지 확인합니다.
댓글은 나중에 다시 삭제할 수 있습니다.
작동하지 않지만 기적이 일어나길 바란다면 동일한 코드를 몇 가지 더 변형해 보세요. 한 번에 모두 시도하지 말고 한 번에 하나씩 시도해 보세요.
ExpiresActive On ExpiresByType application/javascript "액세스 + 1년" ExpiresByType text/javascript "액세스 + 1년" ExpiresByType text/css "액세스 + 1년" ExpiresByType image/gif "액세스 + 1년" ExpiresByType image/jpeg "액세스 + 1 연도" ExpiresByType image/png "액세스 + 1년" 헤더 세트 캐시 제어: 비공개 헤더 세트 캐시 제어: 공개 BrowserMatch "MSIE" 강제 변경 안 함 BrowserMatch "Mozilla/4.(2)" 강제 변경 안 함 - FileETag MTime 크기
ExpiresActive on ExpiresDefault "액세스 + 1개월"
이제 방문자 측 브라우저에서 캐싱을 최적화하여 속도를 높일 수 있는 코드를 .htaccess에 삽입하고 변경 사항을 저장한 후 PageSpeed Insights에서 리소스 페이지를 다시 확인하고 문제가 사라지는지 확인하세요:
보시다시피 제 경우에는 "브라우저 캐시 사용"이 더 이상 로딩 속도를 저하시키는 심각한 결함이 아니며, 이 메모 옆의 아이콘이 녹색이 아닌 주황색으로 변경되었습니다. 불행하게도 영향력은 제3자 서비스, 내 사이트에서 정적 정보(예: Yandex, Google, Feedburner 및 Aptulaik)를 로드할 수 없습니다.
Q.E.D. 그래서 우리는 Page Speed에서 발견된 가장 중요하고 심각한 문제 중 하나를 알아냈습니다.
서버에서 정적 개체의 압축을 활성화하는 방법
또한 GTmetrix 서비스가 불평하는 매우 일반적인 문제는 파일을 사용자의 브라우저로 전송하기 전에 서버에서 파일이 압축되지 않는다는 것입니다.
이 경우에는 내가 이미 쓴 내용이 사용되었습니다. PageSpeed Insights를 통해 직접 분석하지 않고 GTmetrix를 통해 분석하는 경우 PageSpeed 영역에서 "압축 활성화"를 "gzip 압축 활성화"라고 하며 YSlow에서는 "gzip으로 구성 요소 압축"이라고 합니다.
이것이 최대한 이루어지려면 Gzip 압축 Apache 서버가 사용되는 호스팅에서 이를 활성화하려면 해당 코드 조각을 .htaccess 파일(원격 서버 제어 파일)에 추가하면 충분합니다. Apache에는 압축을 위한 두 개의 모듈이 있으며 그 중 하나는 호스팅 업체에서 설치합니다(사실은 아니지만).
가장 일반적인 것부터 시작하겠습니다. 전체 사이트에서 500 오류가 발생하지 않도록 코드에 이 모듈이 있는지 확인하는 기능을 다시 추가합니다.
약간 덜 인기가 있지만 필요한 파일 형식에 대해 Gzip 압축을 활성화하는 코드는 다음과 같습니다.
실제로 코드를 설치한 후 PageSpeed Insights에서 페이지를 확인해 보세요. 문제가 해결되면 운이 좋다고 생각하세요. nginx가 포함된 Apache가 있기 때문에 이 모든 것이 나에게 도움이 되지 않았습니다(호스터는 nginx가 정적을 담당한다고 말했으며 이 상황에서는 이를 구성해야 합니다. 그가 어떻게 했는지 모르겠습니다).
행운을 빕니다! 블로그 사이트 페이지에서 곧 뵙겠습니다.
에 가시면 더 많은 영상을 보실 수 있습니다");">
당신은 관심이 있을 수도 있습니다
GTmetrix에서 사이트 속도 측정 및 증가, 로딩 설정 jQuery 라이브러리구글 CDN으로 
사이트 로딩 속도를 높이기 위한 Gzip 압축 - .htaccess 파일을 사용하여 Js, Html 및 Css에 대해 활성화하는 방법 
웹사이트 로딩 속도를 최대화하고 서버 로드를 최적화하는 방법
로딩 속도는 웹사이트에서 중요한 부분입니다. 사이트를 로드하는 데 시간이 오래 걸리면 사용자는 사이트가 열릴 때까지 기다리지 않을 수도 있습니다. Google 검색 엔진은 사이트 페이지의 로딩 속도가 결과에서의 위치에 영향을 미친다는 사실을 숨기지 않습니다. 페이지를 로드하는 데 시간이 오래 걸리는 경우 페이지 무게를 최적화하고 더 빠른 호스팅으로 전환하는 것을 고려해야 합니다.
사이트 로딩 속도가 중요한 이유
- 속도는 사용자에게 영향을 미칩니다(신뢰, 타겟 작업 수행 가능성 증가 등).
- 검색 엔진에서 순위 요소 중 하나는 사이트 로딩 속도입니다.
- 로딩 속도는 사이트 탐색 깊이에 긍정적인 영향을 미칩니다.
누구나 사용할 수 있는 무료 웹사이트 로딩 속도 확인 서비스를 살펴보겠습니다. 모든 웹사이트의 로딩 속도를 확인할 수도 있습니다
웹사이트 로딩 속도 확인 서비스
1. 구글 페이지 속도
Google Page Speed의 공식 웹사이트는 https://developers.google.com/입니다. 최근에는 누구나 확인할 수 있게 되었습니다.
페이지 속도의 예
사이트로 이동하여 확인란에 사이트를 입력하세요. 확인 버튼을 클릭하세요. 그 후에는 자세한 보고서가 제공됩니다. 또한 보고서는 모바일 버전과 컴퓨터 모두에 적용됩니다.
보고서에서 가장 중요한 것은 100점 척도의 숫자입니다. 높을수록 좋습니다. 100점을 받은 사이트를 찾는 것은 인터넷에서 드문 일입니다. 대략적으로 말하면 이런 뜻이다. 구글에 따르면사이트 로딩 속도에는 문제가 없습니다.
이 서비스에는 사이트 속도 향상을 위한 권장 사항도 포함되어 있어 매우 편리합니다. 매우 매우 편리합니다. 일반적으로 모든 권장 사항을 하나씩 따르면 사이트 속도를 최소 10..20% 향상할 수 있습니다.
구글 웹마스터
Google에는 사이트 로딩 속도를 결정하는 두 번째 도구가 있습니다. http://www.google.com/webmasters/.
사실, 이 서비스는 사이트 소유자에게만 제공됩니다. 다운로드 속도를 보려면 구글 웹마스터"스캔" 탭 -> "스캔 통계"를 엽니다. 여기에서 사이트 로딩 시간 기록을 볼 수 있습니다.
2. Tools pingdom으로 다운로드 속도 확인하기
다음 링크(http://tools.pingdom.com/fpt/)로 이동하세요. 홈페이지 주소를 입력하고 확인해보세요. 테스트가 끝나면 프로그램은 전체 보고서를 생성합니다. 편리하고 간단한 방법.
속도 테스트는 미국 컴퓨터에서 가장 자주 발생하지만 설정에서 다른 도시를 지정할 수도 있습니다. 물론 호스팅이 외부 IP 주소로 데이터를 전송하는 데 시간이 더 오래 걸릴 수 있기 때문에 이로 인해 특정 미묘한 차이가 발생할 수 있습니다.
Pingdom은 각 항목의 로드 속도를 보여줍니다. 별도의 요소리소스: 스타일, 스크립트, 특정 이미지. 이 데이터를 분석하면 로딩 속도를 높이거나 어떻게든 개선할 수 있습니다.
3. 웨보 펄서
WEBO(사이트: https://webopulsar.ru/test/)를 통해 다운로드 속도를 확인하려면 조금 기다려야 합니다. 이 서비스를 이용하려면 이름, 웹사이트 주소, 이메일, 전화번호 등의 데이터를 입력해야 합니다. 그 후 사이트 테스트 결과가 이메일로 전송됩니다.
서비스 쇼 흥미로운 정보인터넷의 평균 데이터를 보고합니다.
저도 이 서비스가 마음에 들어서 주기적으로 이용하고 있어요.
프로세스가 5초 이상 걸릴 경우 페이지가 로드될 때까지 인내심을 갖고 기다리는 사람은 거의 없습니다. 또한 사이트 로드 속도가 빠를수록 SEO에 더 좋습니다. 따라서 사이트 로딩 속도는 클라이언트와 검색 엔진 모두에 중요합니다.
이 기사는 검색 엔진과 잠재 고객 사이의 평판 손실을 방지하는 데 도움이 되는 웹사이트 로딩 속도를 확인하는 서비스에 관한 것입니다.
인터넷에서는 속도가 느리면 처벌을 받습니다.
사이트 속도 확인: 수행 방법
좋은 페이지 로딩 속도는 0.35~0.38초입니다. 이러한 결과는 상위 검색 결과에 사이트를 표시합니다. 이 시간을 계산하려면 소위 "서버 응답 속도", 즉 클라이언트(브라우저) 요청에 얼마나 빨리 응답하는지 측정해야 합니다.
웹마스터는 유료와 무료, 간편하고 정교한 다양한 서비스를 사용하여 로딩 속도를 측정합니다. 이 기사에서는 그 중 가장 인기 있는 항목을 나열합니다.
Google PageSpeed 인사이트
Google PageSpeed Insights는 무료로 측정하며, 고정 장치. 등급은 100점 척도로 결정되며, 점수가 높을수록 좋습니다. 귀하의 사이트가 85 이상이면 모든 것이 정상입니다. 100점을 목표로 하지 마세요. Google 서비스조차도 이를 수행할 수 없습니다.
사이트를 테스트하려면 개발자.google.com의 표시줄에 URL을 입력하세요. 이 서비스는 속도를 평가하고 성능을 향상시키는 방법에 대한 옵션을 제공합니다.
그것은 간단하고 명확한 서비스무거운 기능 없이.
PageSpeed Insights 모듈은 사이트를 실시간으로 최적화하는 데 도움이 됩니다. 사실, 이 경우 개발자의 도움이 필요합니다.
Yandex.웹마스터
webmaster.yandex.ru 도구를 사용하여 Yandex 로봇 요청에 대한 서버의 응답 속도를 볼 수 있습니다. 응답 시간은 밀리초 단위로 표시됩니다.
응답 코드가 "200 OK"이면 사이트에 문제가 없는 것입니다. 다른 것(“404 Not Found”, “301 Moved Permanently”)이 있으면 문제가 있는 것입니다.
Google과 마찬가지로 Yandex는 등록 없이 사용할 수 있고 백엔드에 대한 깊은 이해가 있는 무료 서비스를 제공합니다.
핑덤
pingdom.com 서비스는 더 많은 것을 제공합니다 자세한 정보위에 나열된 사이트보다 테스트 사이트의 경우. 평가 외에도 전체 속도사이트에서 Pingdom은 각 페이지 요소가 얼마나 빨리 로드되는지 보여줍니다.
사이트에 문제가 있는 경우 Pingdom에서 알림을 보내드립니다. Android 및 iOS용 앱이 있으므로 리소스 속도를 실시간으로 모니터링할 수 있습니다.
이 서비스는 일정 기간 동안 속도 통계를 수집하고 자세한 오류 보고서를 제공합니다. HTTP(S), TCP 포트, Ping, DNS, UDP, SMTP, POP3, IMAP 등 확인 유형을 직접 선택할 수 있습니다.
핑돔의 가장 큰 단점은 서비스가 유료라는 점이다. 가격은 월 $9.95부터 시작됩니다.
Sitespeed.ru
RuNet의 또 다른 인기 있는 도구는 sitespeed.ru입니다. 인터페이스는 간단하고 명확합니다. URL을 작성하고 테스트를 실행하면 결과를 얻을 수 있습니다. 이 서비스는 각 사이트 문제를 처리하는 방법에 대한 자세한 설명을 제공합니다.
또 다른 흥미로운 기능은 사이트 로드 계단식 차트입니다. 각 개체를 로드하는 데 걸리는 시간을 확인할 수 있습니다.
사이트에 이메일을 남겨주시면 테스트 결과에 대한 아름답고 자세한 보고서를 보내드립니다. 그리고 이 모든 것은 완전 무료입니다.
GT메트릭스
GTmetrix를 사용하면 웹사이트 성능을 쉽게 측정할 수 있습니다. URL을 홈 페이지에 붙여넣으면 로딩 속도 데이터와 오류 수정 방법에 대한 권장 사항을 얻을 수 있습니다.
여러 지역에서 속도를 테스트할 수 있습니다. 또한 이 서비스는 모바일 장치에서 리소스의 효율성을 분석합니다.
최대 3개의 URL을 무료로 모니터링할 수 있습니다. 프리미엄 플랜(월 $14.95부터)으로 더 많은 사이트를 연결할 수 있습니다. 여기에는 다른 사람들도 포함됩니다 흥미로운 기회, 브랜드 사이트 속도 보고서, 비디오 녹화 로드 등을 통해 병목 현상을 실시간으로 확인할 수 있습니다.
YSlow
YSlow는 웹페이지를 분석하고 야후의 고성능 사이트 규칙에 따라 무엇이 잘못되었는지 판단합니다. 이것은 Firefox, Chrome, Opera, Safari 등 널리 사용되는 브라우저에 설치할 수 있는 확장 프로그램입니다. 이 서비스는 무료 서비스이며 오픈 소스입니다.
YSlow는 웹 페이지를 평가하고, 구성 요소와 통계를 요약하고, 개선 사항을 제안하고, 성능 분석 도구를 제공합니다. 서비스를 이용하려면 다음으로 이동하세요. 원하는 페이지그리고 브라우저에서 아이콘을 클릭하세요. 새 창에서 "실행" 버튼을 클릭하고 결과를 확인하세요.
웹페이지테스트
WebPagetest는 또 다른 무료 오픈 소스 프로젝트입니다. 그 특징은 다양한 선택테스트를 위한 위치, 가젯 및 브라우저. 타겟 고객에게 가장 적합한 옵션을 선택할 수 있습니다.
테스트 결과에 따라 서비스 페이지에서 직접 대규모 보고서를 받게 됩니다. 테이블, 다이어그램, 다이어그램 - 모든 것이 아름답고 명확하게 디자인되었습니다.
우리로부터 제안을 받고 싶으십니까?
협력 시작웹페이지 분석기
WebPage 분석기를 사용하면 다른 서비스와 동일한 방식으로 URL을 입력하고 결과를 얻을 수 있습니다. SMM 및 등록 없이 빠르고 무료입니다.
페이지 로딩과 모든 추가 스크립트, 스타일 및 이미지에 대한 보고서 테이블을 받습니다. Webpagetest만큼 보기에는 좋지는 않지만 내용 면에서는 열등하지 않습니다.
모비레디
모바일 버전의 로딩 속도는 ""기사에서 쓴 별도의 문제입니다. 이를 테스트하기 위해 모바일 웹 개발자, 디자이너 및 마케팅 담당자를 위한 도구인 mobiReady 서비스가 있습니다. 테스트는 W3C(Windows Consortium) 표준을 기반으로 합니다. 월드 와이드 웹), Yahoo YSlow 및 Google 가이드.
보고서에서는 페이지가 다양한 장치에서 어떻게 보이는지 확인하고 테스트 결과가 포함된 아름다운 인포그래픽을 얻을 수 있습니다.
mobiReady에 비용을 지불하거나 등록할 필요가 없습니다.
어느 것이 더 빨리 로드되나요?
whichloadsfaster.co는 귀하의 사이트를 경쟁사와 비교하려는 경우 유용합니다. 메인 페이지의 필드에 두 사이트의 URL을 입력하고 “Go!”를 클릭하세요. 그리고 누가 이겼는지 확인해보세요. 또한 페이지가 로드된 시간(밀리초)도 나타냅니다.
사이트의 로딩 속도를 정기적으로 평가해야 합니다. 이는 and에 중요합니다. 현대적인 서비스테스트는 서버가 사용자 요청에 응답하는 데 걸리는 시간, 페이지 속도를 늦추는 요소, 오류 수정 방법을 알아내는 데 도움이 됩니다. 일부 도구는 다음을 제공하지만 대부분의 기능은 무료로 사용할 수 있습니다. 추가 기능고급 사용자를 위한 돈입니다.
다른 속도 테스트 서비스를 사용하시나요? 댓글에 이에 대해 적어보세요.
(1,598회 방문, 오늘 2회 방문)