◆ ESSAY
import {useRouter} from 'next/router'
export default function IndexPage({time}) {
const router = useRouter()
const refreshServerSide = () => {
router.replace(router.asPath)
}
return (
<>
<div>Server Side Props Request Time: {time}</div>
<button onClick={refreshServerSide}>Refresh Server Side</button>
</>
)
}
export async function getServerSideProps(context) {
const currentDateTime = new Date().getTime()
return {
props: {time: currentDateTime},
}
}
getServerSideProps 의 동작을 상상해본다면 아래와 같을 것이다.
https://yceffort.kr/2020/03/nextjs-02-data-fetching#4-getserversideprops
getServerSideProps가 있는 사이트 방문getServerSideProps를 호출하여 HTML 파일 생성그러나 한가지 nextjs에서 getServerSideProps를 클라이언트 사이드에서 처리하는 경우가 있다. 아래와 같은 시나리오를 상상해보자.
Link를 클릭하여 서버사이드 렌더링 된 페이지에 방문getServerSideProps를 서버에 호출하는데, 이전 처럼 HTML파일을 내려주는 대신에 단순히 데이터를 json으로 클라이언트에 전송이 와 같은 과정이 위 예제 코드에서 이루어지고 있다.
최초 페이지 진입시에는 이렇게 완성된 html을 내려준다.
<div id="__next">
<div>Server Side Props Request Time:
<!-- -->1611794984243</div><button>Refresh Server Side</button>
</div>
위 코드로 새로고침하면, 아래와 같은 json데이터만 받는다.
{"pageProps": {"time": 1611795117182}, "__N_SSP": true}
__N_SSP는 server side props이라는 뜻이다. https://github.com/vercel/next.js/blob/e819e00d0c0b2d9cd851c2c7215af1211c561932/packages/next/next-server/lib/constants.ts#L39
nextjs의 좋은 점 중 하나는 getServerSideProps를 일종의 api 호출처럼 사용할 수도 있다는 것이다. 위에서 사용했던 router.asPath는 현재 페이지의 위치를 반환한다. 여기서는 / 일 것이다. 이 페이지로 리다이렉트 시켜달라는 뜻은, 즉 page에 해당 데이터를 json으로 내려달라는 말과 동일하다.그리고 push 대신 replace를 사용하여 히스토리 스택에 쌓이는 것도 방지하였다.
만약 이 경우에 로딩 스피너를 걸어둬야 한다면 어떻게 할까?
const [loading, isLoading] = useState(false)
const refreshServerSide = () => {
router.replace(router.asPath)
isLoading(true)
}
useEffect(() => {
isLoading(false)
}, [time])
useEffect 훅에 서버사이드 props를 넣어주었다.
그리고 이렇게 넘겨 받은 서버사이드 props를 고치고 싶다면, 아래와 같이 처리해주면 된다.
export default function IndexPage({time}) {
const [currentTime, setCurrentTime] = useState(time)
//...
}
블로그 마이그레이션 뒤 수식 글 LCP가 5.6초로 늘어난 원인을 추적했다. 일반 웹 글꼴을 실제 코드에서 제거하고 다시 빌드하자 수식 글 LCP는 5,650ms에서 2,352ms, FCP는 1,514ms에서 758ms로 줄었다. LCP 대상은 본문 문단에서 배너로 바뀌었다. 수식 전용 글꼴은 쓰는 글리프만 남긴 서브셋으로 바꿔 334KiB에서 26KiB가 됐다. 최초 비교 48회, 원인 대조 15회, 수정 전후 24회, 서브셋 전후 8회의 결과를 기록했다.
블로그의 remark/rehype 체인을 Rust로 옮기고 WASM으로 빌드해 Next.js 서버에 붙였다. 파싱과 HAST 생성에 이어 Oniguruma 하이라이트, MathML 수식, 이미지 크기와 MDX 속성 처리까지 한 호출로 묶었다. 메모리 전달과 해제, 기존 글의 호환성, WASI와 바이너리 배포를 구성하며 얻은 것과 감수한 비용을 기록했다.
블로그의 Tailwind 4를 StyleX로 옮겼다. 유틸리티만 옮긴 중간 상태에서는 CSS와 FCP가 줄었지만 전체 전송량은 늘었다. 전환 범위를 넓히자 홈 FCP가 59% 느려졌고, 작성 방식을 고친 뒤에도 격차가 남았다. 마지막 개선은 KaTeX 조건부 로딩과 본문 CSS 분리에서 나왔다. CSS 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.
트래픽을 12배로 올리고 새 파드가 첫 요청을 받기까지 31.5초. 그 31.5초의 내역서를 스톱워치로 뽑았다. 감지 창이 지배하는 구조, 배포 직후 5분 창에서 오토스케일러가 눈을 잃는 조건, 안정화 창의 계단, 메모리 HPA가 Node에서 불발되는 이유, KEDA의 선제 확장까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 다섯 번째 편이다.