10 Comments
직접 지표 전후 차이를 보여주시니 더 변화를 체감할 수 있던 것 같아요! ‘점수만 보면 괜찮아 보일 수 있지만’ 이라는 부분을 보고, ‘그렇게 나쁘진 않은데?’라고 생각한게 들킨 것 같아 괜히 찔렸습니다ㅎㅎ
쿼리 파라미터 방식에서 정적으로 바꾸기만 해도 큰 차이가 있다는게 너무 신기하고 새로웠던 것 같아요!! 그 원리가 뭘까에 대해 궁금해지는 글이었습니다ㅎㅎ
읽어주셔서 감사합니다 ㅎㅎ
?query=처럼 searchParams를 사용하는 경우, Next.js는 URL 파라미터 값이 요청마다 달라질 수 있다고 판단해서 Full Route Cache를 사용 안하고, 매번 SSR 방식으로 페이지를 렌더링하게 됩니다. generateStaticParams()를 통해 가능한 slug 값 목록을 빌드 타임에 Next.js에 알려주면, 해당 경로들은 미리 SSG 되어 정적 HTML로 생성되고 캐시됩니다. 그래서 요청 시 새로 렌더링할 필요 없이 화면에 빠르게 보여줘서 성능을 개선할 수 있습니다!
내용도 정말 좋은데, 가독성이 너무 좋아요
사실 성능 최적화는 프론트엔드 직무에 필수라고 생각하는데, 너무 쉽게 잊고 넘어가네요
성능 점수를 높이기 위해서 라이트하우스를 정말 잘 쓰고 계시네요!
최대한 대화하는 것처럼 글을 작성하려고 고민을 많이 했는데 가독성 좋게 느껴졌다니 다행이네요! 성능최적화는 아무래도 진짜 필요하다고 느낄때 적용해야하지않나 ㅎㅎ 읽어봐주셔서 감사하고 앞으로도 더 좋은 컨텐츠의 내용을 전달하도록 해보겠습니다!
글의 구조가 탄탄해진 느낌이에요
의문이 하나 있다면 정적으로 바꿔서 성능이 늘어났긴 했지만 중요한 이슈는 아직 남아 있는거 같아요
글의 마지막에 써주신 것 처럼 많은 동적 라우팅이 있어야 할 텐데 이게 꼭 코드의 문제가 아닌 서버 환경의 문제와 같은 다른쪽에도 있지 않을까?.생각해봅니다.
탄탄하다고 느껴져서 다행이네요ㅎㅎ 말씀처럼 정적으로 바꾸는 것만으로는 부족한 경우가 발생할 것 같습니다. 동적 라우팅이 많아질수록 캐시 전략이나 CDN 설정 같은 서버 환경 쪽도 같이 고민해봐야겠다는 생각이 들었습니다. 학습하고 정리해서 또 공유 드릴 수 있도록 해볼게요 :) 좋은 관점 제시해주셔서 감사합니다!
마지막에 데이터가 많아질 때 문제를 미리 고민하는 거 좋은 거 같습니다 :)
나중에 그 상황이 오면 한번 적용을 해보고 또 기록해보겠습니다!!!
이전에 성능 최적화와 실제 최적화 방법 등을 공부했지만, 바쁜 업무로 인해 큼지막 한 것만 적용하게 됐는데, 이렇게 단계적으로 적용하시는 과정을 공유해주셔서, 참고도 되고 더욱 성능 최적화를 적용해 봐야겠단 생각이 듭니다.
좋은 글 감사합니다!!
도움이 되었으면 합니다 ㅎㅎ 읽어주셔서 감사해요~
