크루위키 개선 : 서비스 내 렌더링 전략 수립과 개선 효과

크루위키 서비스를 React에서 Next.js로 마이그레이션 하는만큼 렌더링 전략도 정해보고 싶었다.

단순히 CSR에서 SSR로 변경하는 것이 아니라 적절한 캐시를 설정해서 설정시간 이내에는 캐시된 html을 응답할 수 있도록 하는 것이다. 그렇다면 요청할 때마다 백엔드로 데이터를 요청하지도 않고 미리 만들어둔 정해진 html을 응답만 하면 되니 응답 속도가 더 빨라질 것이라 생각했다.

 

그렇다면 서비스에서 어떤 페이지를 어떤 렌더링 전략으로 가져가는 것이 좋을지 선정해봤다.

 

1. 페이지 별 렌더링 전략

크루위키 서비스는 문서 확인, 편집 로그, 편집 로그 상세, 편집하기, 수정하기 컨텐츠가 있다. 여기서 사용자 상호작용이 들어가지 않는 페이지는 문서 확인, 편집 로그, 편집 로그 상세 페이지이다. 이 세 가지 정적 페이지를 사용자 측면과 크롤러 측면(SEO)을 고려해서 렌더링 전략을 세워봤다.

 

1) 문서 확인

크루위키 사용자들의 방문율이 높은 페이지이다. 크루위키를 처음 실행했을 때 보이는 대문 페이지도 이 페이지 형식이며 각 문서의 최신 상태를 확인할 수 있습니다. 문서 수정이 일어나면 수정된 정보가 바로 적용이 되어야 한다.

 

 

1. 사용자 측면에서

문서 확인 페이지는 사용자들이 가장 많이 사용하는 페이지이다. 그러므로 빠른 응답과 최신성이 보장되어야 한다.
사용자가 페이지를 요청할 때 서버에서 페이지를 제작한 후 보내주는 것보다, 사전 빌드 시점에 미리 만들어둔 html을 요청할 때 응답한다면 더 빠른 응답을 할 수 있을 것 같아 generateStaticParams를 설정하게 됐다.

revalidate 시간은 12시간으로 설정했다. 여기서 revalidate를 길게 가져간다고 했을 때 최신성을 보장하지 못할 수 있지 않을까 하는 우려가 있을 수 있는데 최신성은 문서가 변경됐을 때 on demand revalidate기법을 사용하여(revalidateTag) 서버의 캐시를 무효화하고 그 다음 요청부터 최신화한 html 응답 및 서버 캐시에 저장하게 되어, 최신성을 보장 받을 수 있다.

(브라우저의 캐시가 아니라 서버의 캐시이기 때문에 변경된 다음 요청부터 모두가 최신 응답을 받을 수 있게 된다.)

 

2. 크롤러 입장에서

웹 크롤러 입장에서 크루위키를 검색했을 때 서버에서 html을 만든 뒤에 보여주는 것보다 미리 만들어둔 html을 바로 보이게 한다면 SEO 측면에서 더 좋은 점수를 얻을 수 있으며, 각 문서 별로 다른 메타태그를 설정하여 크롤러에게 더 알맞은 정보를 줄 수 있다고 생각하여 generateStaticParams를 사용하여 빌드 시에 서버에 문서를 만들어뒀다.

 

=> 정리: 문서 확인 페이지는 ISR + generateStaticParams로 서버 빌드 시 페이지 생성, revalidate 12시간

 

2) 편집 로그

크루위키 사용자들의 방문율이 높지 않을 것이라 예상한다. (정확한 수치는 트래킹 코드를 삽입하여 비율을 확인해 볼 예정입니다.) 각 문서의 변경 로그를 확인할 수 있는 페이지이며 문서 수정이 일어나면 새로운 로그가 위에 보이게 된다.

 

1. 사용자 입장에서

문서 편집로그 확인 페이지는 사용자가 그렇게 많이 확인하지 않을 것 같은 페이지이다. 편집로그 버튼을 타고 들어가는 1depth가 있기 때문. (이것도 7기 유치하고 나서 데이터로 확인해보고 싶다.) 그래서 사전 빌드 단계에서 페이지 목록을 가지고 있을 필요가 없다고 생각하여 generateStaticParams를 적용하지 않았다. 또한 이 페이지는 문서 수정 시 새로운 로그가 위에 보여야 하므로 어느 정도의 최신성을 챙겨야 합니다. 그래서 revalidate 시간을 위와 동일하게 12시간으로 설정

 

2. 크롤러 입장에서

굳이 문서 편집로그까지 좋은 평가를 받아야 할 지 모르겠다. 사람들이 문서의 역사에 대해 관심이 많고 이 페이지를 정말 많이 접속한다면 generateStaticParams를 고려해봐도 좋을 것 같다.

 

=> 정리: 문서 편집로그 페이지는 ISR로 revalidate 12시간

 

3) 편집 로그 상세

 

이 페이지 또한 크루위키 사용자들의 방문율이 높지 않을 것이라 예상한다. (정확한 수치는 트래킹 코드를 삽입하여 비율을 확인해 볼 예정입니다.) 각 문서의 특정 로그를 확인할 수 있는 페이지이며, 이 페이지는 새로운 로그가 아닌 이상 절대로 바뀔 수 없다.

 

 

1. 사용자 입장에서

문서 특정 편집로그 확인 페이지는 편집로그 목록보다 더 많이 확인하지 않을 것 같은 페이지이다. 이 페이지에 진입하기 위해서 2depth가 필요하기 때문. 그래서 이 역시 사전 빌드 단계에서 페이지 목록을 가지고 있을 필요가 없다고 생각하여 generateStaticParams를 적용하지 않았다. 또한 이 페이지는 수정될 일이 없고 새로운 로그 페이지가 생성되는 것 이외에 변경될 여지가 없다. 그래서 revalidate 시간을 위와는 다르게 7일로 설정.

 

그렇다면 여기서 내용이 전혀 바뀌지 않으니 SSG를 사용해서 무조건 정적인 응답만 하면 되는 것 아닌가 하는 의문이 들 수 있다. 하지만 저는 사전 빌드 시점에서 정적 파일 생성에 대한 비용을 걱정했다. 지금 현재 문서는 약 130개이며 그 안의 각각 편집 로그가 있어 약 1200개의 데이터가 저장되어있다. 이 데이터를 사전 빌드 할 때 전부 데이터를 불러와서 정적 파일로 만들어두게 된다. 크루위키를 유지보수 하지 않는다면 1200개라도 초기에 불러와서 저장해두는 것이 좋을 것이지만, 유지보수가 이루어지고 주기적으로 코드가 빌드된다면 매 번 빌드 할 때마다 현재 페이지 130개, 로그 페이지 1200개 데이터를 백엔드로 요청하게 된다. 이 이유로 중요하지 않으며, 사용자가 확인할 지도 모르는 페이지를 빌드할 때마다 부담이 되게 하고 싶지 않아서 ISR 방식을 적용했다.

 

2. 크롤러 입장에서

편집로그 목록과 동일하게 문서 특정 편집로그까지 좋은 평가를 받아야 할 지 모르겠다.

 

=> 정리: 문서 특정 편집로그 페이지는 ISR로 revalidate 7일

 

2. 렌더링 전략 수립 후 성능 개선 효과

전략을 세웠다면 개선 결과를 확인해봐야한다. 나는 세 가지 정적 페이지 중 사용자가 가장 많이 확인할 문서 확인 페이지를 검증하기로 했다. 여기서도 두 가지 경우로 나누어 생각했는데 사용자가 처음으로 접속하게 되는 "대문" 페이지, 사진이 많은 "문서" 페이지를 비교해서 성능 개선이 얼마나 이루어졌는지 확인했다.

 

우선 개선 전의 성능 분석부터 진행했다. 성능 분석도구로 LightHouse를 사용했고 성능 지표 중 주목할 것은 로딩 성능과 관련된 FCP와 LCP이다.

 

FCP는 First Contentful Paint로 화면에 처음 요소가 그려지는 시간이고,  LCP는 Largest Contentful Paint로 비중이 큰 요소(중요한 요소)가 화면에 그려지는 시간이다. 둘 다 로딩과 관련된 성능 지표이며 두 지표의 개선이 이루어진다면 로딩 성능을 개선했다는 것을 검증할 수 있다. 

 

1) 개선 전 - 대문 페이지

 

 

성능 점수는 79점으로 문제가 되는 지표는 FCP 1.7s, LCP 2.2s이다. 

 

2) 개선 전 - 사진이 많은 문서

 

성능 점수는 82점으로 문제가 되는 지표는 FCP 1.7s, LCP 2.0s이다. 사진이 많아 성능지표가 안좋게 나오지 않을까 예상했지만 생각보다 그렇지 않았다.

 

3) 개선 후 - 대문 페이지

 

성능 점수는 87점으로 개선 전 79점보다 8점 상승했고 FCP는 1.7s -> 0.3s로 1.4s를 줄일 수 있었다. 그러나 LCP는 예상 외로 2.5s로 나빠졌다. LCP 개선점으로는 대문의 행성이 이미지가 잡혔다. 이 이미지를 불러오는 시간 때문에 LCP가 2.5s로 나온 것으로 예상되고 이 점을 해결한다면 문제를 해결할 수 있지 않을까 생각된다.

대문 문서에서 문제가 되는 이미지

 

 

4) 개선 후 - 사진이 많은 문서

 

성능 점수는 84점으로 개선 전 82점보다 2점 상승했다. 큰 의미가 있다고 생각하지 않는다.

FCP는 1.7s -> 0.3s로 대문과 동일한 성능 개선 효과가 나왔다. 아무래도 렌더링 전략이 동일하기 때문이라고 추측된다.

LCP는 2.9s로 나빠졌다. 이것도 대문 문서와 유사해서 이미지를 최적화한다면 개선되지 않을깨 생각된다.

 

다음 목표는 LCP 최적화를 목표로 개선해보자