모바일에 최적화된 홈페이지제작

모바일 지원 웹 사이트를 만드는 데 어떤 기술이 가장 좋은지에 대한 논쟁이 있습니다. Google은 반응형 웹 디자인 제작을 옹호하는 반면, 유명한 사용성 컨설턴트인 Jakob Nielsen은 전용 모바일 사이트 제작을 지지합니다 (그러나 그는 이후 일부 웹 디자이너들로부터 비난을 받았습니다 ). 세 번째 옵션도 인기를 얻고 있습니다. 웹 서버는 사이트의 웹 페이지가 요청되는 장치에 따라 동일한 URL에서 적절한 HTML 및 CSS를 렌더링합니다( 반응형 디자인 + 서버측 구성 요소 라고 함). ).

이 기사에서는 이러한 각 방법에 대해 설명합니다. 특정 방법을 사용하는 웹사이트의 실제 사례가 각 섹션에 제공됩니다. 모든 예시에 대한 데이터를 테스트하고 수집하는 데 사용된 모바일 장치는 iOS 5.0을 사용하는 iPhone 4입니다.

반응형 웹 디자인(RWD)
반응형 웹 디자인 (RWD)은 일반적으로 CSS3 미디어 쿼리를 사용하여 사용자의 보기 영역 크기에 따라 웹 페이지의 레이아웃을 조정합니다.

동일한 HTML을 사용하여 데스크톱, 태블릿, 모바일 장치, TV 등에 대해 다른 웹페이지 레이아웃을 표시합니다.

반응형 웹 디자인의 장점
콘텐츠 패리티: 귀하의 사이트에는 사용 중인 장치에 관계없이 동일한 콘텐츠와 HTML 마크업이 포함되어 있어 사용자에게 유사한 경험을 제공합니다. 더 많은 사람들이 웹에 액세스하는 주요 수단으로 스마트폰을 사용함에 따라 이는 더욱 중요해질 것입니다.
웹페이지용 단일 URL: 이를 통해 콘텐츠를 더 쉽게 공유하고 연결할 수 있습니다. 장치를 최적화된 보기로 가져오는 데 리디렉션이 필요하지 않습니다(전용 모바일 사이트와 비교).
반응형 웹 디자인의 단점
콘텐츠가 휴대기기에 완전히 최적화되지 않습니다. 모바일 우선 접근 방식을 사용하지 않는 한 웹페이지에는 데스크톱과 동일한 정보가 포함됩니다. 이를 모바일 사용자만을 위해 웹페이지 콘텐츠를 맞춤화할 수 있는 별도의 모바일 사이트와 비교해 보세요.
느린 성능: HTTP Archive의 2013년 1월 데이터 에 따르면 오늘날 평균 웹 페이지는 약 1.3MB입니다 . RWD를 사용하면 불필요한 다운로드를 방지할 수 있지만 실제로 대부분의 반응형 웹 디자인 사이트는 크기가 동일하거나 더 큽니다. 모바일 성능 연구원인 Guy Podjarny가 테스트한 사이트의 86%는 모바일 사이트 성능에 대한 프레젠테이션 에서 보고된 바와 같이 크기가 동일하거나 더 컸습니다 .
사이트를 탐색하는 것이 더 어려울 수 있습니다. 모바일 사용자는 일반적으로 데스크톱 사용자와 다른 작업을 수행하기를 원합니다. 또한 모바일 전용 UI 디자인 패턴 에 더 익숙할 수도 있습니다 . 각 기기별로 네비게이션 구조를 맞춤화하지 않으면 사용성 문제가 발생할 수 있습니다.
반응형 웹 디자인의 예
스타벅스0319 02 스타벅스 반응형 웹 디자인스타벅스 웹사이트제작 반응형 웹 디자인의 장점과 단점을 보여주는 훌륭한 예입니다. 모든 콘텐츠는 모바일 장치에서 액세스할 수 있으며 각 페이지는 동일한 URL을 사용하며 리디렉션이 없습니다. 불행하게도 해당 사이트는 다운로드량이 많고(3G 스마트폰에서 약 15초) 전체 웹페이지를 읽으려면 많은 스크롤이 필요합니다.

전용 모바일 사이트
일부 웹사이트에서는 별도의 모바일 사이트를 만들어 모바일 장치 사용자의 경험을 최적화합니다. 가장 일반적인 구현은 데스크톱 웹사이트를 하위 도메인(예: .)으로 리디렉션하는 것 mobile.examplesite.com입니다 examplesite.com.

전용 모바일 사이트의 장점
모바일 사이트와 데스크톱 사이트를 별도로 변경하기가 더 쉬워졌습니다. 변경 사항은 모바일 버전 또는 데스크톱 버전으로만 제한될 수 있습니다.
더 빠른 로드 시간: 모바일 사이트용으로만 개발하고 있으므로 모바일 사용자 환경에 맞게 모바일 사이트를 간소화하고 최적화할 수 있습니다.
더욱 쉬워진 탐색: 탐색 구조와 콘텐츠는 모바일 사용자가 수행하는 작업에 맞게 맞춤화되었습니다.
모바일 전용사이트의 단점
각 페이지에 대한 여러 URL: 모바일 사용자는 모바일 URL을 공유하지만 데스크톱 사용자는 링크를 클릭하여 모바일 버전을 얻을 수 있기 때문에 소셜 미디어에서 웹 페이지를 공유하는 것이 문제가 됩니다. 중복된 콘텐츠 SEO 문제를 방지하려면 rel=”alternative”및 메타 태그를 사용해야 합니다 rel=”canonical”. 또한 모바일 사용자가 Google에서 검색하고 검색 엔진 결과에서 데스크톱 URL을 클릭하면 데스크톱 버전이 표시되거나 페이지의 모바일 버전으로 리디렉션됩니다.
이 페이지의 모바일 버전이 없으면 오류가 발생합니다.

다양한 콘텐츠 및 기능: 전용 모바일 웹사이트제작은 목적은 모바일 사용자를 위해 특별히 사이트를 맞춤화하는 것입니다. 이는 콘텐츠와 기능을 잘라내어 다른 경험을 제공한다는 의미일 수 있습니다.
콘텐츠 포크: 두 가지 서로 다른 콘텐츠 세트가 있어 콘텐츠 전략 악몽을 만들 수 있습니다.
리디렉션 필요: 모바일 사용자는 최적화된 보기로 리디렉션되어야 하며, 그 반대의 경우도 마찬가지입니다. 리디렉션으로 인해 페이지 로드 시간이 늘어납니다. 이는 사이트의 SEO에도 영향을 미칠 수 있습니다.
전용 모바일 웹사이트의 예
Walmart(mobile.walmart.com)월마트Walmart의 전용 모바일 사이트는 1.35초의 엄청나게 빠른 로드 시간을 자랑합니다. 성능 결과:

평균 로드 시간: 1.35초
평균 페이지 크기: 272.29KB
HTTP 요청 수: 45
Amazon (www.amazon.com/gp/aw/h.html)아마존Walmart와 마찬가지로 Amazon의 별도 모바일 페이지는 제가 테스트한 반응형 웹 디자인보다 빠릅니다(로드 시간은 2.25초였습니다). 그러나 이상한 점은 웹사이트제작의 모든 페이지가 모바일에 최적화된 버전이 아니라는 것입니다. 예를 들어, 스마트폰에서 Google 검색을 수행하면 Google 검색결과 중 다수가 모바일에 최적화된 버전으로 리디렉션되지 않는 데스크톱 페이지를 가리킵니다.

또한 데스크톱에서 직접 모바일 페이지에 액세스하는 경우 데스크톱 버전으로 리디렉션되지 않습니다. 성능 결과:

평균 로드 시간: 2.25초
평균 페이지 크기: 103.66KB
HTTP 요청 수: 16
BBC (www.bbc.co.uk/mobile)BBCBBC의 별도 모바일 페이지는 제가 테스트한 반응형 웹페이지(3.40초)에 비해 빠르지만, 그 시간의 거의 절반이 모바일 사용자를 모바일 페이지로 리디렉션하는 데 소요됩니다(1.65초). . Amazon의 별도 모바일 페이지와 달리 데스크톱에서 모바일 페이지에 액세스하면 자동으로 데스크톱 버전으로 다시 리디렉션됩니다. 성능 결과:

평균 로드 시간: 3.40초
평균 페이지 크기: 56.04KB
HTTP 요청 수: 22
전용 모바일 사이트의 리소스
조직의 모바일화에 관한 웹 세미나
Duda 모바일 웹사이트 빌더
모바일 감지
워플
장치 아틀라스
RESS: 동일한 URL의 다른 HTML 및 CSS
모바일 지원 웹 사이트를 만드는 이 방법은 서버 측 프로그래밍을 사용하여 다양한 장치에 대한 사용자 정의 CSS 및 HTML을 렌더링합니다. 모바일 사용자는 하나의 코드 세트를 받고, 데스크톱 사용자는 다른 코드 세트를 받게 됩니다. 이 구현의 주요 목적은 웹사이트 성능을 향상시키는 것입니다. 이 방법은 반응형 웹 디자인과 결합할 때 가장 잘 작동합니다.

이 구현을 반응형 웹 디자인 + 서버 측 구성 요소 ( RESS ) 라고 합니다 . 이 방법을 사용할 때 로봇이 데스크톱과 모바일 버전을 모두 크롤링할 수 있도록 Vary HTTP 헤더(스마트폰에 최적화된 웹사이트 구축에 대한 Google 가이드에서 이에 대해 읽어보세요)를 포함하는 것이 중요합니다.

RESS의 장점
더욱 쉬워진 탐색: 탐색 구조는 모바일 및 데스크톱 사용자가 수행하는 다양한 작업에 맞게 사용자 정의할 수 있습니다.
페이지 팽창 감소: 모바일 장치의 페이지 요소 에 의존 display: none;하거나 visibility: hidden;숨기는 대신 HTML 또는 CSS에서 제거할 수 있습니다. 이렇게 하면 다운로드되는 데이터의 양이 줄어들고 로드 시간이 빨라집니다.
더 빠른 로드 시간: HTML에서 불필요한 JavaScript를 제거하여 모바일 장치의 CPU, 메모리 및 캐시를 확보할 수 있습니다.
RESS의 단점
더 많은 서버 리소스: HTML을 동적으로 구축하면 서버의 로드가 늘어납니다.
장치 감지 필요: 모바일 사용자를 감지해야 합니다. 장치 감지가 신뢰할 수 없습니다.
RESS의 예
CNNCNN모바일 버전은 모바일 성능에 최적화된 HTML과 CSS를 사용하는 반면, 데스크톱 버전은 훨씬 더 많은 HTTP 요청과 JavaScript를 사용합니다. 탐색 기능도 모바일 관련 작업에 맞게 조정되었습니다. 성능 결과:

평균 로드 시간: 3.46초
평균 페이지 크기: 163.12KB
HTTP 요청 수: 28
eHoweHowCNN과 마찬가지로 eHow의 모바일 버전용 HTML 및 CSS는 성능에 맞게 조정되었습니다. 최상위 탐색 기능은 두 사이트 모두 동일하며 검색과 7개 콘텐츠 채널에 중점을 둡니다. 성능 결과:

평균 로드 시간: 6.15초
평균 페이지 크기: 188.95KB
HTTP 요청 수: 31
SlideShare슬라이드쉐어SlideShare의 모바일 버전과 데스크톱 버전은 완전히 다릅니다. 모바일 버전은 반응형 웹 디자인을 사용하지만 데스크톱 버전은 그렇지 않습니다. 각 사이트는 완전히 다른 HTML과 CSS를 사용합니다.

모바일 버전에는 JavaScript가 훨씬 적습니다. 또한 각 사이트는 서로 다른 탐색 구조를 사용합니다. 성능 결과:

평균 로드 시간: 6.15초
평균 페이지 크기: 188.95KB
HTTP 요청 수: 31
WordPress.com워드프레스닷컴WordPress.com의 모바일 및 데스크톱 버전은 몇 가지 차이점을 제외하고 거의 동일합니다.

모바일 버전에는 http-equiv속성이 있지만 데스크톱 버전에는 속성이 없습니다( <meta http-equiv=”x-ua-compatible” content=”IE=10″>).
그들은 각각 다른 스타일시트를 사용합니다.
모바일 버전은 태그 novalidate내에 속성을 배치하는 <form>반면 데스크톱 버전은 양식 내에 속성을 배치합니다.<input>
모바일 버전은 바닥글에 뉴스 링크가 있지만 데스크톱 버전은 페이지 어디에도 뉴스 링크가 없습니다.
일부 JavaScript가 모바일 버전에서 제거되었습니다.
성능 결과:

평균 로드 시간: 2.77초
평균 페이지 크기: 118.40KB
HTTP 요청 수: 19
RESS의 리소스
Drupal 사용자: Mobile Detect PHP 클래스를 사용하여 사용자 에이전트 감지를 처리할 수 있으며 Drupal Theme Switch는 모바일 장치에 최적화된 테마로 전환합니다. Vary HTTP 헤더 힌트를 HTTP 헤더에 추가하려면 drupal_add_http_header 함수를 사용하세요.
WordPress 사용자: 가장 쉬운 해결책은 WPTouch를 사용하는 것이지만 이 플러그인은 Vary HTTP 헤더를 추가하지 않습니다. 또는 Any Mobile Theme Switcher를 사용하여 모바일에 최적화된 테마로 전환할 수도 있습니다. WordPress 사이트의 HTTP 헤더를 수정하는 방법을 알아보세요 .
요약
이론적으로는 반응형 웹 디자인이 최고의 솔루션입니다. 그러나 실제로 대부분의 RWD 사이트는 최적으로 구현되지 않아 로드 시간이 느려집니다. 내 테스트에 따르면 전용 모바일 사이트를 사용하면 로드 시간이 가장 빨라지지만 이 구현에는 상당한 단점이 있습니다.

성능이 최우선인 경우에만 이 방법을 사용하겠습니다. 개인적으로 선호하는 것은 반응형 웹 디자인과 동일한 URL(RESS)의 다른 HTML을 조합하는 것입니다. 이는 두 가지 가장 큰 단점(다운로드할 파일이 많아지고 로드 시간이 느려짐)을 극복하는 동시에 RWD의 모든 이점을 제공합니다.

반응형 웹사이트를 디자인하는 데 도움이 필요한 경우 펜실베이니아주 해리스버그에 있는 WebFX를 확인하세요. 보트 딜러를 위해 수행한 작업은 다음과 같습니다 ! 모바일에 최적화된 사이트를 구축하기 위해 어떤 방법을 사용하고 있나요? 이 주제에 대한 의견을 댓글로 공유해주세요.