• 최적화된 서비스를 Lighthouse를 통해 검사해보자

Lighthouse 검사 결과

Lighthouse 검사 결과

• 결과를 보면 점수가 아주 높게 나옴. 그런데 한 가지 눈에 띄는 부분은 Diagnostics 섹션의 ‘Serve static assets with an efficient cache policy’ 라는 항목임

• 이 항목은 네트워크를 통해 다운로드하는 리소스에 캐시를 적용하라는 의미임. 항목을 클릭해서 펼쳐 보면 거의 모든 리소스에 캐시가 적용되어 있지 않다고 나옴

  

  Lighthouse 검사 결과 중 캐시 관련 항목

• 실제로 Network 패널에서 위 리소스 중 하나를 확인해 보면 응답 헤더에 캐시에 대한 설정인 Cache-Control 이라는 헤더가 없는 것을 알 수 있음. 즉, npm run start로 실행한 서버에는 캐시 설정이 제대로 되어 있지 않은 것임

  

  번들 파일의 응답 헤더

캐시란?

• 캐시는 자주 사용하는 데이터나 값을 미리 복사해 둔 임시 저장 공간 또는 저장하는 동작임
• 웹에서는 서비스에서 사용하는 이미지나 자바스크립트 파일을 매번 네트워크를 통해 불러오지 않고 최초에만 다운로드하여 캐시에 저장해 두고 그 이후 요청 시에는 저장해 둔 파일을 사용함

캐시의 종류

• 웹에서 사용하는 캐시는 크게 두 가지로 구분할 수 있음

  1. 메모리 캐시: 메모리에 저장하는 방식, 여기서 메모리는 RAM을 의미함
  2. 디스크 캐시: 파일 형태로 디스크에 저장하는 방식

• 어떤 캐시를 사용할지는 직접 제어할 수 없음. 브라우저가 사용 빈도나 파일 크기에 따라 특정 알고리즘에 의해 알아서 처리함

• 구글 홈페이지에서 개발자 도구를 열어 Network 패널을 확인해 보면 Size 항목에 memory cache 또는 disk cache라고 표시된 것을 볼 수 있음. 이 리소스들이 브라우저에 캐시된 리소스임

  

  크롬의 Network 패널의 캐시 정보

<aside> 💡 캐시를 확인할 때는 Network 패널의 Disable cache 설정을 꺼야 함

</aside>

• 캐시가 적용된 리소스를 클릭해보자. 응답 헤더를 보면 Cache-Control이라는 헤더가 들어 있는 것을 볼 수 있음. 이 헤더는 서버에서 설정되며, 이를 통해 브라우저는 해당 리소스를 얼마나 캐시할지 판단함

크롬의 네트워크 리소스에서 볼 수 있는 Cache-Control 지시문

<aside> 💡 구글에서 단순 새로고침을 한 후 확인했다면 memory cache가 많을 것임. 왜냐하면 이미 구글의 리소스가 메모리에 캐시되었기 때문임. 브라우저를 완전히 종료한 후 구글에 접속하는 첫 네트워크 리소스를 확인하면 disk cache가 많을 것임. 브라우저가 완전히 종료되면 메모리에 남아있는 내용은 제거하고 다음 접속 때는 파일 형태로 남아 있는 캐시를 활용하기 때문임

</aside>