웹 성능 최적화 SSR + Cache 적용기

사용자에게 속도(Speed)는 얼마나 중요할까요?

구글 자료를 보면, 대부분의 사용자는 속도(Speed)가 UX 계층 최상위에 있다고 평가합니다. 이 결과가 당연한 이유는, 페이지가 보여야 기능을 수행할 수 있고, 페이지가 보여야 아름다운지 판단할 수 있습니다.

https://developers.google.com/web/updates/2018/08/web-performance-made-easy

사용자 UX 계층

  • 75%: 페이지를 로드 하는 데 걸리는 속도
  • 66%: 내가 찾고자 하는것을 찾는게 쉬운지
  • 61%: 사이트가 내 화면에 잘 맞는지
  • 58%: 사이트 사용이 간단한지
  • 24%: 사이트가 얼마나 매력적인지

💰속도가 빨라지면 매출이 늘어난다?

웹 로딩 속도 1초에 아마존 매출 68억 달러가 달려있다.

https://zdnet.co.kr/view/?no=20190418142445

(2019년 기준) 아마존 웹 로딩 속도 1초 빨라지면 판매량이 1% 증가한다고 합니다. 한화로 7조 7천억 원…!! 역대 최고 실적 낸 작년(20년) 기준을 적용하면 10조는 훌쩍 넘을 것입니다.

📈속도가 빨라지면 전환율도 Up Up

느린사이트는 전환율을 죽입니다.

원티드에는 다양한 전환율 존재 합니다.
가입률, 지원율, 합격률, 결제율 등등..
위에는 가장 대표적인 것이고, funnel 별 세분화된 전환율을 주기적으로 트래킹 및 관리하고 있습니다.

https://www.cloudflare.com/learning/performance/more/website-performance-conversion-rates/

위 표를 보면 2.4초 안에 페이지 로드가 되었을 때 전환율 1.9%로 가장 높았고, 4초 넘으면 전환율이 1% 미만으로 내려오게 됩니다.

  • 2.4 초 만에로드 된 페이지의 전환율은 1.9 %
  • 3.3 초에서 전환율은 1.5 %
  • 4.2 초에서 전환율은 1 % 미만
  • 5.7 초 이상에서 전환율은 0.6 %

다른 연구 결과를 보면,
47% 사용자는 2초 이내에 로드가 완료되길 기대하고,
40%는 3초 이상 걸리는 페이지를 포기합니다. 사이트가 열리는데 3초 이상 걸리면 사이트에 도착하기도 전에 절반의 사용자를 잃게 됩니다.

https://www.crazyegg.com/blog/speed-up-your-website/

(속도가 느리면) SEO가 죽는다

Google은 사이트 순위를 지정할 때 속도를 고려합니다. 속도는 사용자가 처음에 우리 서비스를 얼마나 쉽게 찾을 수 있는지에 영향을 미칠 수 있습니다.

2020년 5월 28일 Google은 검색엔진 순위 알고리즘을 발표. 이를 페이지 경험 업데이트 라고 합니다. 속도(Speed)가 중요한 요소로 자리매김 하였습니다.

Google은 오늘(2020년5월28일) 사용자가 웹 페이지와 상호 작용하는 경험을 어떻게 인식하는지에 따라 웹 페이지를 판단하도록 설계된 새로운 순위 알고리즘을 발표 했습니다. 즉, Google이 귀하의 웹 사이트 사용자가 귀하의 페이지에서 열악한 경험을 할 것이라고 생각한다면 (핵심 웹 가치라고하는 새로운 측정 항목으로 측정) Google은 해당 페이지의 순위를 지금처럼 높게 평가하지 않을 수 있습니다. 이 업데이트를 Google 페이지 경험 업데이트라고하며 2021 년에 출시 될 예정이므로 준비 할 시간이 충분합니다.

페이지 경험이란 무엇입니까? Google에는 페이지 경험 기준 에 대한 자세한 개발자 문서가 있지만 간단히 말해서 이러한 측정 항목은 사용자가 특정 웹 페이지의 경험을 인식하는 방식을 이해하는 것을 목표로합니다. 페이지가 빠르게로드되는지 여부와 같은 고려 사항 (예 : 모바일 친화적 인 경우 실행 여부) HTTPS, 방해가되는 광고의 존재 및 페이지가로드 될 때 콘텐츠가 점프하는 경우.

출처: https://searchengineland.com/the-google-page-experience-update-user-experience-to-become-a-google-ranking-factor-335252

페이지 속도가 빨라지면 좋은 점이 아주 많습니다.
0.01초 빨라지는 것도 의미 있는 작업이며, 이런 작업들이 계속해서 쌓였을 때 서비스 속도가 점진적으로 개선되게 됩니다.

이제 본론으로 원티드 프론트엔드팀이 웹페이지 속도개선을 위해 시도하고 있는 일을 소개하도록 하겠습니다.

원티드 웹은 Next.js를 사용하고 있어요.

Next.js를 사용하는 가장 큰 목적은 간편하게 SSR(Server Side Rendering) 사용할 수 있기 때문이라고 생각합니다.

SSR 장점

  1. SEO
  2. 빠른 첫페이지 로딩

SSR 단점

  1. CSR에 비해 더 많은 서버 자원 소비
  2. 코딩 복잡도 증가

장/단점이 있으나, Next.js를 사용하고 있으니 SSR 활용하여 속도를 끌어 올리면 좋겠다는 생각이 들었습니다.

원티드웹 SSR 현황은?

head, GNB, Footer 3가지 영역이 SSR로 되어 있고 (노랑색표시)
컨텐츠 영역은 CSR으로 구현이 되어 있습니다.

원티드 웹 SSR 현황

컨텐츠영역을 SSR로 전환하고, Cache 연동하여 성능이 얼마나 개선 되는지 살펴보겠습니다.

아직 Live에 배포하지 않아서 개발환경에서 테스트를 진행 하였고,
모바일 환경과 비슷한 조건을 만들기 위해, 측정횟수 10번중 5번은 Network를 Fast 3G로 테스트 하였습니다.

측정방법

  • 대상페이지: `/salary` (직군별 연봉 페이지)
  • Chrome 시크릿탭
  • 크롬 개발자도구 Lighthouse (설정은 아래스샷 )
  • 성능측정 횟수 총10번 (network online 5번 / network Fast 3G 5번)

현재 CSR 성능은? 46점

테스트 평균 점수는 46점 입니다.
전반적인 수치들이 좋지 못합니다.

CSR Lighthouse 점수

컨텐츠 영역을 SSR로 전환해보면?

컨텐츠 전체를 SSR로 변경하기 보다, 사용자가 처음 스크린에 보이는 부분만 SSR 처리하는 것이 더 효율적입니다.
또한, 이부분이 LCP (Largest Contentful Paint) 메트릭으로 중요한 성능 지표로 사용됩니다.

LCP 란 무엇입니까?
LCP (Largest Contentful Paint) 메트릭 은 뷰포트에서 볼 수 있는 가장 큰 이미지 또는 텍스트 블록 의 렌더링 시간을보고합니다 .

https://web.dev/lcp/

TO-BE 같이 변경해 보겠습니다.

https://www.wanted.co.kr/salary

진행하다보니, 사전작업으로 아래와 같은 처리가 필요했습니다. (세상엔 공짜가 없었습니다.)

  • 인증로직 server에서 처리
  • server, client 환경 모두 호출할 수 있는 axios 처리

위 처리가 끝나고, 본격적으로 API 호출로직을 `getInitialProps` 로 이동하였습니다.

Salary.getInitialProps = async function(ctx) {
try {
const { data: salaryData} = api.getSalary();
return {
salaryData
}
} catch(error) { // error handle
}
}

SSR 적용확인

크롬 개발자도구 Network -> Doc -> `/salary` 내용을 보면 차트 관련 데이터가(빨간색 표시) 같이 내려오는 것으로 보아 잘 적용되었습니다.

SSR 평균성능 59점

CSR -> SSR 변경시 총점은 (CSR 대비) 13점 높아졌고
LCP 성능은 1초 빨라졌습니다.

SSR의 장점인 빠른 첫페이지 랜더링이 잘 동작합니다.

SSR + Cache 적용해 보면 어떻게 될까?

첫 요청 때 SSR 결괏값을 cache에 저장하고, 같은 요청이 오면 cache에서 결괏값을 내려주는 방식입니다. 이를 적용 시 프론트 서버와 API 서버 양쪽 모두 부하를 줄일 수 있고, 속도도 빨라지게 됩니다.

유의사항으로는 frontend, API 서버 양쪽에서 cache를 사용하게 되면 데이터 정합성 이슈가 발생할수 있습니다. 전반적인 cache layer 잘 알고 있어야 디버깅 시 애를 안 먹습니다. 또한, 예외 발생시 cache 처리가 안되도록 주의해야 합니다.

자세한 구현방법은 아래 링크를 참고해주세요.

Cache 적용확인

response 해더에 아래 2개 해더가 추가 되었습니다.

// cache HIT는 안되었지만, 새로운 cache가 생성됨x-cache-expired-at: 4m59.9s // cache 만료시간x-cache-status: MISS // cache HIT 여부
SSR cache 적용 해더

cache에 HIT 되면 `x-cache-status: HIT` 로 내려옵니다.

SSR cache가 되었을때

SSR+Cache 평균성능 76점

전반적인 성능지표가 준수하게 올라갔습니다.

  • SSR 대비: 점수 17점 증가 / LCP 2.3초 속도개선
  • CSR 대비: 점수 30점 증가 / LCP 3.3초 속도개선

SSR + Cache 적용시 추가 이득

🏖 ️API 서버에게 휴식을

예를 들어`/test` 페이지에서 3번의 API 호출 발생한다고 가정해 보겠습니다. `/test` 페이지에 10번 요청이 발생했다면, Frontend Server는 API 서버를 30번 호출하게 됩니다.

  • 100번이면 API Server로 300번…
  • 1,000번이면 API Server로 3,000번…
  • 10,000번이면 API Server로 30,000번…
cache 미적용시

cache를 적용하게 되면, cache HIT 된 만큼 서버의 요청을 줄일 수 있게 됩니다. HIT가 일어나지 않으면 속도/성능은 올라갈 수 없습니다.

하여, HIT가 잘 되도록 Cache Key 설정과 인프라 구성이 중요 합니다.

cache 적용시

(중요한건) 히트 다 히트!

출처: MBC 무한도전

마치면서

미비된 작업을 빨리 완료하고 live 배포할 수 있는 날을 기다립니다. 이외에도 프론트엔드팀은 다양한 성능 개선을 진행하고 있습니다.
원티드 사용자의 쾌적한 커리어 여정을 위하여 프론트엔드팀 도전은 계속됩니다.

프론트엔드팀은 채용’ing 입니다.
즐겁게 원티드 웹을 만들어갈 프론트엔드 개발자분들의 지원을 기다립니다.

> 원티드 채용공고 확인하기

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store