Firebase 호스팅에 HTTP/2 활용하기
아무 것도 하지 않아도 Firebase 호스팅에 HTTP/2를 활용할 수 있습니다! 사용자 브라우저가 지원하기만 하면 HTTP/2가 자동으로 제공됩니다. 하지만, HTTP/2에 맞게 최적화하려는 경우에는 염두에 두어야 할 몇 가지 모범 사례가 있습니다.
- 단일 연결을 사용하여 동시 요청을 다중 송신할 수 있기 때문에 많은 리소스를 함께 연결하기 위한 이점은 더 이상 없습니다. 브라우저는 리소스 캐시 작업을 훌륭하게 수행하므로, 실제로는 변경 빈도가 더 낮은 파일을 더 많이 제공하는 것이 좋습니다. 여기서 더 많은 파일은 수십개의 파일을 의미합니다. 수백 개의 파일을 처리하면 여전히 상당한 오버헤드를 수반할 수 있으므로 주의해야 합니다.
- 자산을 여러 도메인에 "분할"할 필요가 없습니다. Firebase 호스팅은 이미 빠른 CDN을 사용하기 때문에 HTTP/2를 사용하면 동일한 도메인에서 모든 파일을 제공하는 데 유리합니다.
- 따라서 필요한 자산만 로드하시기 바랍니다! 왕복 횟수가 더 적으므로 애플리케이션 셸을 부트스트랩하는 데 필요한 파일만 로드하도록 최적화해야 합니다. 다른 리소스는 사용자 상호 작용을 바탕으로 필요에 따라 로드되어야 합니다.
위에 명시된 지침은 꼭 지켜야 하는 규칙은 아닙니다. 성능 최적화를 할 때와 마찬가지로 어떤 최적화 조합이 앱의 요구 사항을 가장 잘 충족하는 결과를 제공하는지 다양하게 테스트해야 합니다.
서버 푸시 테스트
Firebase 호스팅은
Link 헤더를 사용하여 HTTP/2 서버 푸시를 시험적으로 지원합니다. 서버 푸시를 사용하면 초기 요청 수행 시 서버가 추가 리소스를 위한 콘텐츠를 자동으로 전송할 수 있습니다. 서버 푸시의 가장 일반적인 용도는 페이지가 로드될 때 연결된 자산(예: JavaScript 또는 CSS 파일)을 전송하는 것입니다.
Firebase 호스팅에 서버 푸시를 구성하려면 다음과 같이 Link 헤더를 firebase.json 구성에 추가해야 합니다.
{
"hosting": {
"headers": [
{
"source": "/",
"headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style"}]
},
{
"source": "/users/*",
"headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style;nopush,</css/users.css>;rel=preload;as=style"}]
}
]
}
}
여기서는 루트 경로에서 /js/app.js와 /css/app.css를 미리 로드하고, /users/*와 일치하는 경로에서 /css/users.css를 추가로 미리 로드하는 데 서버 푸시를 사용합니다. 브라우저 캐시에 이미 있을 가능성이 큰 파일에 대해서는 (두 번째 예제의 app.css에 대한 지시문과 같이) nopush 지시문을 사용하여 HTTP/2 푸시를 사용하지 않고 자산을 미리 로드할 수 있습니다.
서버 푸시는 아직 초기 단계이므로 다음과 같이 명심해야 할 사항이 몇 가지 있습니다.
- Link 헤더를 설정하는 데 와일드카드를 사용하는 경우 주의해야 합니다. 리소스가 그 자체를 미리 로드하도록 설정하면 안 됩니다.
- 서버 푸시는 성능과 대역폭 사용 간에 균형을 맞추는 기술입니다. 즉, 브라우저에서 이미 캐싱된 자산을 푸시할 경우 불필요한 데이터를 전송하게 됩니다. 푸시되는 자산을 성능에 중요한 작은 자산으로 유지하도록 노력하고, 사용자가 휴대기기에서 추가 데이터에 대한 비용을 지불해야 할 수 있다는 점을 알고 있어야 합니다!
- 미리 로드하기 기능은 푸시를 사용하지 않고도 탁월한 성능을 제공하는 데 유용합니다! ;nopush를 미리 로드 Link 헤더에 추가하면 브라우저는 서버 푸시 없이 자산을 미리 로드합니다. 이는 브라우저에 이미 캐싱되어 있을 수 있다고 생각하는 자산에 유용합니다.
저희는 HTTP/2가 최초의 로드 환경을 개선할 잠재력이 얼마나 될지 무척 기대되며, 서버 푸시를 단순하고 안정적이며 사이트에 효과적인 것으로 만들어줄 더 많은 방법을 강구하고 있습니다.
맞춤 도메인 마이그레이션
HTTP/2로 마이그레이션하면서, 저희는 SSL 인증서를 SNI(Server Name Indication)로 전환하는 중입니다. SNI는 계속해서 인프라를 더욱 안정적으로 확장할 수 있도록 해주며,
전 세계 98% 브라우저에서 지원됩니다. 이러한 변화는 사용자 트래픽에 영향을 미칠 가능성이 있으므로, 2016년 12월까지 기존의 맞춤 도메인을 자동으로 전환하지 않을 계획입니다.
2016년 8월 11일 이전부터 Firebase 호스팅에 맞춤 도메인을 보유한 분이라면 DNS 레코드를 업데이트해야 HTTP/2를 이용할 수 있습니다. dig <your-site>.firebaseapp.com을 실행하여 SNI로 이미 전환되었는지 확인할 수 있습니다. 결과에 s-sni.firebaseapp.com이 표시되면 사이트가 이미 마이그레이션된 것입니다.
CNAME을 사용하는 경우 마이그레이션하려면 s-sni.firebaseapp.com을 가리키도록 DNS를 업데이트해야 합니다. A 레코드를 사용하는 경우에는 다음과 같이 업데이트하십시오.
151.101.1.195
151.101.65.195
DNS를 변경하고 그 변경 내용이 전파되면 사이트가 HTTP/2로 구동될 것입니다! 올해 말까지 모든 Firebase 호스팅 트래픽을 HTTP/2와 SNI로 전환할 예정입니다. 따라서 SNI가 사용자에게 어떤 영향을 미칠지 걱정된다면
지원 사이트를 방문하시기 바랍니다.
Firebase 호스팅과 관련된 저희의 목표는 모든 이가 PWA(Progressive Web Apps) 개발의 모범 사례를 자유롭게 활용하도록 하는 것입니다. HTTP/2는 이런 목표를 향한 여정에서 거치는 또 하나의 단계이며, 여러분이 이를 활용하여 무엇을 빌드할지 정말 기대됩니다!
▶ 원문 링크
