요즘 트위터에서 자주 언급되는 Progressive enhance에 대해 알아봅시다.
원문 주소입니다 : https://jjenzz.com/progressively-enhance-for-a-more-resilient-web
Progressively enhance for a more resilient web
There has been a lot of talk on the socials lately about progressive enhancement. Some good, some bad, and while the bad is often misled I get it.
jjenzz.com
최근 점진적 향상(progressive enhancement)에 대한 이야기가 많이 나오고 있습니다.
이 주제에 대한 교육 콘텐츠는 일반적으로 JavaScript 없이 작동하도록 만드는 데 중점을 둡니다.
멋지긴 하지만 JavaScript가 요즘 웹의 기본적인 부분이라는 반대론자들의 의견에 동의합니다.
그렇다면 JavaScript 없이 앱을 동작하도록 하는데 시간을 투자해야 하는 이유는 무엇입니까?
TLDR : 기준선으로 자바스크립트가 없을 시의 저하된 경험을 제공하고, JS와 함께 향상된 경험을 제공하자. 자바스크립트가 없는 1% 인터넷을 사용하는 사람들의 1%가 JavaScript를 비활성화했다는 의미는 아니라는 점을 분명히 하는 것으로 시작하겠습니다.
1%라는 숫자가 무섭게 들리지 않을 수도 있지만 큰 숫자의 1%는 많은 것입니다.
(13 million requests per month )
모니터링 결과 BuzzFeed에서 JavaScript에 대한 요청의 약 1%가 시간 초과되었음을 알 수 있습니다.
이 수치는 타임아웃된 JavaScript 요청만 나타냅니다.
아직 대부분의 브라우저가 지원하지 않는 새로운 브라우저 API 사용을 테스트하는 것을 잊었을 수 있습니다.
또는 일부 동적 코드가 존재하지 않는 배열 인덱스에 있는 객체의 속성에 액세스하려고 시도합니다.
또는 사용자에게 타사 추적기를 비활성화하는 브라우저 확장이 있고
우리는 로직에서
Sentry 를 항상 사용할 수 있다고 가정합니다.
TypeScript는 이러한 것들을 포착하지 못하지만
고맙게도 오류가 발생하는 모든 사용자 상호 작용은
브라우저를 JavaScript가 없는 환경으로 대체하여
웹 사이트를 계속 사용할 수 있도록 합니다.
아, 하지만 잠깐, BuzzFeed는 이렇게 할 수 없습니다 😢
아직 자바스크립트를 다운받지 못했잖아요...
BuzzFeed의 JavaScript 오류 수가 💭 몇개인지 궁금해지네요 ...
어쨌든, 계속 진행합니다.
"죄송합니다"라는
ErrorBoundary components 로 앱을 어지럽힐 수 있습니다.
또는 JavaScript를 비활성화하는 것에 대한 문제가 아니라 웹 사이트의 가용성에 관한 문제이기 때문에,
사용자의 fallback 경험에 미미한 시간을 할애할 수 있습니다.
JavaScript가 계속 시간 초과되거나 오류가 발생하여
사용자가 비행기 Wi-Fi에서 웹사이트를 사용할 수 없는 경우 웹사이트가 작동하지 않는다고 가정하고
다시는 돌아오지 않을 수 있습니다. .
모두 흥미로운 점이지만 당신 웹페이지의 1%가 단지 100회의 방문이라면 어떨까요? 신경 쓸 가치가 있는 일인가요? 예.
이것이 99%에게 중요한 이유
저는 21년 동안 웹 작업을 전문적으로 해왔습니다.
내가 웹을 시작했을 때, 점진적인 향상은 필수였기 때문에
많은 회사에서 그것을 직무 기술서에 요구했습니다.
분명히 브라우저가 너무 오래되었고 JavaScript가 없는 사용자 그룹이 훨씬 더 많았기 때문입니다.
점진적인 향상을 배우려면 시맨틱 마크업을 배워야 했고 JavaScript 오류가 발생했을 때 폴백 환경을 보장하기 위해
양식 작동 방식 및 더 많은 브라우저 기본 사항을 배워야 했습니다.
이 모든 것을 배운다는 것은 이미 향상된 경험을 가진 99%의 사람들도 혜택을 보았다는 것을 의미했습니다.
새 탭에서 열기 위해 CMD + 링크를 클릭할 수 있었고,
페이지를 탐색하기 위해 키보드의 탭 키를 사용할 수 있었고,
양식 상태를 유지하기 위해 불필요한 JavaScript 바이트를 다운로드할 필요가 없었고,
JS 번들이 우리 제품에 찾아올 때까지 기다릴 필요가 없습니다.
그것은 모두에게 더 접근하기 쉬운 경험을 보장했습니다.
그러나 우리는 점진적인 향상에 대해 많은 관심을 두지 않았습니다.
점진적 향상은 죽었다 웹 산업은 JavaScript 프레임워크로 옮겨갔고 이를 따라잡기 위해 저도 계속 나아가야 했습니다.
아무도 점진적인 향상에 대해 더 이상 신경 쓰지 않는 것 같았고
불행했지만 식탁에 음식을 올려야했습니다.
고맙게도 나는 여전히 가지고 갈 수 있는 접근 가능한/의미론적 페이지를 만드는 지식을 얻었지만,
컴포넌트 기반 아키텍처가 렌더링되는 마크업을 고려하지 않으며 합성을 장려하는 방법을 알아차리기 시작했습니다.
웹은 천천히 JavaScript를 사용하는 사람들이 사용할 수 없는 엉망이 되었습니다.
거대한 JS 번들이 로드를 완료할 때까지 제출되지 않는 양식, 링크용 div, 키보드 지원 없음 등은 교육 차원의 문제가 아니었습니다.
나는 이 모든 것을 배웠고 그것이 어떻게 작동하는지 알고 있지만 여전히 이러한 실수를 저질렀습니다.
더 최근에 나는 JavaScript를 사용하여 src 속성을 이미지에 첨부했는데,
이는 99%가 브라우저가 이미지 다운로드를 시작하기 전에 JavaScript가 로드되는 데 걸리는 시간을 더 기다려야 함을 의미했습니다.
1%는 이미지를 보지 못할 것입니다!
이것은 HTML이 초창기부터 지원한 것이며 여전히 99%의 경험을 악화시킬 수 있었습니다.
그래서 저는 점진적 향상이 그 1%를 지원하는 것만이 아니라는 것을 깨달았습니다.
100%의 사용자에게 더 성능이 좋고 사용 가능하며 복원력이 뛰어난 환경을 제공하기 위해
JavaScript 없이 앱을 테스트하는 것입니다.
점진적 향상의 재탄생
Remix 가 유료 베타 버전이었을 때, 마침내 누군가가 JavaScript 프레임워크 세계에 점진적인 향상을 가져오는 데 집중하고 있었기 때문에, 해당 제품을 사용해 볼 기회를 얻었습니다.
이전 프로젝트의 코드를 새 Remix 프로젝트로 가져오고
root.tsx에서 <Scripts /> 컴포넌트를 주석 처리하여 스크립트가 로드되지 않도록 했습니다.
내 코드에서 쉽게 개선할 수 있는 영역을 빠르게 발견했습니다(예: src 문제).
그런데
Combobox 용 자바스크립트가 없는 UI를 구축하는 데 몇 시간을 할애해야 했을까요?
그게 가능하긴 한가요?
접근성을 위한 모든 aria 속성과 role을 제공하려면 JavaScript가 필요합니다. 맞나요?
글쎄, 이것은 많은 사람들이 점진적 향상을 오해하는 것 같습니다.
점진적 향상은 JavaScript 없이 똑같은 UI를 제공해야 한다는 의미가 아닙니다.
향상된 경험은 더 좋아야 하고 더 많은 일을 해야 합니다.
그렇지 않으면 향상된 경험이 전혀 필요하지 않습니다.
또한 사용자의 저하된 경험을 향상히키고, 목표를 달성할 수 있도록 돕습니다.
예를 들어, 우편 번호를 텍스트 상자에 수동으로 입력하는 것은 저하된 환경 버전일 수 있습니다.
점진적 향상된 버전은 지리적 위치 데이터를 기반으로 텍스트 상자를 미리 채웁니다.
이 예를 보면 두 경험 모두 텍스트 상자가 필요하며,
저하된 경험을 만드는 데는 추가적인 노력이 필요 없다는 것을 알 수 있습니다.
향상된 경험을 점진적으로 적용할 수 있게 해주는 기준선입니다.
향상된 경험에 도움이 되지 않는 로직를 사용하여 완전히 별도의 UI를 구축하는 데 몇 시간을 보내고 있다면
아마도 잘못하고 있는 것입니다.
JavaScript를 사용할 수 있을 때 재사용할 수 있는 기본 환경을 구축하면 큰 노력이 필요하지 않습니다.
콤보박스를 다시 살펴봅시다.
콤보박스의 점진적 향상 콤보 박스의 경우 성능 저하로 인해 제안 데이터 없이 수동으로 입력하는 입력이 렌더링될 수 있습니다. 그게 다입니다.
또는 결과에서 선택하는 것이 중요한 경우 다음도 제공할 수 있습니다.
return (
<div className="combobox">
<form method="get" action="/api/some-data">
<input type="search" name="search" />
<button className="combobox__submit">Search</button>
</form>
<div className="combobox__results">
<ul>{/* ... */}</ul>
</div>
</div>
);JavaScript를 사용할 수 없는 경우 사용자는 양식을 action에 submit하고
JavaScript를 사용할 수 있는 경우 submit 버튼을 숨기고
접근성을 위한 aria 역할, 속성 및 키보드 기능을 추가하고
onSubmit 핸들러에서 event.preventDefault()를 사용하여 양식 action에 가져오기 요청을 합니다.
저하된 경험을 제공하기 위한 상당한 노력은 없습니다.
사실 대부분의 노력은 js가 아닌 모든 UI와 로직이 재사용되고 확장되는 향상된 경험 에 소비됩니다.
non-js 버전의 유일한 오버헤드는 우리가 숨긴 버튼입니다.
레이아웃 이동 JavaScript를 사용할 수 있게 되었을 때 요소를 숨기는 것은
JavaScript가 로드될 때 레이아웃 이동을 유발할 수 있기 때문에 점진적 향상에서 더 실망스러운 부분 중 하나입니다.
콤보 상자 예제에서 WAI-ARIA 예제의 화살표 버튼처럼 보이도록 스타일을 지정할 수 있으며 그러면 숨길 필요가 없습니다.
두 경험 모두에서 재사용되고 레이아웃 이동을 피할 수 있습니다.
탭은 어떻습니까? 우리는 탭 버튼을 아래 내용이 있는 제목 태그로 렌더링하여 처리했습니다.
JavaScript를 사용할 수 있게 되었을 때 모든 것을 탭 인터페이스로 축소했지만 이는 하나의 거대한 레이아웃 이동입니다.
대신 탭 버튼을 패널 ID에 연결하는 앵커로 변경하고 CSS를 약간 뿌리면 JS 없이 작동하는 탭을 갖게 됩니다.
모두 동일한 기준으로 향상된 경험이 필요하고 레이아웃 이동이 없습니다.
두 경험 모두에서 재사용할 수 있는 기준선을 제공하여 이와 같은 레이아웃 전환을 방지하는 방법을 생각하는 것이 좋습니다.
비슷한 경험을 유지하려고 할 때 인지된 어포던스를 고려하는 것이 중요합니다.
탭 컴포넌트에 대한 라디오 버튼 예제는 의도적으로 복사하지 않았습니다.
사용자가 인지하는 동작과 실제 기능이 다른 혼란을 가져오기 떄문입니다.
내 대안도 완벽하지 않습니다.
JS가 동작되고 탭이 탭 역할이 있는 탭 버튼처럼 보이도록 스타일이 설정되면,
키보드 및 스크린 리더 사용자는 탭에 JavaScript 오류가 있는 경우에는 사용할 수 없는 화살표 키를
사용할 수 있다는 것을 이해할 것입니다.
특히 JS 오류의 경우를 고려할 때 기능과 어포던스 일치를 유지하는 것이 항상 가능한 것은 아니지만
.has-js와 레이아웃 이동 피하기 레이아웃 변경 없이 재사용 가능한 기준선을 만드는 데 여전히 어려움을 겪고 있다면
<script>
document.body.classList.add('has-js');
</script>
이것을 문서의 초기에 삽입함으로써 아래 CSS를 사용하여 레이아웃 이동 없이 콤보박스 버튼을 숨길 수 있었습니다.
이것은 브라우저가 스크립트 파싱에 도달하고 JavaScript 인터프리터로 넘겨줄 때 문서 구문 분석을 중지하기 때문에 동작합니다.
문서의 나머지 부분을 구문 분석하기 전에 클래스를 추가합니다.
.has-js .combobox__submit {
display: none;
}
문서의 나머지 부분이 구문 분석되면 CSS는 버튼이 표시되지 않도록 합니다.
그러나 이것은 새로운 문제를 야기합니다.
콤보 상자 JavaScript 오류가 발생하면 버튼이 다시 나타날 수 없으므로
대체 버전을 향상된 버전에 통합하는 우선 순위를 지정하십시오.
다른 모든 방법이 실패할 경우 저하된 경험으로 인한
문제가 해결되지 않는다는 사실을 받아들이는 것이 좋습니다.
다시 말하지만, 보다 접근 가능하고 사용 가능하며 탄력적인 웹을 원한다면
점진적으로 향상된 경험을 목표로 하는 것이 전혀 고려하지 않는 것보다 낫습니다.
결론 점진적인 향상은, JavaScript를 비활성화하는 사람들을 지원하는 것 이상의 향상을 가져옵니다.
참고 https://developer.mozilla.org/ko/docs/Glossary/Progressive_Enhancement
점진적 향상 - 용어 사전 | MDN
점진적 향상은 가능한 많은 사용자에게 필수 콘텐츠와 기능을 제공하기 위한 설계 철학이다. 나아가 필요한 모든 코드를 실행할 수 있는 최신 브라우저 사용자에게 최상의 경험을 제공한다.
developer.mozilla.org
