What's in my b̶a̶g̶ Browser

📌 웹 사이트가 빨라야 하는 이유

---

는 굳이 구구절절 말로 설명할 필요가 없을 정도로 명확하다. 화면에 로딩 아이콘이 빙글빙글 회전하는 것을 구경하는 취미가 있는 사람은 아마 없을 것이다. 때문에 웹 개발자들은 사용자 경험 개선과 전환율 증가를 위해 성능 향상에 많은 노력을 기울인다.

 

📌 HTTP Caching

---

캐시(not 현금)란

캐시는 프랑스어 단어 "Cacher"에서 유래되었다. "Cacher"는 감추다 또는 숨기다라는 의미를 가진다. 

 

캐시는 데이터를 일시적으로 숨기거나 보관하는 개념에서 유래하여, 데이터를 빠르게 접근할 수 있도록 숨겨놓은 임시 저장소를 가리키는 용어로 사용되고 있다. 캐시는 자주 사용되는 데이터나 자원을 임시로 저장해 두어, 동일한 데이터나 자원에 대한 요청이 있을 때 바르게 응답할 수 있도록 돕는다. 캐시를 이용하면 데이터 접근 속도를 향상, 서버의 부하를 줄이며, 네트워크 대역폭을 절약할 수 있다.

 

HTTP 캐싱

HTTP 캐싱은 웹 자원의 성능을 최적화하기 위한 기술로, 기본적으로 서버의 응답을 클라이언트 또는 중간 캐시 서버에 저장하고 동일한 요청이 들어올 때 저장된 응답을 재사용하는 방식이다. 이를 통해 서버의 부하를 줄이고 페이지 로딩 속도를 개선할 수 있다.

 

Private Caches

Private cache는 특정 클라이언트와 연결된 캐시로, 대표적인 예시는 브라우저 캐시가 있다. 다른 클라이언트와 공유되지 않는 응답이므로, 사용자 맞춤형 설정이 반영된 페이지 콘텐츠를 저장하기에도 유용하다. 응답 헤더에 다음과 같은 설정을 통해 private cache를 활성화할 수 있다.

Cache-Control: private

Shared Cache

Shared cache는 클라이언트와 서버 사이에 위치하여, 여러 클라이언트 간에 응답을 공유할 수 있는 캐시이다. 이 방식은 네트워크 트래픽을 줄이고, 서버 부하를 감소시킨다는 장점이 있으며, ISP 캐시, CDN 등이 이에 해당한다.

 

 

앞선 설명에 따라, Private Cache는 브라우저에 저장되고, Shared Cache는 프록시나 CDN, 리버스 프록시 등에 캐시되어 있는 것을 확인할 수 있다.

 

 

📌 Heuristic caching

---

HTTP 캐싱은 Cache-Control 헤더 명시를 통해 지정할 수 있는데, 이 헤더가 명시되지 않은 경우에도 자원을 캐시하고 재사용하기 위한 방법이 바로 휴리스틱 캐싱이다. 휴리스틱 캐싱은 캐시 만료 시간을 명시적으로 설정하지 않은 자원에 대해서도 일정 기간 동안 자동으로 캐시를 적용한다.

 

휴리스틱 캐싱의 동작 원리

1. 응답 저장: HTTP 응답이 Cache-Control 헤더 없이 반환된 경우, 응답의 Last-Modified 헤더와 같은 정보를 바탕으로, 캐시가 적용될 수 있는지 판단한다.
2. 자동 만료 기간 설정: 응답의 업데이트 날짜가 오래된 경우, 응답이 일정 기간 동안 유효할 것으로 추정하고, 적정한 만료 기간(일반적으로, 응답 저장 시점에서부터의 시간의 약 10% 정도)을 설정한다.
3. 캐시 재사용: 클라이언트는 지정된 만료 기간 동안 저장된 응답을 재사용하고, 만료된 경우에는 서버에 응답을 요청한다.

 

예를 들어, 웹 브라우저가 서버로부터 위와 같은 응답을 받았다면, Last-Modified 헤더가 3년 전 날짜를 나타내기에 캐시된 응답이 상당 기간 동안 유효하다고 추정하여 재사용한다.

 

📌 유행에 뒤처지지 않는 클라이언트가 되는 법

---

If-Modified-Since

클라이언트가 마지막으로 응답을 받은 시점을 서버에 전달하여, 그 시점 이후에 리소스가 수정되었는지 확인하는 방식이다.

 

1. 클라이언트는 서버로부터 받은 응답을 저장

2. 응답이 1시간(Cache-Control의 max-age가 1시간)을 넘으면 stale 상태가 되며, 클라이언트는 변경 사항을 확인하기 위해 다음과 같은 요청을 전송

3. 서버는 콘텐츠가 변경되지 않았다면 304 Not Modified 상태 코드로 응답하고, 변경 사항이 있다면 200 OK와 함께 최신 콘텐츠를 응답으로 반환

ETag/If-None-Match

서버는 응답 본문에 대한 해시값 또는 버전 번호 등으로 ETag에 대한 값을 생성할 수 있다. 클라이언트는 이 값을 사용하여 서버에 리소스 수정 여부를 확인하는 방식이다. Last-Modified 헤더를 사용하는 경우 날짜 형식은 복잡하고 파싱하기 어렵고, 분산 서버 환경에서는 파일 수정 시간을 동기화하기 어려운 문제들을 해결해 준다.

 

1. 서버로부터 ETag 헤더가 포함된 응답을 받는다.

 

2. 클라이언트는 이 응답이 stale 상태가 되면, 저장된 ETag 값을 If-None-Match 헤더에 포함하여 서버에게 요청을 보낸다.

3. 서버는 If-None-Match 값과 서버에 저장된 리소스의 ETag 값을 비교한다. Last-Modified 헤더를 사용하는 경우와 마찬가지로, 콘텐츠에 변경 사항이 없다면 304를, 변경 사항이 있다면 200을 응답한다.

 

Cache Busting

캐시 버스팅은 웹 리소스의 변경을 브라우저 캐시와 서버 캐시에서 인식할 수 있도록 URL을 변경하는 기법이다. 이 방법은 자원이 업데이트될 때마다 클라이언트가 최신 버전을 받을 수 있도록 보장한다.

 

자원의 URL에 버전 번호나 해시값을 포함시켜 URL이 바뀔 때마다 새로운 자원이 로드되도록 강제하여, 애플리케이션의 UI가 깨지는 등의 버그 발생을 예방한다.

 

Cache Busting 방법

1. 버전 번호 혹은 해시값을 파일명에 포함시키기

   ex) bundle.v123.js, build.v123.css

2. 쿼리 문자열에 버전 혹은 해시값을 추가하기

   ex) bundle.js?v=123, build.css?v=123

 

WebMvcConfigurer Cache Busting 설정

@Configuration
public class CacheBustingWebConfig implements WebMvcConfigurer {

    @Override
    public void addResourceHandlers(final ResourceHandlerRegistry registry) {
        registry.addResourceHandler(PREFIX_STATIC_RESOURCES + "/" + version.getVersion() + "/**")
                .addResourceLocations("classpath:/static/")
                .setCacheControl(CacheControl.maxAge(Duration.ofDays(365)).cachePublic());
    }
}

 

위와 같이 설정하여 정적 자원에 대한 Cache Busting을 추가할 수 있다.

 

📌 결론

---

수업을 열심히 들읍시다... 🥲

 

 

 

참고자료

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#validation