퇴사, 입사

원래 좋소 탈출기라는 글을 썼다가 지웠다. 이제는 어지간하면 글을 네거티브하게 보단 포지티스하게 쓰고 싶어서였다. 그래서 그런가? 좋은 일만 생기고 몸도 많이 건강해졌다.

하지만 인수인계가 좀 짧았던지라 계속 후속지원을 해주고 있는데 유독 페이지 로딩이 오래걸리는 부분이 발견되었다.

getServersideProps

Next.js 는 SSR 을 위해서 몇가지 나름의 생명주기? 메소드?들이 존재한다. 그중에 getServersideProps 의 경우는 100% SSR 이 돌아가고 무조건 서버에서만 실행된다. 여기서 무조건 서버에서만 돌아간다는게 당연하겠지만서도 저런 표현을 쓴 이유는 가장 많이 비교되는 것이 9.3 이전 버전에서 사용되던 getInitialProps 와의 차이이기 때문이다. getInitialProps 는 서버도, 브라우저에서도 다 돌아간다.

관성에 젖은 코드

난 운좋게 Next.js 를 꽤 일찍부터 접했었다. 그래서 getInitialProps 를 밥먹듯이 사용했고 잘 쓰고 있었다. (물론 내가 쓴 방식이 Next.js 의 ASO 를 안되게 하는 그런 코드였지만 말이다...) 그래서 그렇게 쓰던대로 getServersideProps 도 쓰게 되었다.

느리다

서비스의 메인페이지에서는 4개의 api 호출이 있고 그걸 기반으로 첫화면을 그린다. 굳이 SSR 을 할 필요가 없는 페이지다. 하지만 검색은 되어야한다. 그리고 거기서 생성된 컨텐츠들의 경우는 [id].tsx 처럼 그때그때 api 를 불러야 하는 페이지들이라 SSR 을 돌릴 수 밖에 없다.

하지만 [id].tsx 에 들어가고 계속 돌아다닐 때는 그렇게까지 느리다고 생각을 못했지만 다시 뒤로가기로 메인페이지에 나올때는 미친듯이 느리다.

TTFB

결국 느린 이유는 TTFB 때문이었고 내가 싼 똥을 남은 사람들이 치우고 있었다. 뭔고 하니 getServersideProps 의 내용이 캐싱되지 않고 매번 그때그때 호출해서 데이터를 받아서 그리고 있기 때문에 느린 것이다. (그것도 api를 4개씩이나..) 이걸 해결하는 방법은 의외로 간단하다. getStaticProps 를 쓰면 되는 것이다. 물론 [id].tsx 처럼 동적 렌더링을 해야하는 곳에서는 안되겠지만 메인페이지 같이 검색은 되어야 하는데 빠른 접근이 필요한 곳에 사용하기 괜찮아 보인다.

getStaticProps

근데 이걸 그냥 써도 되는지가 관건이다. 왜냐면 이건 빌드타임 때 데이터를 만들어서 진짜 싹 만들어서 갖고 있기 때문에 업데이트 되는 자료들의 확인방법이 없어진다. 근데 이걸 사용할 수 있는 곳에 사용해보면 정말 미친듯이 빠르다 라는 것을 경험할 수 있다.

결론

내가 싸놓은 똥이 결정적으로 느렸던 이유는 바로 4개의 api 를 호출하는데 병렬로 안해놓고 직렬로 순차처리를 하게끔 해놓았던 것이 제일 컸다. 어느정도였냐면 뒤로가기로 메인페이지로 빠져나갈 때 보면 거의 뭐 브라우저가 죽은게 아닐까 싶을 정도로 프리징이 심했었다.

Promise.all 을 사용해서 병렬로 api 호출을 시킨결과 수치상으로는 만족스럽지 못하지만 그래도 흔히 우리가 웹브라우저를 통해서 웹사이트를 쓸 때의 경험과 비슷한 수준의 속도는 나오게 되었다.

꺼진 불도 다시 보듯이 짜놓은 코드는 항상 다시보자.