HTML-First 사이트를 구축하여 사용자 전환율을 두 배로 높이기

Astro를 사용한 HTML-first 아키텍처로 복잡하고 JavaScript가 많은 React 애플리케이션을 교체함으로써 하룻밤 사이에 서비스 신청서를 완료하는 사용자 수가 두 배로 증가했습니다. 이 증가는 새로운 시스템이 오래된 브라우저, 저사양 하드웨어, 열악한 네트워크 연결을 사용하는 사용자들에게 여전히 기능했기 때문에 발생했습니다. 이러한 사용자 집단은 이전에 JavaScript 오류로 인해 이탈되었고 JavaScript 기반 분석에서는 보이지 않았습니다.

공공 서비스에서 JavaScript가 많은 프레임워크의 실패

규제된 독점 공공기관에서 중요한 신청서는 이전에 오래된 ASP 폼 또는 수동 프로세스로 관리되었습니다. 최근 React 앱을 사용하여これを 현대화하려는 시도는 심각한 고객 불만으로 인해 삼일 만에 실패했습니다. 실패한 구현은 다음과 같은 몇 가지 치명적인 결함을 겪었습니다:

  • 성능 병목: 앱은 과도한 로딩 스피너와 전역 JavaScript 상태에 의존했습니다.
  • 접근성 격차: 장애가 있는 사용자에게 애플리케이션이 접근 불가능했습니다.
  • 스토리지 관리 오류: 중요한 이미지 업로드가 localStorage에 저장되려고 시도되었는데, 이는 엄격한 5MB 제한이 있어 데이터 손실과 충돌을 초래했습니다.

HTML-First 접근 방식의 핵심 원칙

모든 가능한 사용자에게 서비스가 작동하도록 보장하기 위해, 사이트는 점진적 향상에 중점을 두고 Astro를 사용하여 재구축되었습니다. 이 아키텍처는 연결 품질이나 브라우저 나이와 관계없이 어떤 기계에서도 사이트가 작동해야 한다는 요구사항에 따라 안내되었습니다.

보편적 접근을 위한 기술적 요구사항

  • 고유 세션 ID: 모든 폼 세션에 진행 상황을 추적하기 위한 고유 ID가 할당되었습니다.
  • 서버 측 지속성: 업로드를 포함한 데이터는 폼 위저드의 모든 단계에서 백엔드에 저장되어 데이터 손실을 방지했습니다.
  • JavaScript 독립성: 폼은 JavaScript가 활성화되지 않아도 완전히 완료할 수 있었습니다.
  • 레거시 브라우저 지원: 사이트는 오래되고 성능이 낮은 웹 브라우저에서도 작동하도록 설계되었습니다.
  • 접근성 준수: 팀은 WCAG AA 표준을 준수했습니다.
  • 점진적 향상: 현대 CSS와 JavaScript는 핵심 기능의 요구 사항이 아닌 경험을 향상시키기 위해만 사용되었습니다.

구현: 폼 위저드와 검증

다중 페이지 폼 패턴

이 애플리케이션은 폼 위저드의 각 단계가 자체 페이지인 오래된 웹 패턴을 사용했습니다. 사용자가 '다음'을 클릭하면 폼이 서버로 제출되었고, API가 데이터를 검증하면 브라우저가 다음 단계로 리디렉션되었습니다. 이 접근 방식은 3G 연결을 사용하는 10년 된 모바일 기기를 통해 서비스에 접근할 수 있는 사용자에게 메가바이트 단위의 JavaScript를 전송하지 않도록 했습니다.

웹 컴포넌트를 통한 경량 검증

무거운 React 검증 라이브러리를 사용하는 대신, 개발자는 커스텀 HTML 웹 컴포넌트(나중에 validation-enhancer로 출시됨)를 구현했습니다. 이 컴포넌트는:

  1. 기존 HTML 폼을 감싸고 네이티브 브라우저 검증을 활용했습니다.
  2. 기본 브라우저 툴팁을 방지하고 대신 오류를 aria-describedby(또는 aria-errormessage) 요소에 배치했습니다.
  3. 사용자가 입력할 때 실시간으로 검증 오류를 지웠습니다.
  4. JavaScript가 실패하면 네이티브 브라우저 검증으로 폴백하고,さらに 백엔드 API 검증으로 폴백했습니다.

이 전체 검증 향상은 1KB 미만의 코드로 제공되었습니다.

결과 및 산업적 영향 분석

"보이지 않는 사용자" 현상

완료된 폼 수가 두 배로 늘면서 현대 원격 측정의 치명적인 결함이 드러났습니다: JavaScript 기반 분석 패키지는 JavaScript 오류로 인해 이탈한 사용자를 추적할 수 없습니다. 이러한 사용자는 근본적인 기술적 장벽이 제거될 때까지 개발자에게 효과적으로 보이지 않습니다.

커뮤니티 통찰과 반론

이 사례와 관련된 기술 논의는 "이력서 중심 개발"과 사용자 중심 엔지니어링 사이의 차이를 강조합니다:

  • 단순함의 사례: 많은 개발자가 대부분의 프로젝트에 HTMX, Go, SQLite 스택이 충분하다고 지적했으며, 산업은 빅 테크와 VC 자금의 영향으로 불필요한 복잡성으로 흘러가고 있다고 언급했습니다.
  • "좋은 디자인" 논쟁: 일부 비평가들은 성공이 HTML보다 React를 선택한 특정 요인이 아니라 더 나은 디자인과 유능한 개발자 때문이라고 주장했으며, React도 올바르게 구현된다면 접근 가능하고 성능 좋은 사이트를 구축하는 데 사용될 수 있다고 지적했습니다.
  • 접근성 의무: 정부 및 공공 서비스에서는 "lite" 폴백을 제공하는 것이 단순한 선호가 아니라 중요한 인프라에서 시민이 소외되지 않도록 보장하는 준법적 요구사항이라고 강조했습니다.

"당신의 JavaScript 기반 분석 패키지는 JavaScript 오류로 인해 이탈한 사용자를 볼 수 없습니다. 이 편견이 그들이 존재하지 않는다는 생각을 강화함으로써 매일 얼마나 많은 사람들이 중요한 시스템에서 소외되는지를 생각하는 것만으로도 두려울 정도.

결론

플레이스테이션 포터블과 3G 연결과 같은 최소 공통 분모를 대상으로 구축하면 서비스가 모든 사용자에게 작동하도록 보장됩니다. 클라이언트 사이드 프레임워크보다 HTML과 점진적 향상을 우선시함으로써 개발자는 더 넓은 청중에게 도달하고 수십 년간 기능 유지할 수 있는 시스템을 만들 수 있습니다.

Sources