GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
이 게시물에서는 성능 측면에서 Vue, React 및 Angular를 비교하는 방법과 이러한 프런트엔드 프레임워크에서 실행되는 이커머스 스파를 최적화하여 최상의 사용자 경험을 제공하는 방법에 대해 알아봅니다.
성능 측면에서 Angular, React 및 Vue는 어떻게 비교됩니까?
빠른 사이트를 운영하면 더 나은 SEO 순위, 더 많은 방문자, 더 긴 세션 및 결과적으로 더 많은 수익을 통해 수익을 올릴 수 있습니다. 속도의 역할을 이해하는 많은 이커머스 리더들은 이미 헤드리스 커머스 아키텍처로 전환하여 진보적인 웹 앱과 스파 같은 현대적인 프론트엔드를 채택하고 있습니다. 경량 SPA 프런트엔드는 최신 이커머스 플랫폼에 내재된 다양한 성능 문제를 해결하여 사업자가 번개처럼 빠른 상점을 제공할 수 있도록 보장하는 확실한 방법이기 때문에 인기를 얻고 있습니다.
글쎄요, 그게 이론입니다. 이러한 고상한 주장을 검증하기 위해 우리는 소규모 사내 성과 분석을 수행했습니다. 이를 위해 선도적인 프런트엔드 프레임워크에서 실행되는 약 2,000개의 인기 전자 상거래 웹 사이트를 테스트하고 Lighthouse 6 점수를 기준으로 성능을 평가했습니다. 조사 결과는 놀랍습니다 – 테스트 된 SPA 프론트엔드의 평균 등대 점수는 24 점이며 중간값은 19 (100 점 만점)입니다! 낮게 들리지만, 이는 여전히 매출 기준 미국 500대 인터넷 소매업체의 평균 점수보다 26% 높았다.
Vue.js 사이트가 가장 빠르며 평균 27점, 중간값 20점을 기록했습니다. 각 웹 사이트의 평균은 23이었지만 성능 점수는 중앙값이 18로 더 분산되어 있었습니다. React 웹 사이트는 가장 느린 테스트 였으며 평균 Lighthouse 점수는 22, 중간값은 18 이었습니다. 이것은 놀랍습니다, 프레임 워크는 페이팔, 그래머, 및 Vimeo와 같은 사이트를 포함하여 가장 큰 플레이어의 일부에 의해 사용되기 때문에, 특히.
테스트의 결론은 다소 분명했습니다. 스파는 전통적인 웹 사이트보다 빠르다고 생각되지만 여전히 개선의 여지가 있습니다. 더욱이 Google Crux 및 기타 측정 도구는 단일 페이지 애플리케이션 (SPA)의 페이지 전환을 추적하지 않아 실제보다 훨씬 느린 것으로 오인하고 점수에 불이익을 줍니다. 우리는 블로그에 다른 포스트에 이 문제에 대해 더 많이 썼다.
시작 시간 및 런타임 성능이 Lighthouse 점수에 미치는 영향
앱의 성능은 시작 시간 과 런타임 성능의 두 가지 메트릭으로 정의됩니다. 코드 번들의 크기는 주로 전자에 영향을 미칩니다. 즉, 앱 코드와 프레임워크 코드가 결합됩니다. 런타임 성능은 프레임워크의 특정 최적화 기능과 프레임워크가 DOM 조작 및 업데이트를 처리하는 방식에 따라 달라집니다.
번들 크기
세 프레임워크는 모두 비슷한 크기의 최소한의 코드 번들을 가지고 있습니다. 프레임워크의 번들 크기는 시작 시간에 영향을 미치지만 Angular, React 및 Vue의 성능을 비교할 때 메트릭이 주된 초점이 되어서는 안 됩니다.
더 정확하게 말하면, 각도 번들 크기는 Vue 및 React 번들 크기보다 약간 크며 Vue 번들은 React 번들보다 약간 작습니다. 또한 Angular dev 팀이 (소스) 코드 번들의 크기를 꾸준히 최적화하고 있다는 점도 주목할 필요가 있습니다.
대략적인 수치는 아래 차트를 참조하십시오.
Lighthouse의 TTI 및 LCP 지표
Lighthouse는 귀중한 속도 인사이트를 제공하는 훌륭한 테스트 도구입니다. 가능한 성능 문제를 식별하고 사이트의 다양한 측면을 최적화하는 데 도움이 됩니다. 등대 점수는 여러 메트릭의 가중 평균을 기준으로 계산됩니다(전체 개요를 보려면 여기로 이동). 그러나 가장 큰 내용물 페인트(LCP), TTI(Time to Interactive) 및 CLS(Cumulative Layout Shift)는 사용자의 관점에서 가장 중요한 것일 가능성이 높습니다. TTI 및 LCP는 감지된 부하 속도와 직접 연결됩니다. 사용자가 앱과 상호 작용하기 전에 번들을 완전히 평가해야 하므로 TTI는 프레임워크 번들 크기가 SPA 속도에 미치는 영향을 잘 나타냅니다. TTI가 긴 사이트는 로드하는 동안 사이트의 다양한 부분을 표시하지만 사용자가 상호 작용할 수 없으므로 궁극적으로 좌절을 초래할 수 있습니다. 반면에 LCP 메트릭은 페이지 내용의 가장 큰 요소가 화면에 렌더링될 때까지 걸리는 시간을 측정합니다.Lighthouse와 실제 브라우징 데이터 비교
합성 속도 측정 도구(예: Lighthouse)가 전체 이야기를 전달하지 않는다는 점에 주목할 필요가 있습니다. 사이트 속도는 사용자가 사이트를 탐색할 때 사이트가 어떻게 “느낌”하는지에 관한 것입니다. Lighthouse 성능 점수는 좋은 참조 포인트이지만 다소 임의적이며 실제 경험과 관련이있는 것이 어렵습니다. 예를 들어, 사용자 경험 측면에서 60점이라는 성능 점수가 50점인 경우와 비교했을 때 얼마나 더 좋은지 번역하기는 어렵습니다. 합성 테스트는 또한 구형 장치 및 연결을 시뮬레이션하는 경향이 있으며(예: Lighthouse는 3G 연결을 시뮬레이션함), 실제로 대부분의 모바일 사용자는 고속 LTE 또는 5G 네트워크를 사용합니다. 특정 프레임워크에서 실행되는 사이트는 “느낌”이 빠르지만 원시 성능 점수와 관련하여 다른 사이트에 손실되거나 그 반대의 경우도 마찬가지입니다. 이것은 주로 각 프레임워크가 사이트가 사용자에게 얼마나 빨리 “느낌”을 향상시키기 위해 사용하는 특정 트릭 (예 : 게으른 로딩)에 기인합니다. 다음 섹션에서는 이러한 프레임워크가 웹 사이트 성능 개선을 위해 제공하는 기회를 살펴보겠습니다.각도
Angular 는 새 태그 및 특성을 사용하여 HTML 코드를 확장하고 특성을 해석하여 데이터 바인딩을 수행합니다. 풍부한 기능으로 인해 작업 응용 프로그램은 Vue 또는 React에 비해 훨씬 더 클 수 있으며(약 500KB) 성능에 약간 영향을 줄 수 있습니다.
Angular의 MVC 추상화 (소스)
다음은 Angular의 주요 이점에 대한 간략한 요약입니다.
- 코드 생성. Angular는 JavaScript 가상 머신을 위해 고도로 최적화된 코드를 생성하여 손으로 작성한 코드의 이점을 제공합니다. JavaScript와 결합된 HTML 템플릿은 React와 같은 다른 프레임워크에서 불가능한 최적화를 위한 문을 엽니다.
- 코드 분할. 컴포넌트 라우터 덕분에 Angular 앱이 빠르게 로드되고 자동 코드 분할이 가능합니다. 이렇게 하면 사용자가 요청한 뷰를 렌더링하는 데 필요한 코드를 로드합니다.
- 실제 DOM입니다. Angular는 실제 DOM을 사용하므로 대부분의 전자 상거래 사이트와 같이 자주 변경되는 콘텐츠가 아닌 콘텐츠가 수시로 업데이트되는 단일 페이지 응용 프로그램에 가장 적합합니다. 화면에 아무것도 그려지지 않기 때문에 가상 DOM을 조작하는 것이 훨씬 빠릅니다.
반응
Facebook에서 개발하고 개발한 React는 가장 인기 있는 오픈 소스 모바일 애플리케이션 프레임워크 중 하나입니다. 광범위한 라이브러리를 제공하지 않으므로 Angular의 크기보다 훨씬 작습니다.
React 개발자는 단일 방향 데이터를 사용하여 프로젝트를 보다 효율적으로 제어할 수 있습니다. 앱을 디자인할 때 React 개발자는 상위 상위 구성 요소 내에 하위 구성 요소를 중첩할 수 있습니다.
React는 다음과 같은 몇 가지 흥미로운 기능을 제공합니다.
- 가상 DOM: 노드는 필요한 경우에만 다시 렌더링됩니다. React는 새 데이터를 원래 DOM과 비교하고 뷰를 자동으로 업데이트합니다. 따라서 정기적인 콘텐츠 업데이트가 필요한 모든 규모의 응용 프로그램의 성능이 향상됩니다.
- 단방향 데이터 바인딩: React는 Flux 컨트롤 애플리케이션 아키텍처와 단방향 데이터 바인딩을 사용합니다. ReactJS는 사용자의 View를 업데이트하는 데 도움이 되며 Flux는 애플리케이션 워크플로우를 제어합니다. Virtual DOM은 새 데이터를 원래 DOM과 비교하고 View를 자동으로 업데이트하므로 장점이 있습니다.
- 번들링 및 트리 쉐이킹 지원: 최종 사용자의 리소스 부하를 최소화합니다.
- SSR(Server-side rendering) 지원: 특정 구현에서 속도 향상을 제공합니다.
Angular 및 Vue보다 더 큰 범위에서 React는 최종 사용자가 페이지를 더 빨리 “느낌”하게하는 특정 기술을 사용합니다. 예를 들어 프레임워크는 페이지의 콘텐츠를 렌더링하는 것보다 사용자 입력의 우선 순위를 지정합니다.
Vue
VUE는 속도가 빠르며 크기가 30KB(gzip)에 불과하여 첫 번째 로드가 더 빨라집니다. 따라서 세 가지 프레임 워크 중 가장 작고 Vue에서 실행되는 웹 사이트의 성능을 크게 향상시킬 수 있습니다.
VUE는 다음을 제공합니다.
- 서버 쪽 렌더링(SSR)
- 나무 떨림
- 번들링
- 가상 DOM: 프로젝트 내의 변경은 DOM에 적절하게 영향을 미치지 않습니다. 실제 DOM을 수정하는 것은 리소스 집약적인 작업이므로 업데이트가 먼저 가상 DOM에 적용됩니다.
주요 JavaScript 프레임워크 및 라이브러리의 시작 시간, 메모리 할당 및 특정 작업 지속 시간을 비교하려면 이 상세 벤치마크 보고서를 확인하십시오. React와 비교할 때 Vue는 메모리 할당과 시작 시간 측면에서 약간 더 좋지만 React는 런타임 측면에서 조금 더 빠릅니다.
Angular 및 Vue는 JavaScript와 결합된 HTML 템플릿을 사용합니다. 이것은 React가 제공하지 않는 최적화 공간을 추가로 제공합니다. 예를 들어, Vue는 종속성을 추적하여 하위 구성 요소의 불필요한 렌더링을 방지합니다.
VUE 대 React 대 Angular SPA 최적화
벤치마크와 성과 점수가 전체 스토리를 말해주지 않는다는 것을 알고 있습니다. 웹 사이트 속도는 응용 프로그램 크기와 최적화 노력에 따라 달라질 수 있습니다. Vue, React 및 Angular Spa를 최적화하여 속도를 높일 수 있는 몇 가지 아이디어를 소개합니다.
1. 서버 측 연출 (SSR)
전반적으로 SPA 사이트에 SSR을 사용하면 다음과 같은 네 가지 주요 이점이 있습니다.
- SSR을 사용하면 SPA 템플릿을 빠르게 로드하고 사용자에게 콘텐츠를 표시할 수 있습니다(사용자가 즉시 상호 작용하지 못할 수도 있음). SSR이 없으면 사용자는 빈 화면을 바라보며 브라우저에 콘텐츠가 로드되고 렌더링되기를 기다립니다.
- SSR은 최종 사용자 시스템의 부하를 줄입니다.
- Google은 이제 SPA 콘텐츠를 제대로 크롤링할 수 있으므로 서버 측 렌더링이 SEO에 이전만큼 중요하지 않을 수 있습니다. 그러나 SSR을 사용하는 이점은 다른 많은 검색 엔진이 여전히 JavaScript를 이해하지 못하고 JavaScript가 많은 사이트를 제대로 크롤링 할 수 없다는 것입니다.
- 소셜 네트워크에서 클라이언트가 렌더링한 SPA 사이트에서 공유한 콘텐츠를 제대로 표시할 수 없는 경우가 많습니다. 예를 들어 Facebook 스크레퍼는 서버에서 설정한 메타 태그에만 의존하며 클라이언트측 렌더링 메타 태그에서는 작동하지 않습니다. Open Graph를 통해 공유할 때 SPA 사이트의 모양을 보다 잘 제어하려면 SSR이 필요합니다.
- AMP는 모바일 기기에서 최초 로딩 속도를 높이지만 JavaScript를 사용할 수는 없습니다. 클라이언트의 React에서 AMP를 렌더링하는 것은 불가능합니다. 서버에서 수행해야 합니다. 그러나 SSR이 있더라도 React 앱을 유효한 AMP 앱으로 변환하기 위해 뛰어 넘어야 할 많은 후프가 있습니다. 다행히도 React Storefront 와 같은 일부 프런트엔드 프레임워크는 모든 것을 처리할 수 있습니다.
SSR은 정적 사이트에 가장 적합하지만, 올바른 인프라를 통해 eCommerce SPA 웹 사이트는 여전히 캐시할 수 있습니다. Layer0에서는 콘텐츠가 서버 측에서 즉시 렌더링된 다음 CDN-as-JavaScript를 사용하여 엣지에서 캐시됩니다. 이러한 방식으로 수백만 페이지가 아닌 수천 개의 전자상거래 스파, 개인화, 실시간 인벤토리 등과 같은 대규모 데이터베이스 기반 웹사이트는 방문부터 체크아웃까지 1초 미만의 페이지 로딩으로 사용자를 만족시킬 수 있습니다.
CDN-as-JavaScript 서비스 작업자(Layer0 Workers)는 방문자가 링크를 탭하여 브라우저로 스트리밍하기 전에 엣지에서 동적 데이터를 지능적으로 가져옵니다.
Layer0 네트워크 및 모니터링 도구는 동적 데이터가 최소 95%의 시간 동안 캐시되도록 하여 사전 추출에 의해 생성된 추가 요청으로부터 데이터베이스를 보호합니다. 이렇게 하면 1초 미만의 페이지 로드를 제공하여 방문자에게 착륙부터 결제까지 원활한 경험을 제공할 수 있습니다.
Layer0 네트워크 및 모니터링 도구
전반적으로 SSR 기능 및 상세 문서와 관련하여 Vue는 서버측 페이지를 렌더링하기 위해 타사 라이브러리(예: Next.js)가 필요한 React보다 우수합니다.
2. 앰프
AMP는 HTML을 단순화하고 CSS 및 JavaScript에 대한 엄격한 제한을 적용하여 모바일 웹에서 더 빠르고 우수한 경험을 제공합니다. 그런 다음 이러한 페이지는 Google 서버에서 캐시되고 미리 렌더링되어 거의 즉각적으로 앱으로 전환됩니다.
단점은 PWA/SPA를 작성하는 방법과 다르며 React Storefront 와 같이 AMP가 내장된 전용 프레임워크를 사용하지 않는 한 앱을 완전히 다시 작성한다는 것입니다.
AMP 페이지에는 Google의 SERP에서 들어오는 트래픽에 대한 500ms 중간 페이지 로드가 있습니다. 이러한 속도는 Google 서버가 AMP 페이지 링크를 클릭하기 전에 AMP 콘텐츠를 사용자의 브라우저에 미리 가져오고 미리 렌더링하기 때문에 가능합니다. 평균 전자 상거래 사이트는 Google 검색에서 트래픽의 큰 덩어리를 가져옵니다 (유기적 및 유료 모두), 그래서 이러한 이익은 엄청난 영향을 미칠 수 있습니다.
AMP를 사용하는 사이트에서는 이탈률이 감소합니다. 일반적으로 페이지가 로드되기를 기다리는 동안 이탈하는 사용자도 이제 번개처럼 빠른 경험을 할 수 있습니다.
3. 부호 분할
기능을 계속 추가하면 시간이 지남에 따라 단일 페이지 응용 프로그램이 증가합니다. 그러나 우리는 모든 응용 프로그램이 거의 사용되지 않고 불필요하게 느려지는 일부 기능을 가지고 있음을 알고 있습니다. 앱을 최대한 빨리 유지하려면 코드 분할을 구현해야 합니다.
코드 분할에는 앱의 각 최상위 구성 요소에 대해 별도의 번들을 만드는 작업이 포함됩니다. 전자 상거래 SPA의 경우 홈 페이지, 제품 목록 및 제품 설명 페이지에 대한 별도의 번들이 있습니다. 이렇게 하면 사용자가 특정 제품에 대한 링크를 통해 앱에 도착하면 브라우저가 이전 페이지의 코드를 다운로드하여 실행할 필요가 없으므로 TTI 및 FID 시간이 단축됩니다.
코드 분할을 사용하면 앱은 백그라운드에서 다른 페이지 구성 요소를 “게으르게 로드”하고 사용자가 탐색하기로 결정한 경우 사용할 수 있습니다. 이렇게 하면 대역폭이 절약되고 첫 번째 입력 지연 또는 FID(FID는 대화형 또는 TTI 측정 지표의 시간으로 근사치임)가 감소하여 웹 사이트 속도와 검색 엔진 순위가 향상됩니다.
4. 게으른 선적
VUE, React 및 Angular는 모두 SSR과 결합하여 속도를 크게 향상시킬 수 있는 Lazy Loading을 지원합니다.
SSR을 구현할 때 지연 로딩이 어려울 수 있습니다. 서버는 나가는 HTML을 렌더링하는 데 사용된 구성 요소를 알고 있어야 하며 HTML과 함께 이러한 구성 요소에 대한 코드를 보내야 합니다. 그렇지 않으면 앱이 대화형이 되기 전에 브라우저에 마운트되고 두 개의 렌더링 사이클을 실행해야 합니다. 그러면 FID(및 TTI)가 증가하여 콘텐츠가 플래시되거나 고장이 발생할 수 있습니다.
Lazy Loading과 SSR이 연결된다. Lazy 로딩을 위해 선택한 라이브러리(예: React Loadable)는 응답으로 다시 전송된 최종 HTML을 생성하는 방법에 영향을 미칩니다. 서버에서 렌더링된 HTML을 하이드레이션하기 위해 로드해야 하는 번들을 캡처하려면 <loadable.capture 를 추가해야 합니다.></loadable.capture> SSR 코드에 입력한 다음 React Loadable의 getBundles 함수를 사용하여 어떤 <스크립트를 사용하는지 알아냅니다.></script> 태그를 문서 본문에 추가해야 합니다.
게으른 로드 클라이언트 힌트는 아직 모든 브라우저에서 전역적으로 지원되지 않으므로 게으른 로딩을 원활하게 구현하기 위한 몇 가지 해결 방법이 있습니다.
솔루션 #1
이미지를 서버 측에서 렌더링하는 대신 앱이 마운트될 때 클라이언트측에서 이미지를 채우도록 할 수 있습니다.
솔루션 #2
“접힌 부분 아래” 이미지에 대해서만 게으른 로딩을 사용하십시오. 즉, 알고 있는 이미지는 로딩 직후 표시되지 않습니다. 이는 사용자의 장치 및 디스플레이 크기에 따라 접는 선이 위아래로 움직일 수 있기 때문에 어려운 작업입니다. 그러나 일부 휴리스틱은 도움이됩니다. 예를 들어, 전자 상거래 카테고리 페이지에서 첫 번째 제품 이미지 집합에 대해 게으른 로딩을 끌 수 있습니다 (그들은 “접기 위”일 가능성이 높습니다). 그리고 당신이 알고 있는 아이템은 지속적으로 접기 위에 있을 것입니다 (예: 헤더, 회사 로고, 카트 아이콘), 당신은 어쨌든 게으른 로드를 활성화 하지 말아야 하 고 항상 그들을 서버 측에 렌더링 할 수 있습니다.
솔루션 #3
사용자 에이전트를 검색하면 SSR 렌더링 페이지의 적절한 버전을 제공하는 데 도움이 될 수 있습니다. 사용자 에이전트 감지는 일반적으로 점진적 개선 구현에는 권장되지 않지만 브라우저가 클라이언트 힌트를 따라잡고 구현하는 동안 임시 해결 방법으로 사용됩니다.
이 솔루션을 사용하려면 캐시 키를 적절하게 정규화해야 합니다. 그렇지 않으면 캐시를 크게 조각화할 수 있습니다.
5. 현대 CDN
SPA의 속도를 최적화하고 우수한 CDN을 사용하면 사이트가 향상되지만 1초 미만의 속도를 달성하는 것만으로는 충분하지 않습니다. 이는 대부분의 기존 CDN이 정적 파일을 캐싱하는 데만 능숙하지만 전체적으로 JSON/HTML/SSR 데이터에는 잘 대처하지 못하기 때문입니다. 이커머스 SPA 사이트는 바로 그 역할을 합니다. 이러한 사이트를 더 빠르게 만들려면 여러 웹 기술이 효율적으로 작동해야 합니다. 다른 CDN과 달리 Layer0 애플리케이션 인식 CDN은 이커머스 스파와 잘 작동합니다. 캐시 적중률을 전례 없는 수준으로 최적화하고 에지에 인텔리전스를 제공합니다. 이를 통해 비즈니스 소유자는 무한 URL 목록을 표시하는 대신 유사한 페이지(예: PDP, PLP 및 장바구니)를 분류하여 추세와 최적화 기회를 파악할 수 있습니다. 이를 통해 조치를 취하고 웹 사이트 로드 시간의 차이를 확인할 수 있습니다.
그러나 무엇보다도 CDN-as-JavaScript는 고급 예측 프리페치 기술을 사용하여 캐시된 데이터를 엣지에서 사용자의 브라우저로 스트리밍한 후 아무 것도 활용하지 않는다는 점이 중요합니다. 이를 통해 웹사이트가 쇼핑객의 도청 시간보다 5초 앞당겨져 즉각적인 브라우징 경험을 통해 사용자를 만족시킬 수 있습니다.
6. 이동할 수 있는 장식새김
Angular는 모바일 앱을 구축하는 데 유용합니다. 프레임워크를 사용하여 모든 장치에서 실행되는 웹 애플리케이션을 구축하거나 Angular와 NativeScrip을 결합하여 iOS 및 Android 네이티브 앱을 개발할 수 있습니다. 이를 통해 데이터 바인딩, 종속성 주입, 서비스 및 라우팅과 같은 각도 개념을 재사용할 수 있습니다.
React Native는 크로스 플랫폼 개발의 왕으로 간주됩니다. 개발자는 React와 유사한 컴포넌트를 사용하여 Android와 iOS 간에 JavaScript 코드를 최대 99%까지 재사용할 수 있습니다. 즉, 개발자는 자신의 스타일을 제어하는 100 % 기본 위젯을 만들 수 있습니다. 프레임워크는 보기 계층을 순수 상태 출력으로 처리하므로 네이티브 모양과 성능으로 iOS/Android용 컴패니언 앱을 쉽게 만들 수 있습니다.
Vue는 React보다 뒤처지지만 여전히 모바일 개발을 위한 몇 가지 유용한 솔루션을 제공합니다. 예를 들어, NativeScript를 사용하면 Vue 응용 프로그램을 작성하고 네이티브 iOS/Android 응용 프로그램으로 컴파일할 수 있습니다.
그 다음에는 Vue 네이티브가 나옵니다. 이 프레임워크는 Vue 및 RN 에코시스템의 장점, 선언적 렌더링, 양방향 바인딩 및 크로스 플랫폼 네이티브 앱을 만들기 위한 기본 구성 요소 집합을 결합합니다.
스파가 더 빠르지만 여전히 속도 문제가 있음
단일 페이지 애플리케이션의 원래 매력은 탐색 중에 후속 페이지가 다시 로드되지 않아 더 빠르고 마찰 없는 브라우징 환경을 제공한다는 것입니다. 그러나 최신 SPA 프런트엔드는 사이트 속도 솔루션의 일부에 불과하며 다음과 같은 몇 가지 문제를 해결해야 합니다.
- 합성 속도 벤치마크와 테스트가 반드시 전체 스토리를 말하지는 않습니다. 이러한 프레임워크의 속도는 응용 프로그램 크기와 최적화 노력에 따라 달라질 수 있습니다.
- 점진적인 웹 앱, SPA 및 AMP를 비롯한 다양한 최첨단 프런트엔드 기술이 고객 경험을 극적으로 향상시킬 수 있지만 웹 사이트 속도는 풀 스택 문제입니다. 브라우저, 에지 및 서버를 아우릅니다. 따라서 모든 웹 사이트, SPA 및 다중 페이지 애플리케이션의 속도를 높이기 위해 전체 스택 솔루션이 필요합니다.
- 이러한 모든 기술은 속도를 향상시킬 수 있지만 조화롭게 적용하면 가장 잘 작동합니다. 이러한 모든 기술이 함께 작동하도록 만드는 것은 사내 팀이 처리할 수 없는 복잡한 작업입니다(예를 들어, Node.js 레이어를 만들어야 함).
Layer0: 웹을 즉각적이고 간단하게 만들기
Layer0은 전자 상거래 웹 사이트를 빠르고 쉽게 개발할 수 있도록 완벽한 솔루션입니다. 고급 최적화 기법을 결합하여 전자 상거래 스파와 같은 대규모 데이터베이스 기반 웹 사이트의 속도를 높이고, 코드를 워크플로의 중심에 배치하여 개발자에게 일주일에 하루를 되돌려 주는 강력한 도구를 제공합니다. Layer0은 Jamstack을 대형 전자 상거래 웹 사이트에 제공합니다.
인스턴트: 최신 프론트엔드와 엣지의 동적 콘텐츠에 대해 95%의 캐시 적중률을 가진 CDN-as-JavaScript와 Node.js 백엔드를 결합하여 Layer0은 복잡한 웹사이트가 스택 전반의 속도를 최적화하도록 지원합니다. 대규모 이커머스 웹사이트에 대한 중간 규모 LCP(Content Paint) 시간을 보장하는 유일한 플랫폼입니다.
단순함: Layer0(현재 Edgio)은 다음과 같은 기능을 제공하는 프론트엔드를 개발, 배포, 미리보기, 실험, 모니터링 및 실행할 수 있는 올인원 플랫폼입니다.
- 사전 렌더링과 Just-in-Time 렌더링을 통해 전자 상거래용 Jamstack 활용
- 제품 카탈로그 API에서 데이터를 프리페치하여 지연 시간이 없는 네트워킹 지원
- 앱에서 기본적으로 엣지 구성(CDN-as-JavaScript)
- 에지 규칙을 로컬로 실행 및 사전 프로덕션에서 실행
- GitHub, GitLab 또는 Bitbucket에서 모든 새 브랜치와 푸시로 미리보기 URL을 만듭니다.
- 성능 A/B 테스트, 카나리 배포 및 개인화를 위해 엣지에서 분할 실행
- AWS Lambda보다 훨씬 쉽고 안정적인 서버리스 JavaScript
결론
더 빠른 사이트를 운영하는 것은 단지 멋진 속임수가 아닙니다. 하루의 끝에, 당신은 뿐만 아니라 사용자를 감동 하려고 하지만 또한 세계에서 가장 큰 검색 엔진을 기쁘게 하려고. 구글의 순위가 곧 결정될 것이기 때문에 부분적으로 페이지 속도에 의해 결정되기 때문에 가볍게 받아 들일 수는 없습니다. 빠른 사이트는 SEO 순위와 전환을 향상시켜 더 많은 수익을 창출한다는 것을 의미합니다.
각 프레임워크의 성능에 대해 많은 언급이 있지만, 기억해야 할 세 가지 사항이 있습니다.
- 프레임워크 성능의 실제 차이는 미미할 수 있습니다. SPA 사이트의 성능은 매우 많은 변수에 따라 달라지므로 이러한 프레임워크를 의미 있는 방식으로 나란히 비교하는 것은 불가능합니다.
- Angular, Vue, React 중 어떤 것을 사용하든, 여전히 개선할 여지가 많습니다.
SPA를 더 빠르게 만들려면 고급 웹 기술이 함께 작동해야 하며, 사내 팀에서는 이를 효율적으로 구현하지 못할 수 있습니다. 고맙게도 Layer0을 포함한 몇 가지 미래 지향적 인 공급 업체는 당신을 위해 무거운 리프팅을 수행했습니다.
Layer0은 서버측 렌더링과 첨단 예측 프리페치 및 에지에서의 사전 캐싱을 결합합니다. 동적 데이터는 최소 95%의 시간 동안 캐시되기 때문에 사전 반입을 통해 생성되는 추가 요청으로부터 데이터베이스가 보호됩니다. Layer0 CDN-as-JavaScript 서비스 작업자는 방문자가 링크를 누르기 전에 동적 페이지를 지능적으로 가져옵니다. 이렇게 하면 단일 페이지 애플리케이션에서 1초 미만의 페이지 로드를 제공하여 방문자에게 착륙부터 결제까지 원활한 경험을 제공할 수 있습니다.
