Chrome Dev Insider: 프레임워크 생태계를 통한 성능 확장

Paul Kinlan

저는 Chrome의 개발자 관계를 이끄는 폴 킨란입니다. 저는 실제 개발자의 관점을 제품 및 엔지니어링팀에 전달하고 개발자 만족도 개선을 목표로 하는 열정적인 웹 활동가 팀과 함께 일하고 있습니다.

Google은 '만족도'가 추적하고 개선하기에 야심적이고 주관적인 측정항목임을 잘 알고 있으므로 개발자 요구사항에 중점을 두면서 실질적인 변화를 가져올 수 있는 방법을 끊임없이 모색하고 있습니다. Google에서 유용하다고 생각하는 원칙은 '개발자가 있는 곳에서 만나기'입니다. 최근 Stack Overflow 연구에 따르면 75% 의 개발자가 프레임워크 또는 일종의 추상화를 사용한다고 보고했습니다. Google은 이미 기술 스택에 관해 결정을 내렸거나 기술 스택을 관리할 수 없는 개발자를 가장 효과적으로 지원할 방법을 모색해 왔습니다. 오버헤드를 추가하지 않고 생산성을 높이려면 어떻게 해야 하나요?

Chrome의 소규모 팀은 프레임워크 및 라이브러리와 같은 웹 플랫폼의 서드 파티 추상화를 사용하는 것을 목표로 Aurora라는 프로젝트를 진행해 왔습니다. Google의 목표는 고객인 웹 개발자에게 부담을 주지 않고 이러한 추상화에 성능 향상을 직접 가져오는 것입니다.

Chrome Dev Insider의 세 번째 버전에서는 Project Aurora팀의 애디 오스매니, 카라 에릭슨, 후세인 지르데와 만나 이 프로젝트에 접근하는 방식과 향후 계획에 대해 자세히 알아봤습니다.

내부자 팁: 서드 파티 프레임워크 사용

이 프로젝트의 시작부터 살펴보겠습니다. 어떻게 하신 건가요?

애디: Aurora는 개발자가 현재 위치에서 원하는 곳으로 도달할 수 있도록 지원한다는 단순한 아이디어에서 시작했습니다. 예를 들어 개발자가 선택한 인기 있는 기술 스택의 성능을 개선하는 데 도움을 주는 것입니다. 요즘 많은 앱 개발자가 React, Vue, Angular 또는 Next.js, Nuxt와 같은 메타 프레임워크* 를 사용하여 빌드하고 있습니다. Svelte, Lit, Preact, Astro 목록은 계속됩니다. 이러한 개발자가 심층적인 전문가 (예: 성능)가 되기를 기대하기보다는 이러한 스택에 더 많은 권장사항을 기본적으로 삽입하여 성공의 길로 안내할 수 있습니다. 이렇게 하면 웹용으로 빌드하는 것만으로도 사이트 품질이 향상됩니다.

Aurora는 널리 사용되는 몇 가지 프레임워크와 메타 프레임워크를 선택하여 파트너십을 맺고, 다른 사람들이 Chrome 프레임워크 펀드를 통해 다른 프레임워크와 도구를 빠르게 따라잡고 확장할 수 있도록 학습 내용 (예: 우수한 이미지 구성요소를 빌드하는 방법)을 문서화합니다. 브라우저를 통해 웹 환경의 품질을 개선할 수 있지만 경우에 따라 프레임워크를 통해서도 이 목표를 달성할 수 있다고 생각합니다. 이번 업데이트를 통해 모든 사용자에게 더 높은 품질의 웹을 제공하는 Google의 목표 달성에 도움이 되기를 바랍니다.

카라: 이를 확장하면 개발자 환경을 개선하여 웹 성능을 개선하는 것입니다. 실적 권장사항은 자주 변경되고 기업이 이를 따라잡기 어렵기 때문에 이를 공개하는 것만으로는 충분하지 않습니다. 실적보다 우선시되는 자체 비즈니스 우선순위가 있습니다.

따라서 Google은 개발자가 성능에 할애할 시간이 제한되어 있다면 개발자가 더 쉽고 빠르게 성능이 우수한 앱을 빌드할 수 있도록 지원하는 것이 좋다고 생각합니다. 인기 있는 웹 프레임워크와 파트너 관계를 맺으면 상위 수준의 구성요소, 규정 준수 경고 등을 통해 개발자 환경을 개선할 수 있는 적절한 추상화 계층에 있게 됩니다. 이러한 인기 도구를 사용하는 모든 사용자가 이러한 이점을 누릴 수 있습니다. 그리고 이론적으로 권장 사항이 변경되면 Google에서 구성요소를 업데이트할 수 있으므로 개발자는 최신 상태를 유지하는 데 대해 걱정할 필요가 없습니다.

후세인: 저는 개발자 어드보케이트로 Google에 입사한 후 몇 년 후 소프트웨어 엔지니어링 역할로 전환했습니다. 이전에 했던 일의 대부분은 웹 개발자에게 훌륭한 사용자 환경을 빌드하는 다양한 방법을 가르치는 것이었습니다. 사이트의 성능과 사용성에 영향을 미칠 수 있는 일반적인 문제에 대해 개발자에게 경고하기 위해 동일한 안내의 변형이 반복적으로 제공되었습니다. Aurora 프로젝트를 구상할 때 Google은 다음과 같은 질문을 했습니다. 툴체인이 모든 것을 처리해 주기 때문에 개발자에게 무엇을 해야 하는지 알려주지 않아도 되는 방향으로 나아갈 수 있을까요?

제가 잘 이해한 것 같습니다. 엔지니어 6명으로 구성된 팀이신가요? 가능한 모든 프레임워크나 라이브러리를 사용할 수는 없을 것입니다. 그렇다면 함께 일할 파트너는 어떻게 선택하나요? 어떤 사람들이 이용하나요?

애디: 웹은 여러 면에서 미지의 영역과 같습니다. 원하는 프레임워크, 번들러, 라이브러리, 서드 파티를 거의 모두 선택할 수 있습니다. 이로 인해 실적이 좋게 또는 나쁘게 될 수 있는 여러 복잡한 계층이 도입됩니다. 실적을 개선하는 가장 좋은 방법 중 하나는 의견을 피력하는 데 편안함을 느끼는 층을 찾고 의견을 더 많이 추가하는 것입니다.

예를 들어 웹 프레임워크 (Next.js, Nuxt.js, 어느 정도는 Angular)는 수동 롤링 솔루션보다 더 많은 의견과 기본값을 빌드하려고 합니다. 이러한 이유로 Google은 크리에이터와 협업하는 것을 좋아합니다. 이러한 모델에서는 Core Web Vitals를 개선하기 위해 이미지, 글꼴, 스크립트를 로드하는 방법에 관한 더 강력한 기본값을 사용하는 것이 좋습니다.

또한 최신 권장사항이 적용되는 영역과 재고가 필요한 영역을 확인하는 데 유용하며, 최적화 문제 해결 방법을 전체 생태계에 알리는 데 도움이 될 수 있습니다.

카라: 현실적으로 인기도도 고려해야 합니다. 웹에 최대한 큰 영향을 미치려면 기존에 큰 개발자 커뮤니티가 있는 프레임워크와 라이브러리를 사용하는 것이 이상적입니다. 이렇게 하면 더 많은 개발자와 앱에 도달할 수 있습니다. 하지만 인기만으로는 안 됩니다. 궁극적으로 인기도, 라이브러리의 확고한 방향, 사용할 수 있는 기능 세트가 충족되어야 합니다.

예를 들어 인기도만 고려하면 React, Vue, Angular가 고려할 만한 '3대'입니다. 하지만 Google에서는 Next.js, Nuxt, Angular를 가장 많이 사용합니다. React 및 Vue와 같은 뷰 라이브러리는 주로 렌더링에 중점을 두므로 원하는 모든 기능을 라이브러리에 직접 빌드할 수 없습니다. 따라서 Google은 Next.js 및 Nuxt와 같은 이를 기반으로 빌드된 주관적인 메타 프레임워크와 더 긴밀하게 협력합니다. 이 추상화 수준에서는 내장 구성요소를 만들 수 있습니다. 또한 서버가 내장되어 있으므로 서버 측 최적화를 포함할 수 있습니다.

Angular가 긴밀한 파트너십 목록에 포함되어 있지만 메타 프레임워크는 아닙니다. Angular는 꽤 인기가 있지만 React 및 Vue와 같은 보완적인 메타 프레임워크가 없으므로 다소 특별한 케이스입니다. 따라서 Google은 Angular와 직접 협력하고 가능한 경우 CLI를 통해 기능을 제공합니다.

또한 Gatsby와 같은 다른 프로젝트와는 디자인을 주기적으로 동기화하지만 코드에 적극적으로 기여하지 않는 등 여러 가지 지속적인 관계가 있습니다.

실제로는 어떻게 작동할까요? 이 문제를 해결하기 위해 어떤 접근 방식을 사용하셨나요?

카라: 실제로는 밀접하게 협력하는 프레임워크가 몇 개 있습니다. 이 프레임워크를 사용하여 앱을 프로파일링하고 일반적인 성능 문제점을 파악하는 데 시간을 할애하겠습니다. 그런 다음 프레임워크팀과 협력하여 이러한 문제점을 해결할 수 있는 실험용 기능을 설계하고 OSS 저장소에 직접 코드를 기여하여 구현합니다.

Google은 성능 영향이 예상한 것과 일치하는지 확인하는 것이 매우 중요하므로 외부 회사와 협력하여 프로덕션에서 성능 테스트를 실시하기도 합니다. 결과가 좋으면 이 기능을 '안정화'하고 기본값으로 설정할 수 있습니다.

말처럼 쉽지는 않습니다. 지금까지 어떤 어려움이 있었으며 어떤 점을 배웠나요?

후세인: Google에서는 최선을 다해 여러 경쟁 우선순위가 있는 인기 있는 오픈소스 저장소에 기여하는 데 노력하고 있습니다. Google팀이라고 해서 Google 기능이 우선순위에 반영되는 것은 아닙니다. 따라서 Google은 다른 팀의 발목을 잡지 않으면서 새로운 기능을 제안하고 출시하는 일반적인 절차를 따르기 위해 최선을 다하고 있습니다. Next.js, Nuxt, Angular 생태계에서 수용적인 유지관리자와 협력할 수 있어 매우 기쁩니다. 웹 생태계에 대한 Google의 우려사항을 경청하고 다양한 방식으로 협력해 주셔서 감사합니다.

Google에서 사용하는 많은 프레임워크의 전반적인 사명은 동일합니다. 개발자가 즉시 개선된 사용자 환경을 이용하면서도 우수한 개발자 환경을 누릴 수 있는 방법을 찾는 것입니다. Google은 수백, 아니 수천 명의 커뮤니티 참여자와 프레임워크 유지관리자가 서로 교차하는 여러 프로젝트에서 각각 작업하고 있음을 알고 이를 존중합니다.

카라: 또한 YouTube는 성능 영향의 검증과 데이터에 기반한 조치를 중요하게 생각하기 때문에 이 과정에 다소 시간이 더 걸립니다. Google은 아직 탐색하지 않은 영역을 탐색하고 있으므로 실적이 좋지 않은 최적화를 실험하거나 계획된 기능을 빌드하지 못하는 경우가 있습니다. 기능이 제대로 작동하더라도 성능을 검증하는 추가 단계가 몇 가지 필요하므로 시간이 걸리고 일정이 연장됩니다.

기능을 테스트할 프로덕션 파트너를 찾는 것도 쉽지 않습니다. 앞서 언급한 바와 같이 파트너는 비즈니스이며 자체 우선순위가 있으므로 우선적으로 진행해야 하는 기존 프로젝트와 잘 맞지 않는 경우 새 이니셔티브를 적용하기 어려울 수 있습니다. 또한 지원에 가장 관심이 있는 기업은 이미 실적에 투자하고 있는 경우가 많으므로 Google의 타겟층이 아닙니다. YouTube는 실적에 투자할 수 없는 대규모 커뮤니티의 의견을 수집하고자 하지만, 이러한 커뮤니티는 YouTube에 문의할 가능성이 가장 낮습니다.

어떤 종류의 최적화에 중점을 두고 있나요?

후세인: 수천 개의 애플리케이션을 분석한 결과, 가장 큰 성능 문제는 일반적으로 프레임워크 자체가 아닌 애플리케이션 코드의 안티패턴으로 인해 발생하는 것으로 확인되었습니다. 예를 들어 불필요하게 큰 이미지를 전송하거나, 맞춤 글꼴을 너무 늦게 로드하거나, 기본 스레드를 차단하는 서드 파티 요청을 너무 많이 가져오거나, 비동기 콘텐츠로 인해 페이지에서 다른 항목이 이동하는 방식을 처리하지 않는 경우 등이 여기에 해당합니다. 이러한 문제는 사용하는 도구와 관계없이 발생할 수 있으므로 이러한 문제를 잘 처리하면서도 프레임워크 도구에 잘 맞는 깔끔한 개발자 환경을 제공하는 기본 최적화를 빌드할 수 있을까 생각했습니다.

이러한 생각으로 다음과 같은 기능을 출시했습니다.

Google의 작업은 다른 프레임워크와 도구가 유사한 최적화를 구현하도록 하는 데 영감을 주었습니다. 다음과 같은 예가 해당되지만, 이에 국한되지는 않습니다.

이러한 선수들과 함께 일한 결과 얻은 긍정적인 결과를 공유해 주시겠어요?

후세인: Google에서 제공한 최적화로 인해 많은 사이트의 성능이 개선되었습니다. 제가 가장 좋아하는 예시 중 하나는 Leboncoin입니다. 이 사이트는 Next.js 이미지 구성요소로 전환한 후 LCP를 2.4초에서 1.7초로 줄였습니다. 현재 실험 및 테스트 단계에 있는 기능은 더 많으며, 여기에서 이러한 기능으로 얻은 교훈과 성과를 계속 공유할 예정입니다.

좋습니다. 가장 인기 있는 프레임워크에 중점을 두고 계시지만, 현재 사용하고 있지 않은 다른 프레임워크나 라이브러리도 이로부터 이익을 얻을 수 있는 방법이 있나요?

Addy: Aurora가 공동작업하는 많은 성능 최적화는 모든 프레임워크에서 복제할 수 있습니다. 예를 들어 이미지 또는 스크립트 구성요소 작업을 살펴보면 기존 권장사항을 코딩하는 경우가 많습니다. 이러한 구성요소를 빌드하는 '방법'과 각 프레임워크에서 구성요소가 어떻게 표시되는지 문서화하려고 합니다. 이 아이디어를 복사하는 데 도움이 되기를 바랍니다.

한 생태계 (예: React 및 Next.js)에서 얻은 학습사항을 다른 생태계로 가져와 좋은 성과를 거둔 사례가 있습니다. 예를 들어 새로운 Angular 이미지 디렉티브 (Next.js 이미지 구성요소를 빌드하면서 얻은 학습사항을 기반으로 빌드됨) 또는 세분화된 JavaScript 청크 처리에 대한 Google의 접근 방식을 제공하는 Gatsby를 들 수 있습니다.

동시에 모든 프레임워크에서 참여자가 유사한 성능 기능을 빌드하거나 사용자에게 중요하다고 생각하는 다른 최적화에 투자할 수 있는 대역폭이나 자금이 있는 것은 아닙니다. Chrome 웹 프레임워크 펀드는 프로젝트에서 참여자에게 수익금을 지급하고 생태계에서 성능 작업을 확장할 수 있도록 JavaScript 생태계의 성능 작업을 후원하는 방법입니다.

앞으로 팀의 로드맵에는 어떤 내용이 있나요?

카라: 앞으로 흥미로운 프로젝트가 많이 예정되어 있습니다. 주요 개편 사항:

  • 글꼴 관련 CLS 줄이기: 웹 글꼴이 로드되어 대체 글꼴을 대체할 때 레이아웃이 변경되는 것은 흔한 일입니다. 글꼴 측정항목 재정의와 'size-adjust' 속성을 사용하여 Next.js에서 기본적으로 글꼴 관련 CLS를 줄이는 방법을 모색하고 있습니다. 이 문제에 대해 Nuxt팀과도 상의했으며 내년에는 이 아이디어를 더 많은 프레임워크로 확장할 계획입니다.
  • INP 디버깅: 이제 다음 페인트에 대한 상호작용 (INP) 측정항목이 출시되었으므로 Google은 프레임워크와 협력하여 커뮤니티의 INP 문제의 가장 일반적인 근본 원인을 조사하고 해결 방법을 제안하고 있습니다. YouTube는 이 문제와 관련하여 Angular와 긴밀히 협력하고 있으며 곧 결과를 공유할 수 있기를 바랍니다.
  • 일반적인 서드 파티 스크립트 최적화: 잘못된 시점에 서드 파티 스크립트를 로드하면 성능에 상당한 부정적인 영향을 미칠 수 있습니다. 매우 일반적인 서드 파티가 몇 개 있으므로 이러한 서드 파티가 프레임워크와 함께 최적으로 로드되고 기본 스레드를 차단하지 않도록 래퍼를 제공할 수 있는지 살펴보고 있습니다. 이 조사의 시작점으로 빌드한 Next.js 스크립트 구성요소를 사용합니다.

개발자는 이 사이트에서 진행 상황을 확인할 수 있습니다.

뉴스 속 장소

채팅을 종료하기 전에 Google 내에서 진행 중인 프레임워크 관련 몇 가지 흥미로운 소식을 전해드리고자 합니다.

7월, Chrome팀은 웹의 성능, 사용자 환경, 개발자 환경을 개선하는 것을 목표로 하는 프로젝트에 자금을 지원하는 데 중점을 둔 프레임워크 및 도구 펀드에 50만 달러의 최신 자금 지원을 발표했습니다. 향후 자금 지원 시 새 프로젝트가 고려되므로 요청을 제출하세요.

물론 커뮤니티에서는 놀라운 일들이 많이 일어나고 있습니다. 생태계는 Deno의 Fresh와 같은 새로운 프레임워크와 브라우저 내 데모일 뿐만 아니라 웹 컨테이너 API를 사용하여 브라우저에서 Node.js를 기본적으로 실행하는 Svelte의 온보딩 튜토리얼과 같은 멋진 환경으로 가득합니다. 좋은 자료가 많네요.

생태계가 하나로 모이고 브라우저에서 가능한 작업을 확장하며 개발자가 모든 사용자에게 적합한 제품을 빌드할 수 있도록 지원하게 되어 매우 기쁩니다. 웹 개발자로서는 지금이 매우 흥미로운 시기입니다.

다음번 Insider 때까지 Hwyl fawr.

이번 Chrome Dev Insider에 관해 어떻게 생각하시나요? 의견을 공유해 주세요.