모바일-체커

모바일 체커

휴대전화에서 예약 페이지가 얼마나 잘 작동하는지 100점 만점으로 평가합니다. 동일한 고정 평가 기준을 매번 사용하며, 각 수정 항목이 회복할 수 있는 점수에 따라 우선순위가 매겨진 수정 목록을 제공합니다. 설치나 코드가 필요 없습니다. 페이지 링크, 휴대전화 스크린샷, Google의 무료 PageSpeed Insights 도구에서 얻은 수치만 제공하면 됩니다. 페이지에 광고나 이메일 트래픽을 보내기 전, 리디자인 후, 또는 대부분의 방문자가 휴대전화를 사용하는데 예약 전화가 줄어들었을 때 사용하세요. 랜딩 페이지, 비디오 판매 레터(VSL) 페이지, 신청 페이지, 또는 메인 사이트의 홈페이지 등 예약 전화로 이어지는 모든 페이지에 적합합니다. 캘린더 도구에서 호스팅하는 페이지는 단독으로 평가되지 않으며, 해당 페이지로 연결되는 페이지의 예약 경로로 확인됩니다.

시작하기 전에

1. 이 프로젝트나 채팅에 비즈니스 컨텍스트 파일이 있는지 확인하세요. 있다면 먼저 읽고 다음 정보를 추출하세요: 예약 페이지 링크, 페이지가 판매하는 제안, 주요 버튼에 표시되어야 할 문구, 캘린더 또는 예약 도구, 페이지 빌더, 페이지를 편집하는 사람(본인 또는 개발자), 방문자 유입 경로(광고, Instagram, LinkedIn, 이메일), 그리고 알려진 경우 모바일 방문자 비율.
2. 이미 링크가 있고 웹 검색 또는 웹 가져오기가 활성화되어 있다면, 질문(3단계)하기 전에 먼저 페이지를 직접 여세요. 그러면 페이지 소스가 여전히 필요한지 알 수 있습니다.
3. 여전히 누락된 것에 대해서만 물어보세요. 모든 질문은 하나의 메시지에 담고, 각 질문에는 짧은 이유를 함께 제시하세요. 다음 이상을 요청하지 마세요:
   • 실제 페이지 링크. 페이지를 읽을 수 있고, PageSpeed가 편집기 미리보기가 아닌 실제 페이지를 테스트할 수 있도록 하기 위함입니다. 링크가 캘린더 도구에서 호스팅하는 페이지인 경우, 사람들을 그 페이지로 보내는 페이지를 요청하세요. 없는 경우 6단계의 "호스팅된 캘린더 페이지"를 참조하세요.
   • 스크린샷에 사용된 휴대전화 모델. 화면 너비에 따라 텍스트 줄바꿈과 버튼의 실제 크기가 달라집니다.
   • 주요 작업. 페이지에 둘 이상의 버튼이 있는 경우 어떤 버튼이 "예약"으로 간주되는지.
   • 휴대전화 스크린샷. 일반 스크린샷, 긴 캡처 하나가 아닙니다. 한 메시지에 모두 담을 수 없으면 첫 번째 메시지에 페이지를 보내고 나머지는 두 번째 메시지에 보내세요. a. 첫 화면: 로드된 그대로, 스크롤 없이, 브라우저 바가 보이는 상태. 이미지 하나. b. 전체 페이지: 한 번에 한 화면씩 스크롤하고 매번 일반 스크린샷을 찍어, 각 화면의 약 1/5이 다음 화면 상단에 다시 보이도록 합니다. 메시지당 최대 약 12장; 페이지가 더 길면 나머지는 다음 메시지에 보내세요. 선택 사항, 글자 읽기 전용: iPhone Safari "전체 페이지" PDF 또는 Android "스크롤 캡처". c. 예약 경로: 주요 버튼을 탭하고 최종 확인 버튼까지의 모든 단계를 스크린샷으로 찍습니다. 최대 약 5장. 거기서 멈추세요. 실제 예약이 광고 픽셀(Meta와 Google에서 리드 또는 예약된 통화로 간주), CRM 연락처 및 파이프라인 단계 추가, 확인 문자 및 이메일 발송, 팀 알림, 설정자 또는 AI 에이전트 통화를 트리거한다는 점을 수락하는 경우에만 제출하세요. 취소는 노쇼 또는 취소 시퀀스를 시작할 수 있습니다. 제출하는 경우: 2주 이상 후의 슬롯을 선택하고, TEST라고 표시된 이름이나 이메일을 사용하며, 먼저 팀에 알리고, 바로 취소하세요. d. 팝업: 페이지가 여는 모든 팝업, 열려 있는 동안 찍은 것. e. 인앱 브라우저: Instagram DM(또는 프로필 또는 광고에서)으로 페이지 링크를 자신에게 보내고 Instagram 또는 Facebook 인앱 브라우저 내에서 예약 경로를 탭하세요. Safari 또는 Chrome과 다르게 보이거나 작동하는 단계를 스크린샷으로 찍으세요. 대부분의 소셜 트래픽이 여기에 도달하며, 예약 페이지가 가장 자주 깨지는 곳입니다.
   • PageSpeed 수치, 스크린샷 2장. "PageSpeed Insights"를 검색하고, 실제 링크를 붙여넣고, 모바일을 선택하고, 실행하세요. 상단의 실제 사용자 데이터가 아닌 실험실 섹션("진단 성능 문제")을 캡처하세요: 성능 점수, LCP, CLS, TBT, 접근성 점수, 그리고 성능, 접근성, 모범 사례 아래의 실패 항목 이름과 "예상 절감량".
   • 페이지 소스, 직접 페이지를 읽을 수 없는 경우에만. 컴퓨터에서: 페이지를 열고, 마우스 오른쪽 버튼을 클릭하고, 페이지 소스 보기를 선택하고, 저장한 후 .txt 파일로 업로드하세요. 채팅에 붙여넣지 마세요: 페이지 빌더 소스는 1MB를 초과할 수 있습니다. 아직 링크가 없으면 이 항목을 선택 사항으로 나열하세요("링크에서 페이지를 읽을 수 없으면 두 번째 라운드를 절약할 수 있습니다").
4. 지체하지 마세요. 가지고 있는 증거로 입증할 수 있는 것을 점수화하고, 나머지는 "확인되지 않음"으로 표시하며, 확인에 가장 많은 점수를 추가할 수 있는 누락된 입력 하나를 지정하세요. PageSpeed 수치가 없으면 55점이 확인되지 않은 상태로 남아 있으므로, 먼저 그것들을 요청하세요.

작동 방식

단계를 순서대로 수행하세요. 전체적으로 평이한 용어를 사용하고, 기술 용어는 처음 사용할 때 한 번 정의하세요.

1단계. 휴대전화 크기 설정

평가 기준은 작은 휴대전화(375 x 812 CSS 픽셀)를 기준으로 만들어졌습니다. CSS 픽셀은 웹 페이지가 구축되는 단위입니다. 휴대전화 스크린샷은 CSS 픽셀당 2~3.5개의 실제 픽셀을 가집니다.

휴대전화	CSS 너비
iPhone SE, 12 mini, 13 mini	375
iPhone 12 이상, 표준 및 Pro	390 ~ 402
iPhone Plus, Air, Pro Max	420 ~ 440
대부분의 Android 휴대전화	360 ~ 412

• 배율 = 스크린샷 너비(픽셀)를 CSS 너비로 나눈 값(보통 iPhone에서는 3). 스크린샷의 모든 길이를 배율로 나누면 CSS 픽셀이 됩니다.
• 한 화면 = 모든 휴대전화에서 812 CSS px. 3x iPhone에서는 2436 스크린샷 픽셀입니다. 실제 스크린샷은 브라우저 바가 공간을 차지하기 때문에 그보다 적은 페이지를 보여줍니다: 육안으로, 스크린샷 하나는 약 0.8~0.9 화면입니다. E2, E5 및 모든 화면 수에 812를 사용하여 점수가 휴대전화와 실행 간에 비교되도록 합니다.
• 위치: 반복되는 스트립을 일치시켜 겹치는 스크린샷을 쌓고, 각각이 페이지 맨 위(주소 표시줄 바로 아래)부터 CSS px로 표시하는 새 페이지 높이를 더한 다음 812로 나누어 화면 수를 구합니다. 코드로 측정하지 않는 한 "추정"이라고 표시하세요.
• 텍스트 열(C) = 본문 텍스트 한 줄의 전체 너비(CSS px). 측정하세요. 측정할 수 없으면 휴대전화 CSS 너비에서 40을 뺀 값을 사용하세요.
• 넓은 휴대전화는 텍스트를 375px 평가 기준 폰보다 적은 줄로 감쌉니다. 넓은 휴대전화에서 제목이나 단락이 줄 제한에 딱 맞으면 한 줄 초과로 계산하세요.
• 코드 실행이 켜져 있으면 스크린샷을 열어 픽셀 크기를 측정하세요. 그렇지 않으면 육안으로 판단하고 줄에 "추정"이라고 표시하세요.

2단계. 속도 수치 읽기(A, B, C 섹션 및 D10 라인)

PageSpeed 모바일 실험실 수치를 사용하세요. 평이한 용어로 설명하세요:

• LCP(가장 큰 콘텐츠풀 페인트): 첫 화면에서 가장 큰 요소(히어로 이미지, 비디오 포스터 또는 제목)가 표시를 완료하는 시간.
• CLS(누적 레이아웃 이동): 페이지가 로드되는 동안 얼마나 많이 점프하는지. 엄지손가락 아래에서 버튼을 움직이는 점프는 예약 손실로 이어집니다.
• TBT(총 차단 시간): 페이지가 탭에 반응하기에는 너무 바쁜 시간. Google의 탭 응답 측정 기준인 INP를 대신합니다.

PageSpeed는 실행 간에 몇 포인트 변동합니다. 숫자가 점수 기준선 3포인트(또는 0.3초) 이내에 있으면 증거 열에 그렇게 명시하고 재확인 시 세 번 실행하여 중간 값을 사용하도록 요청하세요. 모범 사례 아래 "브라우저 오류가 콘솔에 기록되었습니다"는 D10 실패를 의미합니다. 항상 실제 페이지를 테스트하고 편집기 미리보기는 절대 테스트하지 마세요. 미리보기는 실제 호스트가 통과하는 압축 및 캐싱 검사에 실패합니다. 각 실패 항목에 대한 PageSpeed의 "예상 절감량"을 유지하세요. 이는 7단계에서 속도 작업의 순서를 결정합니다.

3단계. 페이지 소스 읽기

웹 가져오기 또는 웹 검색이 켜져 있으면 페이지 링크를 열고 HTML을 읽으세요. 많은 페이지 빌더가 JavaScript로 페이지를 그리므로 가져오기는 대부분 스크립트를 반환할 수 있습니다. 그런 다음 업로드된 소스가 있으면 사용하고, 없으면 스크린샷에 의존하고 HTML 전용 라인을 "확인되지 않음"으로 표시하세요. 소스가 약 150KB를 넘고 코드 실행이 켜져 있으면 전체를 읽는 대신 아래 항목을 검색하세요. 코드 실행이 꺼져 있고 파일이 너무 커서 전체를 읽을 수 없으면 확인 가능한 것을 확인하고 나머지는 "확인되지 않음"으로 표시하세요.

다음 항목을 찾고 각 항목이 공급하는 라인을 기록하세요:

• 뷰포트 태그: width=device-width (D1) 및 viewport-fit=cover (D6).
• 모든 img: width 및 height 또는 CSS 종횡비(D5)가 있어야 합니다. 히어로 이미지는 실제 img인가요 아니면 CSS 배경인가요? loading="lazy"로 잘못 설정되었나요? (속도 작업)
• 모든 iframe: loading="lazy" 및 300px 이상의 설정된 높이(D5, E6). 로드 시 YouTube 또는 Vimeo iframes가 있거나, 탭 시 플레이어를 로드하는 썸네일이 있는지(D7).
• autoplay가 있지만 muted가 없는 video 태그(D7).
• CSS에서: safe-area-inset(D6), prefers-reduced-motion 및 :focus-visible(D9), 그리고 본문 텍스트, 문단, 레이블, 캡션의 font-size(D4). 외부 스타일시트는 전달되지 않을 수 있습니다. CSS를 볼 수 없으면 해당 라인을 "확인되지 않음"으로 표시하세요.
• 보이는 양식 필드: input(숨겨지지 않은 것), select, textarea 개수(E6).
• 경쟁 목적지(E3): 다른 제안, 다른 제품 또는 체크아웃, 소셜 프로필에 대한 링크, 페이지에 탐색 메뉴가 있는지 여부.
• async 또는 defer 없이 head에 있는 스크립트. 두 그룹으로 정렬하세요: 채팅 위젯, 히트맵, 세션 레코더(기다릴 수 있음) 및 광고 픽셀, 전환 태그, 분석(도착 시 로드됨)(속도 작업).

대용량 파일을 검색하려면 다음을 찾으세요: viewport, <img, <iframe, <video, <input, <select, <textarea, safe-area, prefers-reduced-motion, focus-visible, font-size, <a href, <nav>, 그리고 <head> 내부의 <script> 태그.

4단계. 스크린샷 읽기

먼저 무엇을 받았는지 확인하세요. 3화면보다 긴 단일 캡처(전체 페이지 PDF 또는 스크롤 캡처)를 받은 경우, 그 위치를 읽지 마세요. 코드 실행이 켜져 있으면 화면 높이 타일로 자르고 각각을 살펴보세요. 꺼져 있으면 겹치는 스크린샷을 요청하고, 그동안 위치가 필요한 라인(D3, D4, E2, E4, E5, E7)을 "확인되지 않음"으로 표시하세요. 그래도 그 단어와 버튼 레이블은 읽을 수 있습니다.

페이지를 위에서 아래로 살펴보세요:

• 첫 화면 (E1): 헤더나 고정 막대에 있지 않고 페이지 자체에 있는 첫 번째 예약 버튼을 찾으세요. 실제 첫 번째 스크린샷에서 평가합니다. 스크롤 없이 완전히 보여야 통과합니다. 브라우저 바에 의해 잘렸지만 그 하단이 여전히 페이지 상단에서 812 CSS px 이내에 있으면 통과합니다. 추가 발견 사항 "휴대전화 브라우저 바에 의해 가려짐"을 추가하세요.
• 가로 스크롤 (D2): 오른쪽 가장자리에서 콘텐츠가 잘리거나, 가로 스크롤바가 있거나, 페이지가 축소되어 보입니다. 사용자에게 옆으로 스와이프해 보라고 요청하세요.
• 탭 대상 (D3): 페이지 자체의 모든 링크와 버튼(푸터 링크 포함), 단 임베디드 캘린더 내부의 버튼은 제외(5단계). 44 CSS px는 화면 너비의 약 1/9입니다. 24px는 약 1/16입니다. 푸터의 텍스트 링크와 인라인 "개인정보" 또는 "약관" 링크가 일반적인 실패 사례입니다.
• 텍스트 크기 (D4): CSS가 글꼴 크기를 제공하면 그것을 사용하세요. 정확합니다. 스크린샷으로만 판단할 경우, 본문 텍스트의 전체 너비 줄에 있는 문자(글자, 공백, 구두점) 수를 세고 텍스트 열 C와 비교하세요:
  • 약 C/8자 이하: 16px 이상, 통과.
  • 약 C/7.3 초과: 16px 미만, 실패.
  • 약 C/6.2 초과: 12px에 가깝거나 미만.
  • 375 폰(C 약 335)에서: 42 이하 통과, 46 이상 실패, 54 이상은 12에 가깝습니다. 43~45는 사진으로 판단하기에 너무 애매합니다. D4의 그 절반을 "확인되지 않음"으로 남겨두고 CSS를 요청하세요.
  • 작은 글씨도 확인하세요: 레이블, 캡션, 버튼 보조 텍스트, 날짜. 모든 스크린샷 결과에 "추정"이라고 표시하세요.
• 제목 (E4): 주요 제목(H1)과 가장 긴 섹션 제목(H2)의 줄 수를 세세요.
• 증거 (E5): 첫 번째 로고 행, 사용 후기, 고객 결과 또는 리뷰가 페이지 상단에서 몇 화면 아래에서 시작하는지.
• 버튼 (E2, E3): 모든 예약 버튼을 화면 위치와 정확한 문구와 함께 나열하세요. 고정 막대가 있으면 기록하세요. 버튼 간 가장 큰 간격(마지막 버튼에서 페이지 끝까지의 간격 포함)을 측정하세요.
• 이탈 (E3): 메뉴, 소셜 아이콘, 다른 제안, 제품 또는 체크아웃에 대한 링크를 기록하세요.
• 문단 (E7): 모든 문단 중 6줄을 초과하는 문단의 수를 세세요.

5단계. 예약 경로 탐색

탭스루 스크린샷에서, 먼저 Safari 또는 Chrome에서, 그 다음 인앱 브라우저에서:

• 캘린더 시간이 나타나기 전 화면에 있는 양식 필드 수를 세세요(E6). 단계로 나뉜 양식은 가장 긴 단계를 계산합니다.
• 캘린더 내부의 작은 탭 대상(시간 슬롯, 요일 셀, 월 화살표)은 점수를 매기지 않습니다. 페이지 소유자가 크기를 조정할 수 없기 때문입니다. 추가 발견 사항 아래에 도구 수준의 수정과 함께 나열하세요: 캘린더 도구의 모바일 레이아웃을 켜거나, 임베드 대신 호스팅된 예약 페이지에 링크하세요.
• 팝업의 경우: 화면 너비에 맞는지, 명확한 닫기 버튼이 있는지, 뒤에 있는 페이지가 움직이지 않는지 확인하세요. 사용자에게 열린 팝업 뒤로 스크롤을 시도해 보라고 요청하세요(D8).
• 인앱 브라우저: 각 단계를 Safari 또는 Chrome과 비교하세요. 일반적인 중단점: 임베디드 캘린더가 빈 화면으로 로드됨, 팝업 또는 새 탭이 차단됨, Google 로그인이 거부됨, 리디렉션이 멈춤. 모든 중단점은 "예약 경로" 아래 상단에 배치하세요. 예를 들어 "Instagram 인앱 브라우저에서 중단됨: 캘린더 빈 화면". 점수를 추가하거나 라인을 변경하지 않습니다.
• 평가 기준에 해당 라인이 없더라도 예약을 중단시키는 다른 모든 것을 기록하세요: 키보드가 제출 버튼을 가림, 잘못된 시간대 표시, 단계가 로드되지 않음. 중단된 예약 경로는 점수 위의 보고서 맨 위에 배치됩니다.
• 확인 화면 (추가 발견 사항): 사용자가 테스트 예약을 제출한 경우 명확한 확인 화면이 표시되었는지 말하세요. 그렇지 않으면 "제출되지 않음"이라고 쓰세요.

6단계. 모든 라인 점수 매기기

이 평가 기준을 정확히 사용하세요. 총 100점입니다. 각 라인의 출처를 표시하세요: PS(PageSpeed), HTML, Shot(스크린샷), Test(탭스루), Est.(스크린샷에서 추정), Not checked(확인되지 않음), 또는 N/A.

라인	확인 사항	최대	채점 방식
A1	PageSpeed 모바일 성능 점수	30	90 이상 = 30. 50 이하 = 0. 그 사이: 30 x (점수 - 50) / 40
B1	LCP 2.5초 이하	7	4.0초 이상 = 0. 그 사이: 7 x (4.0 - LCP) / 1.5
B2	CLS 0.1 이하	4	0.25 이상 = 0. 그 사이: 4 x (0.25 - CLS) / 0.15
B3	TBT 200ms 이하	4	600ms 이상 = 0. 그 사이: 4 x (600 - TBT) / 400
C1	PageSpeed 모바일 접근성 점수	10	90 이상 = 10. 50 이하 = 0. 그 사이: 10 x (점수 - 50) / 40
D1	뷰포트 태그에 width=device-width 포함	3	있으면 3점. 없으면 0점.
D2	가로 스크롤 없음	4	없으면 4점. 스크롤하면 사용자가 스와이프할 수 있지만 알 수 없음 = 2. 있으면 0.
D3	모든 탭 대상이 44 CSS px 이상	3	모두 44 이상이면 3. 하나라도 24px 미만이면 0. 그 사이: 3 x (대상의 24 이상 비율)
D4	본문 텍스트 16px 이상	4	16px 이상 = 4. 12px 미만 = 0. 그 사이: 4 x (글꼴 크기 - 12) / 4
D5	느리게 로드되는 이미지가 없으며(위치 보존) 모든 이미지에 종횡비 있음	3	모든 이미지가 loading="lazy" 없음 또는 크기 비율 있음(위치 보존) = 3. 하나라도 loading="lazy" 또는 크기 비율 없음 = 0.
D6	viewport-fit=cover 및 safe-area-inset 사용됨	3	두 가지 모두 사용됨 = 3. 하나만 사용 = 1. 둘 다 없음 = 0.
D7	비디오가 자동 재생되지 않거나 음소거됨(모바일 데이터 절약 및 배터리 고려)	3	autoplay 비디오가 없거나 모두 muted = 3. 음소거되지 않은 autoplay 비디오 있음 = 0.
D8	팝업이 화면에 맞으며 페이지 고정	3	맞고 고정됨 = 3. 그렇지 않음 = 0.
D9	prefers-reduced-motion 및 :focus-visible 지원	2	둘 다 = 2. 하나만 = 1. 없음 = 0.
D10	브라우저 콘솔 오류 없음	1	없음 = 1. 있음 또는 알 수 없음 = 0.
E1	실제 첫 화면에 예약 버튼 표시	4	예 = 4. 아니오 = 0.
E2	버튼 간 1.5 화면 이상 간격 없음	3	1.5 미만 = 3. 1.5 이상 = 0.
E3	경쟁하는 이탈 지점(메뉴, 다른 제안 링크) 없음	3	없음 = 3. 있음 = 0.
E4	주요 제목이 2줄 이하, 섹션 제목이 3줄 이하	3	둘 다 통과 = 3. 하나만 통과 = 1. 둘 다 실패 = 0.
E5	신뢰 증거가 첫 1.5 화면 내에 표시	3	예 = 3. 1.5 화면 이후 = 1. 없음 = 0.
E6	예약 경로 시작 전 양식 필드 5개 이하	3	5개 이하 = 3. 6~8개 = 2. 9개 이상 = 0.
E7	문단의 30% 미만이 6줄 초과	3	30% 미만 = 3. 30% 이상 = 0.

7단계. 통계와 우선순위 파생

기준 숫자. 세 가지 숫자를 계산하고 각각 "표준"이라고 표시하세요. 점수의 일부가 아닙니다. 방문자가 페이지를 빨리 떠나지 않도록 하려면 먼저 이러한 기준을 충족하세요.

• 페이지 소스 크기: A1 아래에 기록하고, 최대 권장치는 300KB(압축됨)입니다.
• 첫 번째 바이트까지의 시간(TTFB): 압축된 쪽에서, 0.8초가 양호합니다. PageSpeed나 브라우저 DevTools에서 확인하세요. 이 숫자는 실행마다 크게 변동합니다.
• 총 HTTP 요청: 50개 미만을 목표로 합니다. PageSpeed의 진단에서 확인하세요.

분석. 각 라인을 점수에 기여하는 네 가지 동인 중 하나에 연결하세요. 각 동인의 합계를 계산하고 라벨을 붙이세요.

동인	포함된 라인
속도	A1, B1, B2, B3, D5, D10
장치 핏	D1, D2, D4, D6, D8, E2
접근성	C1, D3, D7, D9
메시지 명확성	E1, E3, E4, E5, E6, E7

각 동인의 점수 비율과 동인 우선순위를 함께 표시하세요.

수정 우선순위:

1. 중단됨: 5단계의 모든 예약 경로 중단. (0점 회복, 순서의 맨 위에 배치)
2. 누락됨: 0점 또는 거의 0점이고 큰 가중치를 가진 라인. (PageSpeed 라인이 가장 많은 점수를 회복할 수 있음)
3. 가까움: 점수 기준선에 가깝지만 실패한 라인(예: A1이 48점으로 50에 근접). 적은 노력으로 점수를 회복할 수 있음.
4. 빠른 승리: 약간의 변경으로 일정 점수를 회복할 수 있는 라인(예: D2: CSS overflow-x: hidden).
5. 천천히: 많은 노력이 필요한 라인(예: 전체 리디자인).

각 동인에 대해 가장 큰 영향을 미치는 하나의 수정을 제공하세요.

8단계. 보고서 출력

다음 구조를 정확히 따르세요. "미확인" 입력을 맨 위에 언급하고, 점수, 각 동인에 대한 분석 및 작업 항목, 우선순위 수정 목록(점수 회복량 기준), 추가 발견 사항(평가 기준에 포함되지 않은 항목) 및 다음 단계 순서를 포함하세요. 마크다운을 사용하여 섹션을 구조화하고 강조하세요.