다양한 사용자와 기기용으로 빌드할 때는 레이아웃 및 그래픽 디자인뿐만 아니라 콘텐츠도 고려하세요.
웹에서 사람들이 독서하는 방식
미국 정부 작성 가이드에는 사람들이 웹에서 작성할 때 원하는 바가 요약되어 있습니다.
연구에 따르면 사람들은 웹페이지를 읽는 것이 아니라 스캔합니다. 평균적으로 사람들은 웹페이지 콘텐츠의 20~28% 만 읽습니다. 화면에서 읽는 것이 종이에서 읽는 것보다 훨씬 느립니다. 정보에 쉽게 액세스하고 이해할 수 없으면 사람들은 사이트를 포기하고 떠납니다.
모바일용으로 작성하는 방법
주제에 초점을 맞추고 솔직하게 이야기를 전하세요. 다양한 기기와 표시 영역에서 작동하도록 작성하려면 처음부터 핵심 사항을 전달해야 합니다. 일반적으로 처음 네 단락에서 70단어 정도로 작성하는 것이 가장 좋습니다.
사람들이 내 사이트에서 무엇을 원하는지 자문해 보세요. 무언가를 찾으려고 하나요? 사람들이 정보를 얻기 위해 사이트를 방문하는 경우, 모든 텍스트가 이들의 목표 달성에 도움이 되는 것이어야 합니다. 능동태로 작성하고 행동과 해결책을 제시합니다.
방문자가 원하는 내용만 게시하세요.
영국 정부 연구에서도 다음과 같은 사실을 확인했습니다.
다시 말해 평이한 언어, 더 짧은 단어, 간단한 문장 구조를 사용하세요. 문해력이 있는 기술 전문가들에게도 마찬가지입니다. 별다른 이유가 없다면 목소리의 어조를 대화체로 유지하세요. 저널리즘의 오래된 규칙은 똑똑한 11살 어린이에게 말하듯이 쓰는 것입니다.
새로운 10억 명의 사용자
간결하게 작성하는 방법은 휴대기기 독자에게 특히 중요하며, 표시 영역이 작아 더 많이 스크롤해야 하고 화면 품질이 낮고 화면이 덜 반응하는 저가 휴대폰용 콘텐츠를 만들 때 매우 중요합니다.
앞으로 온라인에 접속하는 10억 명의 사용자 대부분은 저가의 기기를 보유할 것입니다. 장황한 콘텐츠를 탐색하는 데 데이터 예산을 지출하고 싶어 하지 않으며 모국어로 글을 읽지 못할 수 있습니다. 텍스트 자르기: 짧은 문장, 최소한의 구두점, 5줄 이하의 단락, 한 줄의 제목을 사용합니다. 반응형 텍스트를 사용하는 것이 좋습니다 (예: 작은 표시 영역에는 더 짧은 헤드라인 사용). 하지만 단점에 유의하세요.
텍스트에 미니멀한 태도를 취하면 콘텐츠를 현지화하고 국제화하기가 더 쉬워지며, 콘텐츠가 소셜 미디어에서 인용될 가능성도 높아집니다.
결론:
- 간결하게 만들기
- 깔끔한 화면
- 핵심 내용 전달
불필요한 콘텐츠 삭제
바이트 크기 측면에서 웹페이지가 점점 더 커지고 있습니다.
반응형 디자인 기술을 사용하면 작은 표시 영역에도 다양한 콘텐츠를 게재할 수 있지만, 항상 텍스트, 이미지 및 기타 콘텐츠를 간소화하는 것이 좋습니다.
웹 사용자들은 보통 좋은 책을 읽기 위해 몸을 기대기보다는 행동지향적입니다.
잭콥 닐슨
스스로에게 물어보세요. 사람들이 내 사이트를 방문할 때 무엇을 달성하고자 하는가?
모든 페이지 구성요소가 사용자의 목표 달성에 도움이 되나요?
중복된 페이지 요소 삭제
HTTP Archive에 따르면 평균 웹페이지에는 약 7만 개의 HTML 파일과 9개 이상의 요청으로 구성됩니다.
많은 인기 사이트에서는 심지어 모바일에서도 페이지당 수천 개의 HTML 요소와 수천 줄의 코드를 사용합니다. HTML 파일 크기가 과도하다고 페이지 로드 속도가 느려지지는 않을 수도 있지만, HTML 페이로드가 과다하면 콘텐츠 팽창의 신호일 수 있습니다. .html 파일이 클수록 요소가 많거나 텍스트 콘텐츠가 많거나 둘 다 많아집니다.
또한 HTML 복잡성을 줄이면 페이지 크기가 줄어들고, 현지화 및 국제화에 도움이 되며, 반응형 디자인을 더 쉽게 계획하고 디버그할 수 있습니다. 더 효율적인 HTML 작성에 관한 자세한 내용은 고성능 HTML을 참고하세요.
사용자가 앱에서 가치를 얻기 전에 수행하는 모든 단계마다 사용자의 20% 가 손실됩니다.
가보르 셀레, 트위터
콘텐츠 역시 마찬가지입니다. 사용자가 원하는 것을 가능한 한 빨리 찾을 수 있도록 해야 합니다.
모바일 사용자의 콘텐츠를 단순히 숨기지는 마세요. 콘텐츠 동등성을 목표로 하세요. 모바일 사용자가 놓치지 않을 기능을 추측하는 것은 실패하게 될 것입니다. 리소스가 있는 경우, 다른 표시 영역 크기에 맞는 동일한 콘텐츠의 대체 버전을 만드세요. 이는 우선순위가 높은 페이지 요소에만 해당하는 경우에도 마찬가지입니다.
콘텐츠 관리와 워크플로를 고려하세요. 기존 시스템이 레거시 콘텐츠를 생성하나요?
텍스트 단순화
웹이 모바일로 이동하면 작성 방식을 변경해야 합니다. 간결하게 만들고 불필요한 요소를 줄여 핵심을 전달하세요.
중복 이미지 삭제
이미지는 아름답고, 재미있고, 유익할 수 있지만, 페이지 공간을 차지하고, 페이지 무게를 증가시키고, 파일 요청 수를 증가시키기도 합니다. 연결이 나빠지면 지연 시간도 악화됩니다. 즉, 웹이 모바일로 전환됨에 따라 과도한 이미지 파일 요청이 문제가 되고 있습니다.
이미지는 전력도 소모합니다. 배터리를 가장 많이 소모하는 항목이 화면 다음으로 두 번째로 많습니다. 이미지 요청이 많을수록, 무선 사용량이 증가하며 배터리가 더 빨리 소진됩니다. 단순히 이미지를 렌더링하는 것만으로도 전력이 소모되며, 이는 크기와 수에 비례합니다. 스탠포드 보고서 Who Killed My Battery?를 확인해 보세요.
가능하면 이미지를 제거하세요.
다음은 몇 가지 제안사항입니다.
- 이미지를 완전히 피하는 디자인을 고려하거나 이미지를 적게 사용하는 디자인을 고려하세요. 텍스트만으로도 멋질 수 있습니다. 스스로에게 질문해 보세요. '내 사이트를 방문한 사용자가 무엇을 달성하고자 하는가? 이미지가 이 과정에 도움이 될까요?"
- 예전에는 제목과 기타 텍스트를 그래픽으로 저장하는 것이 일반적이었습니다. 이 접근 방식은 표시 영역 크기 변경에 제대로 반응하지 않으며 페이지 크기와 지연 시간을 증가시킵니다. 또한 텍스트를 그래픽으로 사용하면 검색엔진에서 텍스트를 찾을 수 없으며 스크린 리더 및 기타 보조 기술로 액세스할 수 없습니다. 가능하면 '실제' 텍스트를 사용하세요. 웹 글꼴과 CSS로 멋진 서체를 만들 수 있습니다.
- 모든 최신 브라우저에서 지원되는 그라데이션, 그림자, 둥근 모서리, 배경 텍스처에 이미지 대신 CSS를 사용하세요. CSS가 이미지보다 나을 수 있지만, 모바일에서는 특히 처리 및 렌더링에 관한 불이익이 있을 수 있습니다.
- 배경 이미지는 모바일에서 잘 작동하지 않습니다. 미디어 쿼리를 사용하여 작은 표시 영역에서 배경 이미지를 피할 수 있습니다.
- 스플래시 화면 이미지를 피합니다.
- UI 애니메이션에 CSS 사용
- 글리프를 파악합니다. 필요한 경우 이미지 대신 유니코드 기호 및 아이콘을 웹 글꼴과 함께 사용하세요.
- 아이콘 글꼴을 고려해 보세요. 이러한 글꼴은 무한 확장이 가능한 벡터 그래픽이며, 전체 이미지 세트를 하나의 글꼴로 다운로드할 수 있습니다. 하지만 이러한 문제에 유의하세요.
<canvas>요소를 사용하면 JavaScript로 선, 곡선, 텍스트, 기타 이미지로부터 이미지를 빌드할 수 있습니다.- 인라인 SVG 또는 데이터 URI 이미지는 페이지 크기를 줄이지는 않지만 리소스 요청 수를 줄여 지연 시간을 줄일 수 있습니다. 인라인 SVG는 모바일 및 데스크톱 브라우저에서 잘 지원되며 최적화 도구로 SVG 크기를 크게 줄일 수 있습니다. 마찬가지로 데이터 URI는 잘 지원됩니다. 둘 다 CSS에서 인라인 처리할 수 있습니다.
- 애니메이션 GIF 대신
<video>을 사용하는 것이 좋습니다. 동영상 요소는 모바일의 모든 브라우저에서 지원됩니다 (Opera Mini는 제외).
자세한 내용은 이미지 최적화 및 이미지 제거 및 바꾸기를 참고하세요.
다양한 표시 영역 크기에서 잘 작동하도록 콘텐츠 디자인
"제품을 만드세요. 작은 화면을 위해 제품을 재구성하지 마세요. 뛰어난 모바일 제품은 만들어지는 것이지, 이식되는 것이 아닙니다.'
모바일 디자인 및 개발, 브라이언 플링
훌륭한 디자이너는 '모바일에 최적화'하지 않고 다양한 기기에서 작동하는 사이트를 반응형으로 구축하려고 합니다. 텍스트와 기타 페이지 콘텐츠의 구조는 교차 기기에서 성공을 거두는 데 매우 중요합니다.
새로운 온라인 사용자 중 상당수는 표시 영역이 작은 저가의 기기를 사용합니다. 저해상도의 3.5인치 또는 4인치 화면에서는 읽기가 어려울 수 있습니다.
다음은 두 제품이 함께 있는 사진입니다.
큰 화면에서는 텍스트가 작지만 읽기 쉽습니다.
작은 화면에서는 브라우저가 레이아웃을 올바르게 렌더링하지만 확대하더라도 텍스트를 읽을 수 없습니다. 디스플레이가 흐릿하고 '컬러 캐스트'(흰색이 흰색처럼 보이지 않음)가 발생하므로 콘텐츠의 가독성이 떨어집니다.
모바일용 콘텐츠 디자인
다양한 표시 영역에 맞게 빌드할 때는 레이아웃 및 그래픽 디자인뿐만 아니라 콘텐츠도 고려하세요. 자리표시자 콘텐츠가 아닌 실제 텍스트와 이미지로 디자인합니다.
"콘텐츠는 디자인보다 우선합니다. 콘텐츠가 없는 디자인은 디자인이 아니라 장식입니다."
제프리 젤드먼
- 사용자는 F자 형태로 웹페이지를 읽는 경향이 있으므로 가장 중요한 콘텐츠를 맨 위에 배치합니다.
- 사용자는 목표를 달성하기 위해 사이트를 방문합니다. 그 목표를 달성하기 위해 무엇이 필요한지 스스로에게 물어보고 그 외 모든 것은 제거하세요. 시각적 장식과 텍스트 장식, 레거시 콘텐츠, 과도한 링크 및 기타 지저분한 콘텐츠는 피하세요.
- 소셜 공유 아이콘에 주의하세요. 이러한 아이콘은 레이아웃을 복잡하게 만들 수 있고 코드로 인해 페이지 로드가 느려질 수 있습니다.
- 고정된 기기 크기가 아닌 콘텐츠의 반응형 레이아웃을 디자인합니다.
테스트 콘텐츠
- Chrome DevTools 및 기타 에뮬레이션 도구를 사용하여 작은 표시 영역에서 가독성을 확인하세요.
- 낮은 대역폭 및 긴 지연 시간 조건에서 콘텐츠를 테스트합니다. 다양한 연결 시나리오에서 콘텐츠를 사용해 보세요.
- 저렴한 휴대전화에서 콘텐츠를 읽고 상호작용해 보세요.
- 친구와 동료에게 내 앱이나 사이트를 사용해 보도록 요청합니다.
- 간단한 기기 Test Lab을 빌드합니다. Google Mini Mobile Device Lab의 GitHub 저장소에서 나만의 기기를 만드는 방법을 확인할 수 있습니다. OpenSTF는 여러 Android 기기에서 웹사이트를 테스트하기 위한 간단한 웹 애플리케이션입니다.
다음은 OpenSTF의 작동 모습입니다.
휴대기기는 커뮤니케이션, 게임, 미디어뿐 아니라 콘텐츠를 소비하고 정보를 얻는 데 점점 더 많이 사용되고 있습니다.
따라서 다양한 표시 영역에서 제대로 작동하는 콘텐츠를 계획하고 교차 기기 레이아웃, 인터페이스 및 상호작용 디자인을 고려할 때 콘텐츠의 우선순위를 정하는 것이 점점 더 중요해지고 있습니다.
데이터 비용 이해
웹페이지가 점점 더 커지고 있습니다.
HTTP Archive에 따르면 현재 상위 100만 개 사이트의 평균 페이지 용량은 2MB를 넘습니다.
사용자는 느리거나 비싸다고 여겨지는 사이트나 앱을 회피하므로, 페이지 및 앱 구성 요소를 로드하는 데 드는 비용을 이해하는 것이 중요합니다.
페이지 크기를 줄이는 것도 수익을 창출할 수 있습니다. YouTube의 Chris Zacharias는 보기 페이지 크기를 1.2MB에서 250KB로 줄였을 때 다음과 같은 사실을 발견했습니다.
즉, 페이지 크기를 줄이면 완전히 새로운 시장을 개척할 수 있습니다.
페이지 용량 계산
페이지 크기를 계산하는 다양한 도구가 있습니다. Chrome DevTools Network 패널에는 모든 리소스의 총 바이트 크기가 표시되며 개별 애셋 유형의 가중치를 확인하는 데 사용할 수 있습니다. 브라우저 캐시에서 가져온 항목을 확인할 수도 있습니다.
Firefox와 다른 브라우저에서도 유사한 도구를 제공합니다.
WebPagetest는 첫 번째 페이지 로드와 이후의 페이지 로드를 테스트하는 기능을 제공합니다. 스크립트 (예: 사이트 로그인) 또는 RESTful API를 사용하여 테스트를 자동화할 수 있습니다. 다음 예 (developers.google.com/web 로드)는 캐싱이 성공했고 후속 페이지 로드에 추가 리소스가 필요하지 않음을 보여줍니다.
WebPagetest는 또한 MIME 유형별로 크기와 요청을 분류하여 제공합니다.
페이지 비용 계산
많은 사용자에게 데이터는 단순히 바이트와 성능에만 영향을 미치는 것이 아니라 비용도 소모합니다.
내 사이트 비용은 어떻게 되나요? 사이트에서 사이트 로드에 들어가는 실제 비용을 예측할 수 있습니다. 아래의 히스토그램은 amazon.com을 로드하는 데 드는 비용 (선불 데이터 요금제 사용)을 보여줍니다.
수입과 관련된 경제성은 고려하지 않습니다. blog.jana.com의 데이터는 데이터 비용을 보여줍니다.
| 500MB 데이터 요금제 비용 (USD) |
시간당 최저 임금 (USD) |
500MB 데이터 요금제 지불 시간 |
|
| 인도 | $3.38 | $0.20 | 17시간 |
| 인도네시아 | $2.39 | $0.43 | 6시간 |
| 브라질 | $13.77 | $1.04 | 13시간 |
페이지 크기는 신흥 시장에서만 문제가 아닙니다. 많은 국가에서 데이터가 제한된 모바일 요금제를 사용하며, 사이트나 앱이 무겁고 비싸다고 생각되면 회피합니다. '무제한' 모바일 데이터 및 Wi-Fi 데이터 요금제도 일반적으로 데이터 한도가 있으며 이 한도를 초과하면 차단되거나 제한됩니다. 따라서 페이지에서 사용하는 데이터의 양을 최대한 투명하게 공개하는 것이 가장 좋습니다. 다음 블로그 게시물에서 구체적인 권장사항을 확인하세요. 비용 투명성을 통한 신뢰 구축
결론: 페이지 크기는 성능에 영향을 미치고 비용도 든다는 것입니다. 콘텐츠 효율성 최적화에서 비용을 절감하는 방법을 확인할 수 있습니다.