기존 asp net core와 Blazor의 차이를 알아보고 싶어서, asp net core MVC와 Blazor WebAssembly 프로젝트를 각각 생성하여 만져보고 있습니다.
그런데, Blazor로 띄운 사이트에서는 새로고침을 할 때 마다 loading을 띄우며 1초 정도 딜레이가 걸리더군요. asp net core로 띄운 사이트는 바로바로 새로고침이 되는데…
어떤 특징이 이런 차이를 만드는 걸까요?
1개의 좋아요
WebAssembly를 이용하면 .NET 앱을 dll 형태로 서버에서 내려받아 웹브라우저에서 실행하게 됩니다. 그러니까 관련된 로딩 시간이 꽤 걸리는 것이죠.
WebAssembly로 검색을 해보시면 rust등의 언어로 만든 재미난 샘플들을 접하실 수 있습니다. 마치 일반 앱 처럼 동작하는데 WebAssembly로 웹브라우저 안에서 실행할 수 있기 때문입니다.
1개의 좋아요
초기 시작 시에 딜레이가 걸리는 건 이해가 가는데… 새로 고침 할 때마다 dll을 새로 불러와야 하나요?
1개의 좋아요
최초 접속시 dll을 다운로드 받고
이후에는 다운로드된 dll을 사용하게 됩니다.
따라서 최소 접속시 다운로드에 약 1초 또는 이상의 딜레이가 발생하며(로딩시간 포함)
이후에는 다운로드된 wasm 로딩시간이 되겠습니다.
만약, 초기 구동 시간이 개발 시나리오와 맞지 않다면 Blazor Server, Blazor WebApp을 고려하셔야 합니다.
2개의 좋아요
최초 접속 시 로딩 시간이 느린건 감안해야 겠지만, f5 눌러서 새로 고침 했을 때 로딩 시간조차도 asp.net core 서버 보다 체감이 될 정도로 느린 건 어째서일까요?
1개의 좋아요
아마 새로 관련 파일들을 받아오는 과정이 새로고침시에도 하는게 아닌가 싶은데 웹이 아니라 브라우저에 설치하는 앱이라고 생각하시면 편할듯 합니다. 일반적으로 부르는 앱도 종료 후 실행시는 항상 로딩과정이 있지만 실행 후에는 특정 동작을 수행할 때 백에서 데이터만 받아와서 해당 영역만 새로 그려주듯이 Blazor WASM도 그런식으로 동작합니다. 특별한 경우(개발 중 캐시문제로 force refresh를 한다던가…)를 제외하곤 새로고침을 할 일이 없어서 일반 새로고침 시에도 딜레이가 있다는건 몰랐네영…
근데 디버깅 환경이 아니라 실제 배포 후에도 딜레이가 불편할 정도로 있으신가요? 디버깅 환경에선 구조상 충분히 그럴 수 있다고 생각하는데…
1개의 좋아요
asp.net core 서버가 의미하는 바가 MVC라면 MVC는 서버 랜더링이므로 wasm 처럼 초기 구동에 필요한 runtime 등을 요구하지 않습니다.
따라서, wasm(blazor spa)은 브라우저에서 프로젝트 dll구동을 위한 별도의 runtime dll이 포함됩니다.
이에 따라 wasm은 매번 브라우저에서 dll을 구동하기 위한 일련의 해석 절차를 거치게 되므로 기본적으로 mvc보다 느리게 됩니다.
mvc의 경우 html, js는 브라우저 생태계의 기본이므로 별도의 구동을 위한 해석 절차를 거치지 않으므로 빠르게 동작할 수 있습니다.
2개의 좋아요
.NET 8의 Blazor에서는 정적 SSR(static server-side rendering)을 지원하는데 ASP.NET Core MVC와 유사하게 Blazor가 동작하지만 향상된 탐색 기능 및 양식 처리를 통해 마치 SPA(Single Page Application)과 유사한 동작성을 제공할 수 있습니다. 서버에 지속적으로 연결되어야 하는 Blazor Server나 웹브라우저에서 Blazor 앱이 실행되는 Blazor Webassembly가 맞지 않는다면 정적 SSR 모드를 살펴볼 만 합니다.
1개의 좋아요
프로젝트 폴더에 dotnet.wasm 파일 용량이 2.3m네요. 이거 다 로드하려면 초기 구동 시간이 길어질 만 하네요… 다만 이미 로드된 파일을 분명 캐싱을 할 것 같은데, 왜 asp.net core MVC와 새로 고침 시 딜레잉이 유의미 하게 차이가 나는지 모르겠네요. 캐싱 됐다는 전제 하에는 오히려 webAssembly가 더 빨라야 할 것 같은데…
Release 환경에서 디버깅 환경보다 딜레잉이 훨씬 빠르긴 한데, 그래도 MVC 보다는 느린게 느껴집니다
캐싱 됐다는 전제부터 살펴 보는 게 좋을 것 같습니다.
브라우저의 페이지 리프레시는 블레이저와 상관없이 사용자가 (강제로) 브라우저 네비게이션을 유발하는 것입니다.
이때, 브라우저의 캐싱 행태는 서버의 응답 포함된 캐싱 해더에 대응하는 것 뿐입니다.
즉 블레이저 와즘 설정의 영역이 아니라 블레이저 와즘을 서빙하는 서버 설정의 영역입니다. .
참고로, 블레이저 와즘의 페이지 간 이동이 항상 브라우저의 네비게이션으로 이어지는 것은 아닙니다.
블레이저 와즘의 네비게이션은 네비게이션 요청을 후킹하여, 자신이 가진 Route 정보에 포함되어 있으면, 브라우저에 넘기지 않고 자체적으로 처리하고(<Router> 요소가 하는 일), 없으면 브라우저에 넘깁니다.
그런데, 리프레시 문제를 서버의 캐싱 해더를 변경하는 것으로 해결하는 것은 좋은 선택이 아닐 수 있습니다.
왜냐하면, SPA 포함 웹앱 개발 시, 브라우저 캐싱과 관련한 질문의 대부분은 "왜 업데이트가 안 되냐?"입니다. 즉, 이 질문의 의도와 정반대로, 캐싱을 바이패스하고 싶어하는 경우가 많은 것이죠.