$ curl -I <확인할 URL>
위의 명령어를 입력하면 cache-control, etag 지원여부, HTTP 버전등에 관한 정보들을 알 수 있습니다.
cache-control의 max-age가 24시간으로 설정되어 있는 경우 리소스가 변경되었다면 캐싱을 사용하지 않고 etag를 통해 새로 불러와야 합니다.
기존에는 직접 캐시를 제거하고 로드하는 즉, 캐싱을 사용하지 않고 사용했습니다. 그런데 load함수를 호출하기전에 URLRequest의 cachePolicy를 지정하여 자동으로 etag를 검증할 수 있어서 변경하고 확인해봤습니다.
etag란? 리소스가 변경되었을 때 식별할 수 있는 값이고, etag를 요청헤더에 추가할 때 대소문자구분은 하지 않아도 되고 HTTP Status Code가 304인 경우가 리소스변경된 응답코드입니다.
// 기존 수동 삭제
func clearWebViewCache(completion: @escaping () -> Void) {
// 전체 캐시 삭제
URLCache.shared.removeAllCachedResponses()
let websiteDataTypes = Set(arrayLiteral: WKWebsiteDataTypeDiskCache,
WKWebsiteDataTypeOfflineWebApplicationCache,
WKWebsiteDataTypeMemoryCache,
WKWebsiteDataTypeLocalStorage,
WKWebsiteDataTypeFetchCache,
WKWebsiteDataTypeServiceWorkerRegistrations)
let fromDate = Date.init(timeIntervalSince1970: 0)
// 지정된 날짜 이후 지정된 유형의 모든 웹 사이트 데이터를 제거
WKWebsiteDataStore.default().removeData(ofTypes: websiteDataTypes, modifiedSince: fromDate) {
completion()
}
}
// cachePolicy 설정
webView.load(URLRequest(url: url, cachePolicy: .reloadRevalidatingCacheData))
테스트 결과 캐싱을 전혀 사용하지 않았던 방법과 cachePolicy를 지정하여 etag 검증하는 방법과 로드 속도를 확인해본 결과 HTTP요청은 진행하므로 큰 차이가 없었습니다.
정확히 공식문서에도 reloadRevalidatingCacheData가 어떻게 동작하는지 자세히 알 수 없어 테스트 방법이 잘못되었는지 동작방식에서 원래 큰 차이가 없는지는 더 검토해봐야 할 것 같지만 코드라인이 줄어드는 장점은 있었습니다.
앱개발자로서 프론트엔드의 구조와 동작방식을 알게 되면 커뮤니케이션 또는 웹뷰, HTML 파싱 작업등을 진행할 때 도움이 될 것 같아서 HTML, CSS 를 다시 공부하였습니다.
JS를 배우지 않아도 현대적인 프로그래밍언어들이 서로 유사한 문법들을 가지고 있어서 이해하는 부분에서는 큰 난관이 없었습니다.
antonio라는 유튜브채널을 보고 REST API를 expressJS, MongoDB Atlas를 활용하여 만들어보고
NetflixClone을 보고 클론 웹사이트도 제작해봤습니다.