반응형 디자인으로는 충분하지 않습니다. 반응형 성능이 필요합니다

최근에 성능 문제 가 많은 반응형 웹 사이트를 많이 접했습니다. 대부분의 경우 문제가 너무 명확하여 최신 스마트폰 외에는 거의 쓸모가 없습니다. 응답성이 개념으로서 더 많은 청중에게 다가간다는 사실을 고려할 때 이것은 오히려 역효과를 낳는다.

이 문제에 가장 크게 기여한 것은 여전히 ​​널리 퍼진 데스크탑 우선 설계 패러다임입니다. 모바일 우선의 관점에서 생각하면 문제가 해결되는 것처럼 보이지만 그것만으로는 만족스러운 성능을 보장할 수 없습니다. 우리 모두는 다소 우아한 저하에 너무 많이 의존하는 것 같습니다. 우리는 누락된 기능을 활성화하기 위해 심과 폴리필에 의존합니다. 우리는 빠른 개발을 가능하게 하고 브라우저 호환성이 문제가 될 때 우리를 지지하기 위해 라이브러리에 의존합니다.

“왜 걱정해?” 라고 물을 수도 있습니다. “방문객 대부분은 최신 OS 버전을 실행하는 고성능 스마트폰을 가지고 있습니다. 그들은 우리 사이트를 다룰 수 있습니다. 분석 결과가 그렇게 말하고 있습니다.”

무리한 주장에 대해 유감스럽게 생각합니다. 그러나 귀하의 사이트를 사용할 수 있는 사람들이 귀하의 사용자의 대다수가 될 것이라는 점을 큰 소리로 말할 가치가 있다고 생각합니다. 분석에 Android 2.3이 표시되지 않으면 해당 기기를 사용하는 사용자가 없다는 의미입니까? 아니면 귀하의 사이트가 해당 사용자에게 제공할 것이 없다는 의미입니까? 그 세대의 많은 장치가 오늘날에도 새 제품으로 판매되고 있다는 점을 고려하십시오. 과거의 기술이라고 완전히 무시해서는 안됩니다.

따라서 웹 개발의 이상적인 경우와 실제 목표에 대해 이야기하고 싶습니다. 그리고 그러한 목표에 더 가까이 다가가는 관행과 패러다임에 대해 이야기합니다.

벽돌 우선 설계 패러다임

연간 휴대폰 판매의 상당 부분은 여전히 ​​피처폰이 차지합니다. 훨씬 더 많은 인구가 매년 전화를 구매하지는 않지만 웹 지원 장치를 소유하고 있습니다. 이 숫자에 아직 사용 중인 마지막 세대 스마트폰을 추가하고 킨들 및 기타 웹 준 지원 장치(WAP 장치, TV, 토스터, 티셔츠 및 벽돌)를 추가하십시오. 그것들을 모두 더하면 엄청난 액수에 도달할 수 있습니다.

이 청중의 사용 사례를 고려하십시오. 그들은 장치에서 긴 기사를 읽거나 탐색하고 조사하지 않을 것입니다. 그러나 숫자 키보드로 URL을 입력하고 방향 키를 사용하여 페이지를 탐색하여 전화 번호를 얻거나 즉시 주소를 다시 확인하는 공포를 겪을 수 있습니다.

그렇다면 기능과 성능의 특정 임계값 미만의 장치에 해당 정보만 제공하는 모바일 우선 레이아웃을 구현하는 것이 얼마나 어렵습니까?

단계적 개선

최소한의 모범 사례로 점진적인 저하를 통해 우리는 그 너머에 있는 생각을 (어느 정도) 방해하는 포괄적인 원칙을 만들었습니다. 일단 우아한 저하가 발생하면 우리는 확실히 우리의 일이 완료되었으며 잘 수행되었다고 말할 수 있습니다. 사용 중인 다양한 프레임워크와 라이브러리에서 이미 다루었기 때문에 더 자주 생각할 필요조차 없습니다. 마지막으로 폴리필과 심은 경우에 따라 기능 저하의 필요성을 완전히 제거합니다.

이 기능을 점점 더 쉽게 사용할 수 있게 됨에 따라 (그 이상은 고사하고) 그것에 대해 생각할 필요가 점점 더 멀어집니다.

이 기사의 관점에서 보면 다음과 같이 나눌 수 있습니다.

부적절한 성능 저하: 기능을 쉽게 사용할 수 없는 경우 구현이 실패하여 사용할 수 없게 되거나 비현실적으로 사용할 수 있게 됩니다.

단계적 저하: 기능을 쉽게 사용할 수 없는 경우 여전히 허용 가능한 사용성을 가능하게 하는 방식으로 기능이 실패합니다.

부적절한 개선: 기능을 쉽게 사용할 수 없는 경우 폴리필 또는 shim에 의해 에뮬레이트됩니다.

거기에서 문제가 해결되었습니다.

동일한 로우 엔드 장치의 성능을 고려하지 않는 한 글쎄요.

어린 형제자매의 처리 능력과 데이터 기능이 부족하여 훨씬 더 많은 부하를 짊어져야 합니다. 폴리필을 솔루션으로 사용하면 모든 최신 기능을 이제 모든 장치에서 사용할 수 있고 걱정 없이 사용할 수 있다는 환상이 생깁니다.

그래서 만일을 대비하여 모든 것을 현대화하고 폴리필을 구현합니다. 성능이 가장 낮은 장치는 결국 가장 많은 양의 데이터를 로드하고 가장 많은 처리량을 수행합니다. 따라서 "최상의" 최종 사용자 경험을 보장합니다.

단계적 개선이라는 개념은 가장 낮은 기능 요구 사항부터 시작하여 장치 기능을 기반으로 성능-사용성 균형이 최적이 될 때까지 업그레이드를 로드함으로써 개념을 뒤집을 것입니다. 따라서 데이터 트래픽 및 처리 요구 사항은 이를 처리하는 데 가장 적합한 장치로 이동됩니다.

물론 현재로서는 개념이 엄청나게 복잡합니다. 대부분의 프레임워크와 라이브러리에서 지원하지 않고 대부분 논의되지 않으며 그러한 관행에 대한 언급이 거의 없고 멀리 떨어져 있으며 마이크로 기능에 국한되어 있습니다. 그러나 어느 시점에서는 모든 개념과 기능이 그런 식이었습니다.

그럴 수 있지만 꼭 그래야 합니까?

웹 개발의 또 다른 모범 사례는 기능을 활성화하기 전에 장치에서 기능을 사용할 수 있는지 확인하는 것입니다.

그러나 오래된 Android 휴대전화에 최신 버전의 Chrome을 설치할 수 있으며 CSS 애니메이션, WebGL, 배경 시차 효과 및 기타 여러 기능을 실행할 수 있다고 주장합니다. 그러나 그것은 정말로, 정말로 , 할 수 없습니다. 브라우저가 충돌하고 전체 장치가 응답하지 않게 되어 제어권을 되찾기 위해 재부팅해야 할 정도입니다.

이 문제는 최근에 Android 애플리케이션에 큰 영향을 미치기 시작했습니다(사용자 관점에서). 이러한 의미에서 가장 눈에 띄는 저하 중 하나는 이전 장치의 성능 문제로 인해 가장 가벼운 채팅 응용 프로그램에서 거의 사용할 수 없는 응용 프로그램으로 서비스를 전환한 Google 토크/행아웃 앱 업그레이드에 영향을 미쳤습니다. (이 점을 다시 한 번 강조합니다. 여기서 "오래된"은 거의 모든 상점에서 기성품으로 새 제품으로 구입할 수 있음을 의미합니다.) 동일한 문제가 YouTube 앱과 Twitter 앱(내 경험상) 및 분명히 다른 많은 앱에 영향을 미쳤습니다.

따라서 계획 단계의 어느 시점에서 첨단 구성보다 고성능 핵심 기능의 가치를 평가하십시오. 또는 최소한 레거시 사용자를 위해 어떤 형태로든 사용할 수 있는 앱/서비스/콘텐츠의 마지막 세대를 남겨두십시오. 말하자면…

사용자가 Bleeding Edge에서 옵트아웃하도록 허용

오래된 기기에서 또는 연결 상태가 좋지 않은 상태에서 Gmail을 사용하려고 시도한 적이 있습니까? "기본 HTML 로드" 링크는 확실히 유용합니다.

왜 당신의 최첨단 반응형 애니메이션 터치 지향 온라인 상점에는 그 기능이 없습니까?

생각해 보세요. 더 많은 잠재 고객에게 다가갈 수 있도록 반응형으로 요청했습니다. 최고의 첫인상을 남기기 위해 최첨단으로 만들었습니다. 결과적으로 잠재 고객은 귀하와 귀하의 서비스에 대한 기본 정보에도 도달할 수 없습니다. 우아한 개선이 너무 비용이 많이 드는 개념이라면 방문자의 장치에 "WOW" 버전이 너무 많은 경우 최소한 방문자에게 콘텐츠의 텍스트 전용 버전에 액세스할 수 있는 옵션을 제공하지 않으시겠습니까?

전체 라이브러리가 정말로 필요합니까?

마지막으로, 표준을 조금 넘어선 마지막 모범 사례는 "사용하거나 잃는 것"입니다. 어떤 라이브러리와 모듈이 실제로 사용 중인지 추적하고 이들만 포함하는 것은 때때로 지루하지만 모든 페이지에 전체 도구 세트를 유지하는 것은 엉성한 일입니다.

최근에 라이브러리를 포함하면 실제로 얼마나 많은 기능을 사용하는지 추적했습니다. 그리고 제가 가장 자주 사용하는 도구는 jQuery입니다. 종종 저는 $.extend 또는 $.ready와 같은 기능을 한두 가지만 사용하거나 더 나쁜 경우에는 클래스 또는 ID별로 요소를 가져오기 위해 사용했다는 것을 알게 됩니다. 때로는 그대로 두고 다른 경우에는 종속성을 제거하거나 분리하기 위해 코드를 다시 살펴봅니다.

라이브러리의 내용과 양을 자동으로 분석하고 결과에 따라 무게를 줄이면 깔끔하지 않을까요?

많은 라이브러리와 응용 프로그램은 사용을 시작하기 전에 로드아웃을 사용자 정의할 수 있는 옵션을 제공합니다. 그러나 우리 라이브러리에서 자동화된 "사용하지 않으면 사용하지 않는" 빌드 아키텍처를 표준화하는 것이 너무 멀리 떨어져서는 안 된다는 생각이 계속 듭니다.

나는 "모든 것을 포함" 접근 방식에 대한 알레르기가 있습니다. 그러나 이러한 기능과 함께 사용하면 접근 방식이 프로토타이핑 보드와 유사한 것으로 전환될 수 있습니다. 구문뿐만 아니라 실제 기능 자체도 축소되는 지나치게 유연한 개발 도구입니다.

필요한 것은 종속 기능의 단위 테스트를 통해 사용된 기능의 추적을 가능하게 하고 최소한의 종속성 또는 최소한의 활용도를 출력할 수 있는 개발 전용 버전의 라이브러리입니다. 기능 또는 80%). 그런 다음 종속성 출력을 사용하여 생산을 위한 출력을 선별, 집계 및 최소화할 수 있습니다.

하지만 그것에 대해 무엇을 할 수 있습니까?

우선 , 문제에 참여하십시오 . 그것에 대해 생각하고 동료와 토론하고 실제 시나리오에서 문제를 찾아보십시오.

시도해보십시오. 서랍 어딘가에 숨겨둔 마지막 세대 전화기를 꺼내십시오. 자신의 웹사이트에서 사용해 보고 콘텐츠가 원격에서도 사용 가능한지 확인하세요. 시골에 있는 시대에 뒤떨어진 친척을 방문하여 그들에게 기술 전도사가 되어 보십시오. 기술 채택의 지연이 실제로 접근성 문제로 인해 촉진되는지 확인하십시오.

웹사이트를 의뢰 하는 구매자라면 이 문제에 대해 (최소한) 낮은 수준의 지원을 요청해야 합니다. 기억하십시오: 목표는 저수준 장치에 대한 모든 기능의 전체 포트를 만드는 것이 아닙니다. 요구되는 것은 해당 사용자가 장치가 충돌하는 대신 귀하의 연락처 정보를 얻는 것뿐입니다.

이를 위해 실제 리소스를 따로 남겨두십시오. 문제에 대한 가장 간단한 솔루션은 하루나 이틀 이상 소요되지 않으며 약간의 진보적 사고가 필요합니다. 웹사이트를 처음부터 만드는 가장 기본적인 이유(반응형 사이트를 만드는 것은 말할 것도 없고)를 염두에 두십시오.

라이브러리, 프레임워크, 번들 또는 기타 포함 가능한 소프트웨어에서 작업 하는 패키지 개발자 라면 여기에서 가장 큰 차이를 만들 수 있는 사람은 바로 당신입니다. 이러한 개념을 촉진하거나 플랫폼에 통합할 수 있다면 웹 개발의 전체 환경에 영향을 미치게 될 것입니다. 패키지 디자인에 통합하면 알려주시면 복음을 전하겠습니다.

마지막으로 **개발자 또는 디자이너**라면 모범 사례에 그치지 마십시오. 항상 그 수평선 너머를 조금 보려고 노력하십시오. 고객과 사용자의 이익을 위해 지원되지 않고 문서화되지 않은, 아직 아무도 요청하지 않은 이러한 개념을 추진하기 위해 열심히 노력해야 합니다.

궁극적으로 누군가가 몇 시간 동안 이것에 대해 말하고 자그레브 근처에 있다는 것을 듣고 싶다면 저에게 알려주십시오. 우리는 커피 한 잔을 사러 갈 수 있습니다.