SPA 구조 판별

SPA의 URL 복원과 서버 fallback

SPA는 페이지를 한 번 받은 뒤 클라이언트가 화면 전환을 처리합니다. 하지만 실제 품질은 직접 URL 접근, 새로고침, 뒤로 가기, 서버 fallback, SEO 요구가 모두 맞물릴 때 확인됩니다.

01

전환 주체 구분

링크 클릭 뒤 서버가 새 문서를 주는지, 클라이언트 router가 DOM을 바꾸는지 확인합니다.

navigation
02

URL을 상태 계약으로 둔다

현재 화면이 path와 query만으로 복원되는지 확인해 공유와 새로고침을 보장합니다.

URL
03

서버 fallback 연결

API와 정적 파일을 제외한 route는 SPA 진입점으로 돌려줘야 직접 접근이 깨지지 않습니다.

fallback
04

SEO와 초기 로딩을 평가한다

검색 노출, 메타 태그, 첫 화면 속도가 중요하면 SSR, SSG, hybrid 구성을 함께 봅니다.

rendering
SPA
상호작용 많은 앱에 유리 초기 번들 비용과 클라이언트 상태 복원이 품질을 좌우합니다.
client
MPA
문서 중심과 서버 렌더링 기본 흐름에 강함 페이지별 독립성이 높지만 전환마다 문서를 다시 받습니다.
server
Hybrid
페이지 성격별로 렌더링 방식을 섞음 Next 같은 프레임워크는 route 단위로 SSR, SSG, CSR을 조합합니다.
mix

직접 접근 · 뒤로 가기 · 초기 로딩 점검

직접 접근 중첩 route를 주소창에 입력해도 같은 화면과 데이터가 떠야 합니다.
뒤로 가기 브라우저 히스토리가 화면 상태와 어긋나지 않는지 확인합니다.
초기 로딩 빈 root div와 큰 JS 번들만 내려오는 구조가 목표 사용자에게 괜찮은지 봅니다.

SPA 검증 경로

/products/10 직접 접근
뒤로 가기 후 필터 복원
새로고침 후 404 여부
검색 봇이 보는 HTML 확인