다양한 사용자 및 기기를 대상으로 빌드할 때는 레이아웃 및 그래픽 디자인뿐만 아니라 콘텐츠도 고려하세요.
사용자가 웹에서 읽는 방식
미국 정부의 작성 가이드에서는 사용자가 웹에서 작성된 글에 원하는 바를 요약합니다.
연구에 따르면 사용자는 웹페이지를 읽지 않고 스캔합니다. 평균적으로 사용자는 웹페이지 콘텐츠의 20~28% 만 읽습니다. 화면에서 읽는 것은 종이에서 읽는 것보다 훨씬 느립니다. 정보에 쉽게 액세스하고 이해할 수 없다면 사용자는 포기하고 사이트를 떠납니다.
모바일용 글을 작성하는 방법
현재 주제에 집중하고 스토리를 미리 전달하세요. 다양한 기기 및 표시 영역에서 글을 작성하려면 시작 부분에 주요 요점을 전달해야 합니다. 일반적으로 처음 4개 단락에 70단어 내외로 작성하는 것이 좋습니다.
사용자가 사이트에서 원하는 바를 스스로에게 물어보세요. 사용자가 무언가를 찾으려고 하나요? 사용자가 정보를 얻기 위해 사이트를 방문하는 경우 모든 텍스트가 사용자가 목표를 달성하는 데 도움이 되도록 해야 합니다. 능동태로 작성하고, 작업과 솔루션을 제공하세요.
방문자가 원하는 것만 게시하고 그 이상은 게시하지 마세요.
영국 정부 연구에서도 다음과 같은 결과가 나왔습니다.
즉, 문해력이 있는 기술적 잠재고객을 대상으로 하더라도 일반 언어, 짧은 단어, 간단한 문장 구조를 사용하세요. 정당한 이유가 없는 한 대화형 어조를 유지하세요. 저널리즘의 오래된 규칙은 지능이 높은 11세 어린이에게 말하는 것처럼 작성하는 것입니다.
10억 명의 새 사용자 유치
간결한 작성 방식은 휴대기기 사용자를 대상으로 할 때 특히 중요하며, 스크롤이 더 많이 필요하고 디스플레이 품질이 낮고 화면 반응성이 떨어질 수 있는 작은 표시 영역의 저가형 휴대전화용 콘텐츠를 만들 때 매우 중요합니다.
온라인에 접속하는 10억 명의 새 사용자 중 대부분은 저렴한 기기를 사용할 것입니다. 이들은 장황한 콘텐츠를 탐색하는 데 데이터 예산을 사용하고 싶어 하지 않으며, 모국어로 읽지 않을 수도 있습니다. 텍스트를 다듬으세요. 짧은 문장, 최소한의 문장 부호, 5줄 이하의 단락, 한 줄 제목을 사용하세요. 반응형 텍스트 (예: 작은 표시 영역에 더 짧은 제목 사용)를 고려하되 단점을 주의하세요.
텍스트에 대한 미니멀리즘적 태도는 콘텐츠를 더 쉽게 현지화하고 국제화할 수 있도록 하며, 소셜 미디어에서 콘텐츠가 인용될 가능성을 높입니다.
요점:
- 항상 간결하게
- 깔끔한 화면
- 핵심 내용 전달
불필요한 콘텐츠 삭제
바이트 크기 측면에서 웹페이지는 크고 점점 더 커지고 있습니다.
반응형 디자인 기법을 사용하면 더 작은 표시 영역에 다양한 콘텐츠를 제공할 수 있지만, 항상 텍스트, 이미지, 기타 콘텐츠를 간소화하는 것으로 시작하는 것이 좋습니다.
웹 사용자는 좋은 책을 읽기 위해 뒤로 기대기보다는 현재 질문에 대한 답을 찾기 위해 '앞으로 기대는' 행동 지향적인 경우가 많습니다.
제이콥 닐슨
사용자가 내 사이트를 방문할 때 무엇을 달성하려고 하는지 스스로에게 물어보세요.
모든 페이지 구성요소가 사용자가 목표를 달성하는 데 도움이 되나요?
중복 페이지 요소 삭제
HTTP 보관에 따르면 HTML 파일은 평균 웹페이지의 요청 9개 이상에 거의 70KB를 구성합니다.
많은 인기 사이트에서 모바일에서도 페이지당 수천 개의 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를 제외한 모바일의 모든 브라우저에서 지원됩니다.
자세한 내용은 이미지 최적화 및 이미지 삭제 및 바꾸기를 참고하세요.
다양한 표시 영역 크기에서 잘 작동하도록 콘텐츠 디자인
'제품을 만들고, 작은 화면에 맞게 다시 상상하지 마세요. 훌륭한 모바일 제품은 포팅되는 것이 아니라 만들어집니다."
모바일 디자인 및 개발, 브라이언 플링
훌륭한 디자이너는 '모바일용으로 최적화'하지 않습니다. 다양한 기기에서 작동하는 사이트를 빌드하기 위해 반응형으로 생각합니다. 텍스트 및 기타 페이지 콘텐츠의 구조는 교차 기기 성공에 매우 중요합니다.
온라인에 접속하는 10억 명의 새 사용자 중 상당수는 작은 표시 영역의 저가형 기기를 사용합니다. 해상도가 낮은 3.5인치 또는 4인치 화면에서 읽는 것은 힘든 작업일 수 있습니다.
다음은 두 기기를 함께 찍은 사진입니다.
큰 화면에서는 텍스트가 작지만 읽을 수 있습니다.
작은 화면에서는 브라우저가 레이아웃을 올바르게 렌더링하지만, 텍스트는 확대해도 읽을 수 없습니다. 디스플레이가 흐릿하고 '부적절한 색조'가 있습니다. 흰색이 흰색으로 보이지 않아 콘텐츠를 읽기 어렵게 만듭니다.
모바일용 콘텐츠 디자인
다양한 표시 영역을 대상으로 빌드할 때는 레이아웃 및 그래픽 디자인뿐만 아니라 콘텐츠도 고려하고, 자리표시자 콘텐츠가 아닌 실제 텍스트와 이미지로 디자인하세요.
'콘텐츠가 디자인보다 우선합니다. 콘텐츠가 없는 디자인은 디자인이 아니라 장식입니다.'
제프리 젤드먼
- 사용자는 웹페이지를 F자 모양으로 읽는 경향이 있으므로 가장 중요한 콘텐츠를 상단에 배치하세요.
- 사용자는 목표를 달성하기 위해 사이트를 방문합니다. 목표를 달성하는 데 필요한 것을 스스로에게 물어보고 다른 모든 것을 삭제하세요. 시각적 및 텍스트 장식, 기존 콘텐츠, 과도한 링크, 기타 깔끔한 화면을 유지하세요.
- 소셜 공유 아이콘에 주의하세요. 레이아웃을 깔끔하게 유지할 수 있으며, 아이콘 코드로 인해 페이지 로드 속도가 느려질 수 있습니다.
- 콘텐츠에 반응형 레이아웃을 디자인하세요. 고정된 기기 크기가 아닙니다.
테스트 콘텐츠
- Chrome DevTools 및 기타 에뮬레이션 도구를 사용하여 더 작은 표시 영역에서 가독성을 확인하세요.
- 대역폭이 낮고 지연 시간이 긴 조건에서 콘텐츠를 테스트하세요. 다양한 연결 시나리오에서 콘텐츠를 사용해 보세요.
- 저가형 휴대전화에서 콘텐츠를 읽고 상호작용해 보세요.
- 친구와 동료에게 앱 또는 사이트를 사용해 보도록 요청하세요.
- 간단한 기기 테스트 실험실을 빌드하세요. Google의 Mini Mobile Device Lab의 GitHub 저장소에는 자체 빌드 방법에 관한 안내가 있습니다. OpenSTF는 여러 Android 기기에서 웹사이트를 테스트하기 위한 간단한 웹 애플리케이션입니다.
다음은 OpenSTF가 실제로 작동하는 모습입니다.
휴대기기는 통신, 게임, 미디어용 기기뿐만 아니라 콘텐츠를 소비하고 정보를 얻는 데에도 점점 더 많이 사용되고 있습니다.
따라서 다양한 표시 영역에서 잘 작동하도록 콘텐츠를 계획하고, 교차 기기 레이아웃, 인터페이스, 상호작용 디자인을 고려할 때 콘텐츠의 우선순위를 지정하는 것이 점점 더 중요해지고 있습니다.
데이터 비용 이해
웹페이지가 점점 더 커지고 있습니다.
HTTP 보관에 따르면 상위 100만 개 사이트의 평균 페이지 무게는 이제 2MB를 넘습니다.
사용자는 느리거나 비싸다고 인식되는 사이트 또는 앱을 피하므로 페이지 및 앱 구성요소 로드 비용을 이해하는 것이 중요합니다.
페이지 무게를 줄이면 수익을 창출할 수도 있습니다. YouTube의 크리스 자카리아스는 시청 페이지 크기를 1.2MB에서 250KB로 줄였을 때 다음과 같은 결과를 확인했습니다.
즉, 페이지 무게를 줄이면 완전히 새로운 시장을 열 수 있습니다.
페이지 무게 계산
페이지 무게를 계산하는 데 사용할 수 있는 도구는 여러 가지가 있습니다. Chrome DevTools 네트워크 패널에는 모든 리소스의 총 바이트 크기가 표시되며, 이를 사용하여 개별 애셋 유형의 무게를 확인할 수 있습니다. 브라우저 캐시에서 가져온 항목을 확인할 수도 있습니다.
Firefox 및 기타 브라우저에서도 유사한 도구를 제공합니다.
WebPagetest는 첫 번째 및 후속 페이지 로드를 테스트하는 기능을 제공합니다. 스크립트 (예: 사이트에 로그인) 또는 RESTful API를 사용하여 테스트를 자동화할 수 있습니다. 다음 예 (developers.google.com/web 로드)에서는 캐싱이 성공했으며 후속 페이지 로드에 추가 리소스가 필요하지 않음을 보여줍니다.
WebPagetest는 MIME 유형별로 크기 및 요청 분석도 제공합니다.
페이지 비용 계산
많은 사용자에게 데이터는 바이트와 성능 비용뿐만 아니라 금전적 비용도 발생합니다.
사이트 What Does My Site Cost?를 사용하면 사이트 로드의 실제 금전적 비용을 추정할 수 있습니다. 아래 히스토그램은 선불 데이터 요금제를 사용하여 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 데이터 요금제에도 일반적으로 차단되거나 제한되는 데이터 한도가 있습니다. 이러한 이유로 페이지에서 소비하는 데이터 양을 최대한 투명하게 공개하는 것이 좋습니다. 다음 블로그 게시물에서는 구체적인 권장사항을 제공합니다. 비용 투명성을 통한 신뢰도 제고
요점: 페이지 무게는 성능에 영향을 미치고 비용이 발생합니다. 콘텐츠 효율성 최적화에서는 비용을 줄이는 방법을 보여줍니다.