소개
빠른 웹 앱은 성공적인 웹 앱입니다. 앱의 실제 성능과 인지된 성능을 모두 최적화할 때까지 개발자의 업무는 끝나지 않습니다. 단순히 사용자에게 우수한 환경을 제공하는 것은 옳은 일일 뿐만 아니라, 최적화해야 하는 실용적이고 중요한 비즈니스 이유도 있습니다. Amazon은 사이트 지연 시간이 100밀리초마다 1% 씩 판매 감소를 측정했고, Google에서는 0.5초마다 트래픽이 20% 씩 감소했습니다 (인용). 이는 비즈니스 및 웹 앱에 실질적인 영향을 미치는 실제 수치입니다.
웹 속도는 아주 중요한 만큼, Google에서는 웹 속도를 높이기 위해 최선을 다하고 있습니다. 앱 성능을 최적화할 또 다른 이유가 필요하다면 Google은 Google의 순위 알고리즘에 페이지 속도가 추가되었다고 발표했습니다.
고성능 웹사이트와 더 빠른 웹사이트 등 훌륭한 책 2권 등 웹 앱 성능 최적화를 위한 권장사항이 많이 게시되어 있습니다. 서버 (올바른 캐시 제어 헤더 구현)와 클라이언트 (이미지 너비 및 높이 속성 제공)의 기법이 성능 최적화를 위한 엔드 투 엔드 전략으로 결합됩니다. 도움말 및 유용한 정보가 매우 많기 때문에 이 모든 정보가 실제 생활과 실제 웹 앱에 어떻게 매핑되는지 측정하기가 어려울 때가 있습니다.
다행히 Chrome DevTools (모든 Chrome 인스턴스에 포함되어 있음)는 웹 앱을 검사하고 성능을 향상하고 지연 시간을 줄이기 위한 맞춤 권장사항을 제공하는 탁월한 도구를 제공합니다. 이 도움말에서는 가장 많이 사용되는 YSlow 도구와 범위가 비슷한 감사 패널을 살펴보고, 이 패널을 사용하여 웹사이트 속도를 높이고, 지연 시간을 줄이고, 사용자 만족도를 높이는 방법을 설명합니다.
감사 패널 도구는 현재 Chrome에서만 사용할 수 있지만 향후 다른 WebKit 브라우저에서도 통합될 것으로 예상됩니다.
시작하기
감사 패널에서 웹 앱 성능 개선을 어떻게 추천할 수 있는지 설명하기 위해 이 도구를 자체 www.html5rocks.com으로 전환하고자 합니다. 또한 감사 패널을 사용하여 사이트 속도를 개선해 보겠습니다.
DevTools는 Chrome 창 오른쪽 상단에 있는 Chrome 아이콘을 사용하고 도구 > 개발자 도구를 선택하기만 하면 쉽게 시작할 수 있습니다.
DevTools를 시작하는 방법에 관한 자세한 내용은 공식 문서를 참고하세요.
감사 패널은 기본 도구 버튼 패널에 있습니다. 감사 패널을 선택하면 아직 웹 앱에 대한 분석이 실행되지 않은 것을 알 수 있습니다. 특히 Gmail과 같은 큰 웹 앱에서는 모든 휴리스틱이 느리게 실행될 수 있으므로 도구가 기본적으로 사용 중지되어 있습니다.
실행 버튼을 클릭하여 시작해 보겠습니다. 성능 휴리스틱이 사용 설정된 상태로 웹 앱이 새로고침됩니다. 페이지를 새로고침하면 아래 스크린샷과 비슷한 권장사항 목록이 표시됩니다.
감사 패널에서는 제안을 심각도별로 분류하며, 가장 심각한 항목은 빨간색 점으로, 보통 심각도의 제안은 노란색 점으로 표시됩니다. 이러한 색상 코딩을 통해 가장 중요하고 가장 큰 이득에 먼저 초점을 맞춰 추천의 우선순위를 정할 수 있습니다.
제안사항 다음에 나오는 괄호 안의 숫자는 감사 도구에서 감지한 인스턴스 수입니다. 예를 들어 '브라우저 캐싱 활용'의 인스턴스는 12개입니다. 이를 통해 추천이 얼마나 자주 적용될 수 있는지 파악할 수 있습니다.
속도 전략
앞서 언급했듯이 웹 앱 성능을 최적화하기 위한 잘 알려져 있고 많이 테스트된 전략이 많이 있습니다. 이 도움말에서 이러한 내용을 자세히 다루지는 않겠지만, 자세한 정보와 세부정보를 쉽게 찾을 수 있습니다. 웹 앱 최적화의 구체적인 내용을 자세히 알아볼 수 있는 유용한 리소스로는 더 빠른 웹 만들기 및 높은 확장성의 지연 시간은 어디에나 있고 판매 비용이 듭니다.
감사 패널에서 제안사항은 네트워크 사용률과 웹페이지 성능의 두 가지 카테고리로 분류됩니다.
감사 패널에 따르면 네트워크 사용률을 개선하려면 다음과 같이 조치해야 합니다.
- 브라우저 캐싱 활용
- 프록시 캐싱 활용
- 쿠키 크기 최소화
- 쿠키가 없는 도메인에서 정적 콘텐츠 제공
- 이미지 크기 지정
웹페이지 성능을 개선하려면 다음과 같이 해야 합니다.
- 스타일과 스크립트의 순서 최적화
- 사용하지 않는 CSS 규칙 삭제
지금부터는 htmlrocks.com의 실적 향상에 도움이 되는 전략에 대해 살펴보도록 하겠습니다.
브라우저 캐싱 활용
예를 들어 먼저 브라우저 캐싱을 활용하는 권장사항을 살펴보겠습니다. 구체적으로 어떤 의미가 있나요? UI에서 옵션을 열면 다음 세부정보가 표시됩니다.
- 다음 리소스에 캐시 만료가 없습니다. 만료를 지정하지 않은 리소스는 브라우저에서 캐시할 수 없습니다.
- 다음 캐시 가능한 리소스는 새로고침 기간이 짧습니다.
- 다음 리소스는 명시적으로 캐시할 수 없습니다. 가능하면 캐시 가능하게 만드는 것이 좋습니다.
리소스 캐싱은 네트워크 사용률을 개선하는 훌륭한 방법이며, 이로 인해 개발자는 대역폭 요금을 낮추고 사용자는 더 빨리 응답할 수 있습니다. 안타깝게도 이 도구는 개발자가 해야 할 일을 정확히 알려주지 않으므로, 권장사항을 좀 더 자세히 살펴보고 웹 앱 성능 최적화에 관한 지식을 활용하여 이러한 추천을 적용해야 합니다.
캐싱
HTTP 캐싱에 대해 자세히 알아보지 않고도 기본적인 몇 가지 사항을 다룰 수 있습니다. HTTP 프로토콜에는 캐싱 명령이 포함되어 서버와 클라이언트가 네트워크를 통해 전송해야 하는 데이터의 양을 줄일 수 있습니다. 예를 들어 서버는 클라이언트에게 특정 시간 동안 로컬에 리소스를 저장하도록 지시할 수 있으므로 리소스를 다시 요청할 필요가 없습니다. 또한 클라이언트는 서버의 리소스가 로컬에 저장된 리소스보다 최신인지를 물을 수 있습니다. 리소스가 정적인 경우 서버에서 리소스를 로컬에 저장하라고 클라이언트에게 알려주고 나중에 서버에 리소스를 요청하지 않는 것이 이상적입니다. 상상할 수 있듯이 HTTP 캐싱에 관한 엄청난 양의 세부정보가 있지만 일반적인 주제는 '리소스를 클라이언트에 로컬로 저장하여 유선으로 전송되는 데이터의 양을 줄이는' 것입니다.
캐시할 수 없는 리소스 수정
권장사항을 자세히 살펴보고 감사 권장사항을 DevTools 내의 다른 도구에 연결하는 방법을 알아보겠습니다. 특히 '다음 리소스는 명시적으로 캐시할 수 없음'을 수정하는 방법을 살펴보겠습니다.
캐싱은 HTTP 프로토콜을 통해 수행되므로 http://www.html5rocks.com/ 리소스에 대한 HTTP 요청 및 응답을 살펴봐야 합니다. 리소스를 클릭하기만 하면 원래 요청 및 응답 헤더와 세부정보를 볼 수 있습니다.
그러면 클릭된 리소스 유형에 따라 Network, Resources 또는 Sources 패널로 이동하여 자세한 정보가 나와 있습니다. 이 경우 Network 패널로 이동합니다.
서버에서 클라이언트에 'html5rocks.com의 홈페이지를 캐시하지 마세요'라고 지시했는지 확인 중입니다. 이렇게 하려면 리소스를 클릭하여 응답 헤더를 확인합니다. 응답 헤더는 서버에서 전송한 헤더와 지침이기 때문입니다.
Cache-Control 헤더당연히 서버가 'Cache-Control: no-cache' 헤더를 클라이언트에 전송했습니다. 이는 예상할 수 있듯이 항상 리소스를 요청하고 리소스를 로컬에 캐시하지 않도록 클라이언트에 지시합니다. 구체적으로 'no-cache'의 HTTP 사양은 다음을 읽습니다.
'no-cache 지시어가 필드 이름을 지정하지 않는 경우 캐시는 원본 서버를 이용한 재검증 성공 없이 후속 요청을 충족하기 위해 응답을 사용하면 안 됩니다(MUST NOT). 따라서 클라이언트 요청에 오래된 응답을 반환하도록 구성된 캐시에서도 원본 서버가 캐싱을 방지할 수 있습니다."
이것이 바로 감사 패널에서 캐싱을 사용 설정하도록 권장하는 이유입니다. 캐싱을 사용하지 않으면 서버와 클라이언트가 중복될 수 있는 정보를 전송하게 되기 때문입니다.
감사 제안의 근본 원인을 확인했으므로 이제 어떻게 해결해야 하나요? 이 경우 솔루션에는 서버 측 구성 또는 코드가 포함됩니다. 설정에 따라 웹 서버 구성 또는 웹 앱 프레임워크의 구성을 통해 캐싱을 사용 설정할 수 있습니다. 특히 캐시하고자 하는 모든 리소스에 대해 max-age 매개변수와 함께 Expires 헤더와 Cache-Control: private을 포함해야 합니다.
제안은 곧 여기에 있습니다.
감사 패널은 일반 휴리스틱을 기반으로 개선사항을 권장한다는 점을 기억하세요. 여러 해 동안 축적된 권장사항을 특정 웹 앱에 적용하고 있습니다. 대부분의 경우 이러한 권장사항은 확연히 드러나며 이를 반영해야 합니다.
권장사항이 정확할 수 있지만 실제로 개선으로 이어지지 않을 수도 있습니다. 예를 들어 페이지에 큰 이미지가 하나뿐인 경우 '감사' 패널은 <img> 태그에 너비와 높이 속성을 추가하도록 권장합니다. 이렇게 하면 렌더링 엔진이 이미지를 다운로드하고 검사할 필요 없이 이미지 크기를 알 수 있습니다. 이 방법은 일반적으로 좋은 방법이지만 이미지가 페이지의 유일한 요소인 경우에는 별다른 도움이 되지 않습니다.
이러한 제안사항을 이해한 후 적용하는 것을 잊지 마세요. 또한 변경 전후의 실적을 측정하여 실제로 개선이 이루어지도록 하는 것도 잊지 마세요.
요약
감사 패널은 웹 앱의 성능을 최적화하는 방법을 빠르게 보여주는 훌륭하고 사용하기 쉬운 도구입니다. 많은 기업이 성능과 수익 또는 활동 간에 직접적인 상관관계가 있음을 발견했기 때문에 속도는 웹 앱의 중요한 속성입니다. 앱 성능을 최적화하는 것은 사용자뿐 아니라 비즈니스 수익을 높이는 일이기도 합니다.