HTTP/2 및 페이지 속도 소개

게시 됨: 2020-01-03

소개

1991년에 문서화된 요청-응답 HTTP(HTTP 0.9) 프로토콜의 첫 번째 버전이 도입되었습니다. 그 이후로 웹은 크게 확장되었으며 24년 후 HTTP/2(HyperText Transfer Protocol)의 최신 버전이 2015년에 출시되어 올바르게 구현되었을 때 사이트 성능에 많은 이점을 제공했습니다.

이 기사는 페이지 속도 최적화 이니셔티브의 일부로 HTTP/2를 구현하려는 SEO를 대상으로 합니다.

HTTP/2는 매우 자세하게 논의될 수 있는 매우 풍부한 주제입니다. HTTP/2에 대해 논의하는 풍부한 온라인 정보가 있으며 최종 사용자와 개발자에게 더 광범위한 이점이 있지만 HTTP/2에 대한 풍부한 정보에 빠져들기 전에 필요한 정보를 얻고 있는지 확인하십시오. 이것은 올바른 질문을 하는 것으로 시작됩니다.

  1. 이것이 검색 엔진 최적화 및/또는 페이지 속도에 어떤 직접적인 영향을 줍니까?
  2. 통찰력으로 추천할 수 있습니까?
  3. 권고가 현실적으로 이루어질 수 있는가?

이 질문들은 “내가 하는 일이 효과적이고 가치 있는 일인가?”라는 질문을 하는 데 도움이 됩니다. 그리고 궁극적으로 HTTP/2가 웹사이트 개선에 어떻게 도움이 되는지 평가할 수 있는 더 나은 위치에 놓이게 됩니다.

주제의 광범위한 특성으로 인해 SEO의 중요성을 이해하려고 할 때 필요하지 않은 HTTP/2에 대한 많은 지식이 있습니다. SEO를 위한 HTTP/2의 핵심 이점은 페이지 속도입니다.

풍부한 온라인 정보를 탐색하는 데 도움이 되도록 HTTP 1.1에서 Google의 HTTP 호환 Spdy, 그리고 결국에는 HTTP/2로의 진화를 설명하는 HTTP/2에 대한 소개가 있습니다.

웹이 어떻게 진화했는지 이해하면 HTTP/2 프로토콜 추가의 결과로 웹에 대한 개선 사항을 강조하는 데 도움이 됩니다.

Google은 Page Speed를 어떻게 평가합니까?

Google이 Page Speed를 평가하는 방법을 보려면 Chrome 사용자 경험 보고서 를 살펴보십시오 . 이 보고서는 사용자가 웹에서 인기 있는 목적지를 경험하는 방법에 대한 사용자 경험 메트릭을 제공합니다. 이는 주요 사용자 참여 측정항목(First Paint, First Contentful Paint, First meaningful Paint, Time to Interactive)을 사용하여 제공되며 Page Speed ​​Insights, Public Google Big Query Project, Lighthouse 및 Web Page Test와 같은 일반적인 도구를 통해 추가로 지원됩니다. 이러한 측정항목과 도구를 활용하면 Page Speed를 개선하는 데 도움이 될 수 있습니다.

HTTP/2 소개

HTTP 1.1

2015년까지 HTTP 1.1은 구식이 되었습니다. 웹 페이지/사이트가 기본 HTML, CSS, JavaScript, 수많은 리소스 및 다양한 프레임워크에 구축/의존되던 시대는 지났습니다. 2015년 이전 시대는 TCP 연결당 하나의 요청으로 제한된다는 아이디어를 기반으로 했습니다. 이로 인해 웹 클라이언트에 다운로드 대기 중인 여러 리소스가 있어 네트워크 정체와 페이지 로드 시간이 느려지는 상황이 발생했습니다.

HTTP/2는 위에서 논의한 문제를 완화하기 위해 세 가지 주요 개선 영역을 목표로 설계되었습니다.

  • 간단
  • 고성능
  • 견고성

HTTP/2의 SEO 이점

페이지 속도는 SEO가 자체 웹사이트나 클라이언트 웹사이트에서 HTTP/2 구현을 고려하는 주된 이유일 것입니다. 페이지 속도/성능은 2010년부터 데스크톱 쿼리 의 순위 요소가 되어온 측정항목 집합입니다 . 모바일 장치 사용의 증가로 인해 2018년 7월 Google 은 Page Speed가 모바일의 순위 요소가 될 것이라고 공식적으로 발표 했습니다.

HTTP/2는 Page Speed에 맞게 사이트를 최적화할 때 활용할 수 있는 3가지 주요 기능을 제공합니다.

  1. 다중화
  2. 서버 푸시
  3. 스트림 우선 순위 지정

다중화

멀티플렉싱을 사용하면 웹 클라이언트가 하나의 단일 TCP 연결 내에 여러 요청을 포함할 수 있으므로 서버 부하가 낮아지고 네트워크 정체가 줄어듭니다.

이전 HTTP 1/1.1 프로토콜을 사용하는 최신 웹 클라이언트(Chrome, Firefox, Safari 및 Opera)에는 호스트 이름당 동시 TCP 연결 수에 대한 기본 제한이 있습니다. 따라서 HTTP 1/1.1을 사용하는 웹 클라이언트는 TCP 혼잡에 쉽게 어려움을 겪을 수 있습니다. 최신 웹 클라이언트에서 이 문제는 멀티플렉싱을 사용하여 해결되어 페이지 속도를 가장 크게 개선할 수 있습니다.

아래는 HTTP/1.1과 HTTP/2를 비교하여 멀티플렉싱할 때의 이점으로, HTTP/2 멀티플렉싱이 활성화되어 있거나 비활성화되어 있을 때의 일반적인 동작을 보여줍니다.

( WebpageTest, HTTP/1.1, 멀티플렉싱이 시연되지 않음 )

( WebpageTest, HTTP/2, 멀티플렉싱 시연 )

위의 이미지에서 성능 기반 워터폴 은 웹 페이지의 사용자 (리소스를 요청하는 사람)와 서버 (누가 어떤 리소스에 응답하는지 ) 간의 리소스 로드를 보여주는 데 사용됩니다 . 일반적으로 페이지 리소스에는 HTML, JavaScript, CSS 및 이미지가 포함됩니다. 성능 기반 폭포수는 사이트에서 페이지 속도 문제를 발견, 평가 및 분석하는 데 중요한 클라이언트 내에서 특정 리소스가 호출, 다운로드 및 렌더링되는 정확한 시점을 보여줍니다. "HTTP/2" 위의 이미지에서 알 수 있듯이 모든 리소스는 다른 지점에서 로드를 시작하는 리소스 없이 동시에 다운로드를 시작합니다. HTTP/2는 멀티플렉싱을 활용하고 더 이상 단일 TCP 연결을 통해 하나의 요청만 보내는 데 의존하지 않으므로 위에서 본 것처럼 여러 리소스를 동시에 다운로드할 수 있습니다. 대조적으로, 이미지 "HTTP/1.1"에서 보여주듯이 리소스는 멀티플렉싱 기능을 활용할 수 없기 때문에 동시에 다운로드되지 않습니다. HTTP/1.1 아래의 평균적인 최신 브라우저는 동시에 6개의 연결을 가질 수 있지만 HTTP/2를 구현하는 이점은 모든 요청에 ​​대해 TCP 핸드셰이크가 필요하지 않은 반면 HTTP/1.1 초기에 얼마나 많은 연결을 동시에 실행할 수 있는지에 상관없이 매번 연결 과정을 완료해야 합니다. 따라서 다른 지점에서 다운로드를 시작하므로 사용자에게 더 긴 페이지 로드가 발생합니다.

( Upwork HTTP/1.1 대 HTTP/2 다이어그램 )

Google 및 Bing과 같은 검색 크롤러는 HTTP/2 구현의 직접적인 이점을 얻지 못합니다. 위에서 설명한 것처럼 이러한 최적화의 주요 이점은 잠재적으로 Page Speed에 있을 수 있습니다. 따라서 HTTP/2 구현은 검색 크롤러에 직접적인 영향을 미치지 않을 수 있지만 2010년 이후 데스크톱용 Google 검색어와 2018년 7월 이후 모바일 검색어의 직접적인 순위 요소인 Page Speed에 영향을 미칠 수 있습니다. 결과적으로 웹사이트가 게재되지 않는 것이 중요합니다. Google이 순위에 영향을 미치거나 최근에는 사이트가 느릴 수 있음을 사용자에게 표시하여 성능을 억제할 수 있으므로 사용자에게 느린 경험을 제공합니다.

서버 푸시

서버 푸시를 사용하면 클라이언트가 요청하지 않은 경우 특정 서버 또는 에지 네트워크가 웹 클라이언트에 리소스를 보낼 수 있습니다. 서버 푸시 기능을 이해하려면 먼저 웹 사이트가 따르는 요청-응답 패턴을 이해하는 것이 중요합니다. 사용자는 웹사이트에서 페이지를 요청하고 서버는 요청된 콘텐츠/리소스로 응답합니다.

Styles.css라는 외부 스타일 시트에 정의된 모든 스타일이 있는 사이트를 가정해 보십시오. 사용자가 페이지(이 경우 index.html)에 대한 HTML 골격을 요청할 때 서버 푸시는 index.html에 대한 응답을 보내기 시작한 직후 사용자에게 CSS를 "푸시"할 수 있습니다.

( S 매싱 매거진, 서버 푸시 )

서버 푸시가 Page Speed를 개선하는 데 어떻게 도움이 되는지 이해하기 전에 브라우저가 이미지, CSS 및 JavaScript와 같은 다양한 리소스와 함께 작동하여 브라우저에 표시되는 방식을 이해하는 것이 중요합니다. 브라우저는 이미지, CSS 및 JavaScript 리소스를 다운로드하는 방법에 대한 지침을 보냅니다. 웹사이트를 처음 방문할 때 일반적으로 .html 파일인 GET 요청을 합니다. 이 .html 파일이 수신되면 브라우저는 파일을 검색하여 이해한 다음 HTML 파일에 포함된 내용에 따라 추가 GET 요청을 할 수 있습니다.

서버 푸시가 페이지 속도 향상에 어떻게 도움이 됩니까?

서버 푸시를 사용하면 브라우저에서 필요한 GET 요청 수(왕복)가 줄어들고 페이지 로드 시간을 증가시키는 렌더링 지연을 피할 수 있습니다. 이는 웹 클라이언트의 렌더링 시간을 크게 향상시켜 사용자에게 웹 페이지를 더 빠르게 표시하여 훨씬 더 나은 경험을 제공하는 데 도움이 될 수 있습니다.

서버 푸시는 Googlebot이 사이트 또는 실제로 다른 크롤러를 크롤링하는 방식에 직접적인 영향을 미치지 않지만 첫 번째 페인트 및 첫 번째 의미 있는 콘텐츠와 같은 사용자 중심 요소의 개선을 통해 SEO 이점을 얻을 수 있습니다.

웹 페이지 테스트, Lighthouse, Page Speed ​​Insights 및 Chrome 사용자 경험 보고서를 활용하여 동일한 산업 내 경쟁업체와 비교하여 사이트/페이지의 성능을 확인할 수 있습니다. 아래는 서버 푸시가 없는(이미지 1) 및 서버 푸시(이미지 2)가 있는 구현을 보여주는 두 개의 이미지입니다.

(WebpageTest, 서버 푸시 없음)

(WebpageTest, HTTP/1.1, 서버 푸시 포함)

서버 푸시를 사용하면 추가 페이지 구성 요소(예: CSS 파일, JavaScript 및 이미지)가 포함된 .html 파일을 보내도록 요청받은 경우 항상 추가 페이지 구성 요소를 보내도록 서버를 구성할 수 있습니다.

위의 폭포에서 우리는 push.php가 4개의 CSS 파일을 사용하는 것을 볼 수 있습니다.

서버 푸시가 없으면 브라우저는 push.php 파일을 수신하고 HTML을 구문 분석한 다음 각 추가 CSS 파일에 대해 특정 요청을 해야 합니다. 모든 CSS 파일을 받은 후에만 렌더링 프로세스에서 사용할 수 있습니다.

서버 푸시가 활성화되면 push.php에 대한 요청이 자동으로 서버가 4개의 CSS 파일을 통해 전송하도록 트리거합니다. 브라우저는 이를 수신하고 훨씬 더 일찍 렌더링 프로세스에서 사용할 수 있습니다. 즉, 브라우저가 페이지 콘텐츠 렌더링을 훨씬 더 빨리 시작할 수 있으므로 페이지 속도 메트릭이 향상됩니다.

HTTP/2 우선 순위

HTTP/2 우선 순위 지정은 리소스가 로드되는 순서에 대한 제어를 사이트 소유자에게 다시 넘겨줍니다. 적절하게 수행되면 우선 순위 지정은 페이지 리소스를 최적화된 순서로 제공하여 "빠른" 사용자 경험을 생성함으로써 사용자 경험과 페이지/사이트 속도를 향상시킵니다.

HTTP/2의 이전 버전인 HTTP/1.1을 보면 웹 클라이언트가 리소스가 로드되는 순서를 제어했습니다. 위에서 논의한 바와 같이 이것은 각 TCP 연결이 한 번에 하나의 리소스만 지원할 수 있었기 때문입니다. 선택할 리소스와 병렬로 열 연결 수를 결정하여 요청을 예약하는 것은 브라우저에 달려 있습니다.

수행 방법에 대해 설명하기 전에 리소스에 우선 순위 지정을 사용하려는 이유를 이해하는 것이 중요합니다.

페이지 상단에 이미지가 있고 페이지 하단에 이미지가 있는 경우 논리적으로 상단의 이미지가 하단의 이미지보다 먼저 로드되도록 해야 합니다. 이 개념은 HTTP/2 우선 순위 지정이 가져올 수 있는 중요성과 영향을 입증하는 데 도움이 됩니다. HTTP/2 우선 순위 지정을 통해 어떤 리소스가 먼저 전달되고 다른 리소스보다 먼저 로드되어야 하는지(JavaScript, CSS 또는 이미지인지 여부)를 지정할 수 있으므로 페이지의 가장 빠른 로드 시간을 보장할 수 있습니다.

브라우저는 이제 멀티플렉싱을 사용하여 단일 TCP 연결을 통해 여러 리소스를 동시에 요청할 수 있지만 이제 각 요청에 우선 순위 정보를 지정하여 리소스를 언제/어떻게 전달해야 하는지 결정할 수 있습니다. 서버와 브라우저가 모두 HTTP/2 우선 순위 지정을 지원하는 경우 브라우저는 리소스가 서로 경쟁하지 않고 전체 대역폭을 활용하여 우선 순위 지정 규칙을 정의해야 합니다. 우선 순위 지정 프로세스가 어떻게 작동하는지 더 잘 이해하려면 HTTP/2 우선 순위 지정에 중요한 세 가지 매개변수를 논의하는 것이 중요합니다.

스트림: 하나 이상의 메시지를 전달할 수 있는 설정된 연결 내 바이트의 양방향 흐름입니다.

상위 스트림: 리소스가 의존하는 스트림입니다.

하위 스트림: 상위 스트림의 종속 스트림입니다. 그들은 동일한 부모를 공유하므로 자식 스트림으로 알려져 있습니다.

가중치: 여러 스트림이 연결을 공유하는 경우 스트림에 할당할 대역폭을 식별하는 1에서 256 사이에 할당된 숫자입니다. 대역폭은 다른 모든 활성 스트림의 가중치를 기준으로 할당됩니다.

배타적 비트: 다른 스트림과 대역폭을 공유하지 않고 스트림을 다운로드해야 함을 나타내는 플래그입니다.

헤더 프레임: 스트림이 속한 프레임의 ID입니다.

Binary Framing Layer: HTTP 메시지가 캡슐화되어 클라이언트와 서버 간에 전송되는 방식입니다 .

아래 예는 위의 예를 보여줍니다.

( Google 개발자 HTTP/2 스트림 우선 순위 지정 )

HTTP/2 우선 순위 지정을 수행하려면 새 HTTP/2 바이너리 프레이밍 레이어에 있는 헤더 프레임 내에 우선 순위 정보를 추가해야 합니다. 상위 스트림 및 다른 하위 스트림에 대한 종속성/비종속성은 우선순위/가중치를 결정하고 따라서 리소스의 웹 클라이언트로의 전달을 결정합니다.

HTTP/2 우선 순위 지정은 현재 다양한 플랫폼에서 지원되지만 많은 CDN 및 호스팅 공급자는 HTTP/2 우선 순위 지정을 지원하지 않습니다. 따라서 이 최적화 기술을 사용하려면 HTTP/2 우선 순위 지정을 지원하는 CDN/호스팅 공급자를 활용하고 있는지 확인하는 것이 중요합니다. 다음은 HTTP/2 우선 순위 지정을 지원할 수 있는 CDN/호스팅/서버를 설명하는 표입니다.

HTTP/2 우선 순위 - 공통 서버/호스팅/CDN 호환성

이 비교는 2020 년 2월 1일에 정확했지만 어떤 서비스를 선택할지 결정하기 전에 잠재적인 서비스 공급자가 호환성을 개선했는지 확인하는 것이 좋습니다.

불행히도 모든 브라우저가 HTTP/2 우선 순위를 지원하지 않으며 웹 클라이언트가 다르기 때문에 우선 순위가 다르기 때문에 특정 브라우저를 비판적으로 보는 것도 중요합니다. 다음은 HTTP/2 우선 순위를 지원할 수 있는 웹 클라이언트를 설명하는 표입니다.

HTTP/2 우선 순위 웹 클라이언트 호환성

HTTP/2 우선 순위 지정은 페이지/사이트 속도에 대한 사용자의 인식을 크게 향상시킬 수 있으며 Chrome 사용자 경험 보고서에 축적된 데이터에 긍정적인 영향을 미칩니다. 이 최적화는 Googlebot과 같은 검색 크롤러에는 영향을 미치지 않지만 Lighthouse 및 Page Speed ​​Insights 와 같은 도구 는 HTTP/2 우선 순위 지정이 사용자 관점에서 페이지 속도 성능에 미치는 영향을 평가하는 데 도움이 됩니다.

HTTP/2 지원 CDN/호스트를 사용하여 서버와 클라이언트 모두에서 스트림 가중치를 올바르게 구성하면 클라이언트의 페이지 속도 메트릭을 크게 향상시킬 수 있습니다.

HTTP/2의 전제 조건은 무엇입니까?

HTTP/2의 속도 이점을 활용하기 전에 이를 활용할 수 있는지 확인하십시오. 고려해야 할 몇 가지 전제 조건이 있습니다.

  1. HTTPS가 활성화되어 있는지 확인하는 것이 중요합니다.
  2. 인증 기관의 TLS 인증서를 활용하고 인증서를 활성화 및 설치합니다.
  3. Nginx, Apache 및 IIS와 같은 웹 서버 소프트웨어가 HTTP/2를 지원하는지 확인하십시오. 지원을 위해 인증된 전체 목록은 HTTP/2에 대한 브라우저 지원을 보여주는 http://ayi.ma/browsershttp2 에서 찾을 수 있습니다. CDN/Hosting에 대한 HTTP/2 지원을 찾고 있다면 http://ayi.ma/serverhosting 을 참조하십시오 .

일반적인 함정 / HTTP/2의 도입으로 변경되어야 하는 것들

이전 HTTP 1.0 및 HTTP 1.1 프로토콜의 제한으로 인해 개발자와 SEO는 이러한 제한이 페이지 속도 성능 및 보안에 대해 제시한 다양한 문제를 해결하는 방법을 찾기 위해 노력해 왔습니다.

결국 그들은 이러한 제한 사항 중 일부를 회피하기 위해 "해킹"을 찾을 수 있었지만 이러한 방법 중 많은 부분이 개발자에게 더 많은 작업을 야기했습니다. 이러한 해킹에는 어떤 것이 있습니까? 다음은 HTTP/2의 올바른 구현을 통해 해결할 수 있는 사이트에서 볼 수 있는 가장 일반적인 해킹입니다.

도메인 샤딩 피하기

놀랍게도 많은 사이트에서 HTTP/2가 올바르게 구현되었지만 여전히 이 해킹을 사용합니다. HTTP/2가 활성화되면 도메인 샤딩을 사용하지 않는 것이 중요합니다. 도메인 샤딩은 리소스를 서로 다른 호스트 이름으로 분할하여 더 많은 리소스를 동시에 제공할 수 있도록 하는 기술입니다.

업데이트된 HTTP/2 프로토콜 덕분에 도메인 샤딩은 더 이상 필요하지 않으며 실제로 해결되는 것보다 더 많은 문제가 발생합니다. HTTP/2가 사이트에 대해 올바르게 구성 및 활성화되어 있고 도메인 샤딩도 사용하는 경우 브라우저가 여러 호스트 이름에 대한 다중화 및 다운로드의 이점을 누릴 수 없기 때문에 실제로 HTTP/2의 일부 이점을 상쇄하게 됩니다.

또한 도메인 샤딩을 통해 실제로 스트림 우선 순위를 위반하고 페이지 속도를 최대한 활용하기 위해 리소스를 로드할 수 없습니다.

서버 푸시를 적절히 활용

서버 푸시에는 알고 있어야 하는 몇 가지 단점이 있습니다. 서버 푸시는 실제로 남용될 수 있으며 사용 시기를 선택할 때 선택해야 합니다. 너무 많은 리소스를 푸시할 필요는 없습니다. 이렇게 하면 웹 클라이언트가 HTML뿐만 아니라 "푸시"되는 모든 항목을 다운로드할 수 있기 때문입니다. 즉, 페이지를 로드하고 렌더링하는 데 실제로 시간이 더 오래 걸릴 수 있습니다(Time to Interactive와 같이 Google에서 집중하는 사용자 중심 측정항목 증가).

서버 푸시의 두 번째 일반적인 함정은 웹 클라이언트가 이미 가지고 있는 리소스를 푸시하지 않는 방법을 파악하는 것입니다. 이것은 다양한 방법을 통해 제어할 수 있습니다. 한 가지 방법은 리소스를 반환하는 사용자에게 푸시하지 않도록 선택하여 반환된 사용자가 캐시된 자산을 활용할 수 있도록 하는 것입니다. 이것은 지금까지 가장 쉬운 구현입니다. 헤더가 서버 푸시 구현과 겹치지 않는지 확인하는 리소스에 대한 캐시 헤더를 확인하여 간단히 수행할 수 있습니다.

HTTP/2에서 실제 테스트

HTTP/2와 그 이점을 이해하기 위한 토대를 마련하려면 이론적 지식이 항상 중요합니다. 개념이 파악되고 이해되면 HTTP/2가 Page Speed에 미칠 수 있는 영향을 측정하기 위해 이러한 이론을 테스트하는 것이 중요합니다.

이 Page Speed ​​시리즈 HTTP/2의 2부 - 웹사이트 테스트 및 분석 을 사용하여 페이지 속도 및 SEO 가치와 관련하여 HTTP/2의 진정한 이점에 대해 논의할 것이므로 놓치지 마십시오!

HTTP/3는 어떻습니까?

HTTP/3가 HTTP/2의 후속 프로토콜로서 분명한 잠재력을 보여주긴 하지만 웹 전반에 걸쳐 SEO를 위한 HTTP/2의 끝을 알리거나 신호를 보내서는 안 됩니다. 월드와이드 웹에 대한 모든 새로운 주요 개발과 마찬가지로 정상적인 롤아웃 단계를 거치게 되며 사이트가 새로운 프로토콜을 채택하고 SEO 업계에서 사실상의 표준이 되기까지는 시간이 걸릴 것입니다. HTTP/2 구현은 올바르게 구현될 경우 사이트 성능을 개선하는 데 도움이 될 수 있는 유익하고 간단한 이점을 나타냅니다.