Dug_House

어떤 것이 궁금한지 Server Side Rendering(SSR) 페이지에서도 lazy loading이 필요할까? 왜 궁금한지 SSR은 서버에서 HTML을 생성하여 클라이언트로 보내기 때문에 초기 렌더링 속도가 빠를 것 같은데, lazy loading으로 한 번 더 최적화할 필요가 있는지 의문이 생김. lazy loading이란? 최초에 모든 모듈을 가져오지 않고, 필요한 경우에만 클라이언트(브라우저)에서 모듈을 로드하여 네트워크 트래픽을 줄이고 초기 렌더링 속도를 향상시키는 기술. 필요한 상황 페이지 크기 최적화: 서버에서 클라이언트로 전송하는 HTML의 크기를 줄이고, 필요한 리소스만 브라우저에서 로드하여 초기 렌더링 속도를 더욱 향상. ..

사건의 발단상사 : 제품 소개 페이지들을 만들자.나 : 속으로 생각 중 ( 제품 소개 페이지들은 변경될 일이 거의 없으니까 SSG로 만들까? 근데 만약에 관리자 페이지에서 해당 제품 정보를 변경하면 어떡하지…? SSG는 프로젝트를 빌드한 시점에 페이지를 생성해서 변경되지 않잖아…)나 : ISR로 캐싱시간을 10분? 1시간? 하루?를 줘서 페이지를 업데이트해주는 건 어떻게 생각하세요?상사 : 만약에 그 10분, 1시간, 하루 사이에 중요한 정보가 바뀐다면 어떡할래? 책임질 수 있어?나 : 어…그럼 사용자도 거의 없으니까… 그냥 요청마다… SSR하시죠… 캐싱하지 말죠… 하하하 (친구와 한풀이를 하며,,,) 나 : 오늘 이런 일이 있었다,,,친구 : 어 그거 ISR on demand revalidation라고..

글을 작성하게 된 이유현재 하고 있는 프로젝트는 Next.js와 TypeScript를 사용한 프로젝트다. 그러던 와중에 SSR의 개념에 대해서 얘기가 나왔다.팀원 의견 : getserversideprops 를 사용해야 SSR이다. 내 의견 : Next.js 자체로 SSR이 지원되니까 SSR을 하고 있는 것이다.CSR vs SSRCSR과 SSR에 대해서는 해당 POST에 정리해두었다.  넥스트 공식 홈페이지에서 설명https://nextjs.org/docs/basic-features/pagesNext.js는 기본으로는 정적 페이지를 생성해주는 프레임워크이다.SSR은 개발자의 선택사항으로 정하면 된다.hydrationPre-Rendering된 웹 페이지를 클라이언트에게 먼저 보내고, 번들링 된 자바스크립트 ..

문제 상황 Warning: Prop `style` did not match. Server: "null" Client: "min-width:;height:" 원인 Next.js는 SSR을 하기에 서버에서 생성된 컴포넌트와 CSR로 클라이언트에서 생성된 컴포넌트의 클래스명이 서로 달라지게 된다. 게다가 Fullcalendar라이브러리는 SSR을 지원하지 않는다. 해결법 그렇기에 클라이언트에서만 렌더링을 해야한다. Next.js에서 제공하는 dynamic import를 사용한다. export const CalendarPage = () => { const Calendars = dynamic(() => import('./components/Calendar'), { ssr: false, }); return ( );..

CSR : Client Side Rendering 클라이언트 측의 브라우저가 JS파일을 다운로드하고 직접 실행하여 렌더링을 하는 것을 말함 인터넷이 느리거나 사용자가 JS를 비활성한다면 아무것도 나오지 않을 수 있다. 앵귤러, 뷰, 리액트 등 쉽게 말해서 클라이언트 측에서 다하는 것을 말함 서버에서 전체 페이지를 다시 읽어 오고 필요한 부분만 받아오기에 빠른 인터렉션이 가능하다. 문제점 사용자가 첫화면을 보기까지의 시간이 좀 걸린다. 구글 네이버와 같은 검색엔진이 해당 페이지를 빈 페이지로 인식하여 검색엔진이 인식을 못한다. 클라이언트 측에서 사용자의 정보를 쿠키에 저장하기에 보안상의 문제가 발생한다. SSR에서는 서버측에서 세션으로 관리한다. SSR : Server Side Rendering UI를 서..