API 응답을 캐싱하는 법 + 웹 페이지 캐싱

웹 사이트에서 뒤로가기 했을 때 이미 로드했던 페이지를 다시 로드하는 경험이 많을 것이다.

예를들어, 쇼핑몰에서 검색 결과에 나온 상품을 클릭한 다음, 다시 뒤로 가기 했을 때

재검색되는 경우이다.

이미 로드된 페이지를 다시 로드해야하기 때문에 UX에도 좋지 않지만, 시스템 적으로는 문제가 더 크다.

페이지를 새로 로드함으로써 불필요한 API를 호출하고, 트래픽을 증가시킨다.

비용 문제도 발생할 수 있고, 해당 페이지에서 데이터를 수집하고 있다면 특정 데이터가 과수집되는 문제도 있다.

이를 해결하기 위해 페이지나 API 결과를 캐싱하면 큰 효과를 얻을 수 있다.

- localStorage는 브라우저를 닫아도 데이터가 유지된다.

- sessionStorage는 브라우저나 탭이 닫히면 데이터가 날아간다.

- IndexedDB는 큰 데이터를 저장할 때 사용한다. 비동기적으로 저장가능하며, NoSql이다. 이미지나 비디오도 저장 가능하다. 최대 용량은 브라우저마다 다르나, 약 50mb 전후이다. 오프라인에서도 사용 가능하다.

axios를 사용한다면, 내장 기능으로 인터셉터를 활용할 수 있다. 동일한 요청에 대해, 서버에 전송하지 않고 응답을 반환한다.

어떤 컴포넌트를 keep-alive 태그로 감싸면 컴포넌트를 캐싱할 수 있다.

서버 사이드 렌더링 중에 fetch()를 호출할지 설정할 수 있다. false라면 클라이언트 사이드에서만 fetch가 호출된다.

Vuex를 활용하는 방법도 있다. 원리는 브라우저 스토리지와 같다.

웹 서버(Nginx)를 활용하여 응답 헤더에 캐시 설정을 담을 수 있다.

단, 캐시로 인해 이미지 등 리소스 배포 시 즉시 적용이 안될 수 있으므로, 이런 경우에는 캐시를 무효화해야 한다. 파일명을 달리 하거나, 캐시를 무효화하는 요청을 넣거나, AWS CloudFront를 사용하고 있다면 캐시 무효화를 적용할 수 있다.

Nuxt 서버에서 렌더링된 페이지 자체를 메모리 캐시에 저장하는 방법도 있다.

서버사이드 캐싱이며, API뿐만아니라 페이지 전체가 캐시된다. 즉, 뒤로가기 했을 때 지연없이 바로 로드된다. 성능이 매우 뛰어나지만, 서버 메모리를 사용하므로, 주의해야 한다.

만약 10,000명의 사용자가 동일한 페이지를 요청하는 경우,

첫 번째 사용자가 요청하면 페이지가 렌더링되면서 캐시된다.

이후 9,999명이 동일한 페이지에 접근하면 서버는 캐시된 결과를 응답한다.

-> 만약 사용자별로 개별화된 데이터를 뿌려야 한다면, 이 방식은 좋지 않다.

+ cache는 내부적으로는 lru-cache 패키지를 사용한다.

* lru : 가장 오랫동안 사용되지 않은 데이터를 우선적으로 제거하는 캐싱 알고리즘이다.

해시맵이나 이중 연결리스트 자료구조를 사용해서 키-밸류를 빠르게 찾아낸다. : O(1) 시간복잡도