전체 글

Next.js App Router로 성능 최적화를 하다 보면 꼭 비슷한 지점에서 막힙니다. layout.tsx에 preconnect를 넣고, 폰트도 self-hosted로 바꾸고, hero 이미지도 손봤는데 정작 LCP는 생각만큼 줄지 않습니다.이때부터 기준이 흐려집니다. 공통 리소스는 layout에 두는 게 맞는 것 같은데, 페이지마다 다른 hero 이미지는 또 page에서 다뤄야 할 것 같고, 예전엔 priority를 쓰라고 하더니 지금은 preload를 보라는 말도 나옵니다. 문제는 최적화를 안 해서가 아니라, 무엇을 어디에 두어야 하는지 기준이 섞이기 시작했다는 데 있습니다. Next.js App Router에서 layout은 여러 페이지가 공유하는 UI이고, 최신 Image 문서에서는 prior..

Next.js App Router로 작업하다 보면 캐시가 한 번씩 정말 헷갈립니다.어떤 데이터는 매 요청마다 새로 가져오는 것 같고, 어떤 데이터는 한동안 유지되다가 다시 갱신되는 것 같고, 또 어떤 데이터는 별다른 옵션을 안 줬는데도 기대와 다르게 움직입니다.특히 공통 fetch 래퍼를 만들어 둔 프로젝트라면 더 그렇습니다.호출부에서는 단순해 보이는데, 내부적으로는 credentials, headers, 기본 옵션 같은 설정이 숨어 있을 수 있기 때문입니다.게다가 Next.js App Router의 fetch는 단순 네트워크 요청이 아니라, 캐시와 재검증 의미까지 함께 가지도록 확장되어 있습니다.이걸 이해할 때 가장 좋은 기준은 명령 → 동적 전환 조건 → 자동 추론 순서로 보는 것입니다.즉, 먼저 개..

Supabase 개요: PostgreSQL 기반 BaaS를 이해하는 가장 현실적인 방법백엔드를 빨리 만들고 싶은데, 그렇다고 데이터 구조를 너무 단순하게 가져가고 싶지는 않을 때가 있습니다. Firebase처럼 빠르게 붙이고 싶지만 NoSQL이 낯설거나, SQL을 그대로 쓰고 싶은 마음이 들 때도 있죠. 이럴 때 자주 등장하는 이름이 바로 Supabase입니다.처음 보면 “오픈소스 Firebase 대안” 정도로 소개되는데, 사실 이 한 줄로는 많이 부족합니다. Supabase는 단순히 비슷한 서비스를 흉내 낸 제품이 아니라, PostgreSQL을 중심으로 인증, 스토리지, 실시간 기능, 서버리스 함수까지 하나의 플랫폼으로 묶어놓은 서비스에 가깝습니다.쉽게 비유하면 이렇습니다. 직접 백엔드 집을 짓는 대신..

React로 화면을 만들다 보면 처음에는 props만으로도 충분합니다.부모가 자식에게 값을 넘기고, 필요한 곳에서 받아 쓰면 되기 때문입니다.그런데 컴포넌트가 많아지고 화면이 깊어질수록, 상태를 “어디에 둘지”보다 “어떻게 전달할지”가 더 큰 문제가 되기 시작합니다. React 공식 문서도 이런 상황에서 Context와 reducer를 함께 써서 깊은 트리의 상태 전달을 줄일 수 있다고 설명합니다.전역 상태관리의 출발점은 props drilling을 줄이고 싶은 순간이다.하지만 모든 상태를 전역으로 뺄 필요는 없다.비교할 때는 “누가 더 유명한가”보다 어떤 상태를 다루는가가 더 중요하다.Redux는 지금 기준에서 Redux Toolkit으로 보는 편이 맞다.Zustand는 작고 빠르고 hook 기반인 s..

페이지가 늦게 뜨면 사용자는 생각보다 빨리 이탈합니다.실제로 자주 인용되는 Google 자료에서는 모바일 페이지가 3초를 넘기면 절반이 넘는 사용자가 떠날 수 있다고 설명합니다. 다만 이 수치는 오래된 모바일 웹 조사이기 때문에, 절대적인 규칙이라기보다 속도가 이탈에 큰 영향을 준다는 방향성으로 보는 편이 정확합니다.이 지점에서 자주 나오는 최적화 방법이 바로 Code Splitting입니다.이름은 거창해 보이지만 핵심은 단순합니다. 처음부터 모든 코드를 한꺼번에 보내지 말고, 필요한 코드만 먼저 보내자는 방식입니다. 웹 성능 가이드도 JavaScript를 여러 청크로 나누면 초기 로드 성능과 상호작용 시점을 개선할 수 있다고 설명합니다.Code Splitting은 큰 번들을 작은 조각으로 나누는 방식이..

이미지를 화면에 보여주는 것 자체는 어렵지 않습니다. 그래서 처음에는 그냥 img 태그만 써도 충분해 보입니다. 그런데 실제 서비스에서는 이야기가 달라집니다. 이미지가 많아질수록 로딩 속도, 레이아웃 시프트, 반응형 대응, 그리고 LCP 같은 핵심 지표가 한꺼번에 얽히기 시작합니다. 문제는 이미지를 “보이게 하는 것”이 아니라, “빠르고 안정적으로 보여주는 것”에 있습니다. Next.js의 가 자주 언급되는 이유도 바로 여기에 있습니다.next/image는 단순한 이미지 태그가 아니라, 최적화와 안정성을 함께 고려한 컴포넌트다.핵심 차이는 크기 최적화, lazy loading, layout shift 방지, 반응형 이미지 처리에 있다.width, height는 단순한 크기 지정이 아니라 브라우저가 미리 ..