2022년 웹 개발에서 고려해야 할 환경 이라는 글을 읽게 되었다. ie의 퇴장 이후 웹 개발자가 초점을 맞춰야 하는 부분이 어느 부분인지에 대한 글인데, 최근 프로젝트에서 마주했던 부분도 있어서 기억하고자 내용을 정리한다.

브라우저

회사에서 신규 서비스를 개발할 때 가장 큰 패착이었던 부분이, 사파리를 신경쓰지 못했다는 것이다.
걍 진짜 사파리를 아예 생각을 못했다. 결국 최신 크롬을 기반으로 개발하다보니 사파리에서 지원되지 않는 api 등등이 너무 많아 QA 때 버그가 많이 터졌었다.
해당 부분은 프로젝트 회고에도 적었지만 앞으로 개발할 때 크롬이 아니라 사파리를 기반으로 개발해야겠다고 결심한 계기가 되었다.

원문에서도 사파리에 대한 이야기가 아래와 같이 나왔다.

• 사용자의 브라우저는 크게 크로니움 엔진 기반의 브라우저 (크롬, 삼브 등)와 웹킷 기반의 사파리로 나눌 수 있다.
• 둘 중 특히 유의깊게 살펴야 할 것은 웹킷 엔진, 사파리이다.
  • 사파리만 구현하지 않은 웹 표준의 수가 파폭/크롬보다 배로 많다 👿. (대략 파폭의 2배, 크롬의 4.5배)
  • 다른 브라우저는 OS와 독립적으로 업데이트 되지만 사파리는 ios가 업데이트 될 때만 업데이트 된다.
  • 즉, 더이상 ios 업그레이드 지원을 받지 못하는 기기의 유저는 뭔 짓을 해도 최신 버전 사파리를 이용할 수 없다.
  • ios에서 크롬을 써도 그건 크로니움 엔진 기반이 아니라 웹킷 엔진 기반이다. 이유는 애플의 지침 때문이다.
  • 원문에서 분석한 ios 시장 점유율에 의하면 최근 2년 이내의 사파리 버전만 신경써서 개발하면 나름 안심할 수 있다.

모바일 기기

최근 갤럭시 s22 시리즈가 공개되었는데, 2년 전 아이폰의 성능보다 벤치 점수가 낮다고 하여 화제가 되었었다.
그런데 원문에 등장한 그래프에 따르면 갤럭시 프리미엄 라인이 그정도인거고, 보급형 기기의 성능은 10년 전 아이폰 수준이라고 함.

• 안드로이드 보급형 기기의 성능에서 우리 사이트의 퍼포먼스가 어떤지 확인할 필요가 있다.

모바일 네트워크

• 와이파이 연결은 대개 안정적이나 모바일 네트워크는 꼭 그렇지만은 않다.
• 현대의 모바일 네트워크는 3G & 4G / 5G로 나뉘어져 있다.
  • 근 몇 년간 스마트폰 제조사들이 5G 기기만을 출시하고 각 통신사에서도 5G 가입자 유치를 위해 공격적인 보조금 지원을 하는 등 힘쓰고 있으나 아직 그 환경은 매우 열악하다.
  • 때문에 5G로 넘어가지 않고 4G에서 버티는 (나같은) 이용자들도 꽤 있음.
  • 게다가 원문에 따르면 글로벌 4G 가용성이 약 86.8%라고 함. 5G는 가용성이 가장 높은 한국에서도 약 29.1%.
  • 때문에 4G의 네트워크 속도를 기반으로 개발해야 함.

베이스라인

위에서 소개한 세 가지가 원문에서 말하는 2022 웹 개발을 위한 베이스라인이다.

1. 최근 2년 내 사파리 버전 지원 여부
2. 보급형 안드로이드 기기에서의 퍼포먼스
3. 4G 네트워크 속도 기반에서의 퍼포먼스

프레임워크/라이브러리의 JS 용량

1번의 크로스 브라우징 이슈를 제외한다면 결국 웹 성능이 주요한 이슈이다. (늘 언제나 그랬듯이)
원문에서는 우선 웹 사이트의 크기에서 대부분을 차지하는 JS의 용량을 줄이는 것에 주목한다.
JS 용량을 얼마나 줄여야할까? 그 기준점을 아래와 같이 소개하고 있다.

또한 위에서 언급했던 Alex Russell의 기사를 보면 4G 네트워크에서 Android 하위 기종을 테스트할 때 웹 사이트가 좋은 성능을 유지하기 위한 적정 크기는 HTML과 CSS는 최대 100KB, 그리고 JS는 최대 350KB입니다. 현재 중간값을 살펴볼 때 HTML과 CSS는 기준을 충족하지만 JS는 넘어서고 있습니다.

그런데 라이브러리 / 프레임워크를 쓰면 350KB 이하를 유지하는 것은 매우매우매우 힘들어 보인다. 현대 프론트엔드 개발에서 가장 많이 쓰이는 라이브러리 / 프레임워크는 리액트와 Next.js 일텐데 원문에서 소개한 비교 자료들을 보면 특히 리액트의 성적표가 낮다.
그 이유를 원문에서는 ie를 지원하기 위해 구현된 부분 때문이라고 보고 있다. 원문의 주제가 ie 퇴장 이후, 인 만큼 ie 지원을 위한 부분을 걷어낸다면 괜찮지 않을까? 하고 생각해본다.

접근성

프론트 웹 개발자는 접근성을 중요시 해야 한다.
약간 프론트 개발자들 사이에는 너무나 당연한 것으로 여겨지지만 다른 파트에게는 ‘왜 그래야 하는지’를 설명해야 하는데, 이번 프로젝트에서도 그렇고 이 접근성의 중요성에 대해 설득하는 것이 생각보다 어려웠다.
접근성을 준수해야하는 이유를 말했을 때 당장 다른 파트에서 얻을 수 있는 이익과 비교해보면 크게 현실성이 없기 때문에 어려운 것 같다.

원문에서 소개하는 접근성이란 단지 신체적/정신적 장애를 가진 사람 뿐만 아니라 일상 속에서 다양하고 흔하게 마주할 수 있는 상황 장애를 대상으로, 그럼에도 불구하고 우리 사이트와 온전하고 완전하게 상호 작용할 수 있게 하는 조치라고 소개한다.

상황적 장애의 몇 가지 예를 들면, 한 손으로 무언가를 먹거나 마시면서 휴대폰을 사용하거나, 수면의 질을 개선하기 위해 특정 시간 후에는 기기 화면에 흑백 필터를 설정하는 것 등이 있습니다. 이러한 상황적 장애 상황에 놓인 사용자는 접근성을 위한 설계 덕분에 마치 평소와 같이 웹 페이지를 이용할 수 있습니다.

최근 프로젝트에서 ios에서 루트 폰트 사이즈가 16px 이하일 때 인풋 포커스시 자동 줌 되는 기능을 제한하고자 핀치 줌을 제한했는데, 기획/디자인 상의 요청으로 처리를 하긴 했지만 아직도 그 결정에 대해선 찜찜하다.

결론

그래서 원문에서 이야기하는 22년 웹 개발 (이 블로그에서는 프론트 개발)의 지향점은 다음과 같다.

• 사용자를 위한 퍼포먼스 대응과 접근성 준수가 잘 이뤄지지 않았다.
  • 접근성은 개발 초기부터 고려하자.
• JS의 용량이 너무 거대하다
  • css로 할 수 있으면 js가 아니라 css로 하자.
    • 이 내용은 최근 프로젝트에서도 많이 겪었던 부분이다. 예를 들어 뷰포트마다 다른 스타일링을 해야할 때 css로 접근할 수 없어 js로 접근하는 그런 상황 같은 거… 이럴때마다 디자인 파트를 설득해야 하는지 (그러면 디자인을 제한하게 된다) 아니면 걍 js로 처리를 해야할지가 고민됐었다.
  • 이제 더 이상 ie를 지원하지 않아도 되므로, 최신 브라우저를 대상으로 빌드하여 번들 크기를 줄인다.
  • 사용하는 툴셋을 평가하자.