โครงสร้างหน้าเว็บบนมือถือและเดสก์ท็อป

ตรวจทานล่าสุด พฤศจิกายน 2026

ผู้อ่านตัดสินใจได้เร็วว่าหน้าข่าวหน้าหนึ่งคุ้มกับการอยู่ต่อหรือไม่ พาดหัวควรขึ้นเร็ว หน้าเว็บควรนิ่ง และทุกการแตะควรได้รับการตอบสนอง Google ยังจัดทำดัชนีจากเวอร์ชันมือถือของหน้าเว็บของคุณ เลย์เอาต์บนโทรศัพท์จึงเป็นเวอร์ชันที่นับสำหรับ Search ด้วย

ตัวเลขที่ควรตั้งเป็นเป้า

Core Web Vitals ของ Google ให้เกณฑ์วัดสามอย่าง พร้อมเป้าหมายที่ชัดเจนสำหรับแต่ละอย่าง

วัดที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้า โดยนับมือถือและเดสก์ท็อปแยกกัน หน้าเว็บจะผ่านเมื่อตัวชี้วัดทั้งสามถึงเป้าหมายที่เปอร์เซ็นไทล์นั้น

ใช้ข้อมูลภาคสนามจากการเข้าชมจริง ได้แก่ รายงาน Core Web Vitals ใน Search Console, PageSpeed Insights หรือ Chrome User Experience Report Lighthouse มีประโยชน์ในห้องทดสอบ แต่วัด INP ไม่ได้ และรายงาน Total Blocking Time แทน

Google ระบุว่าไม่มีสัญญาณ page experience เพียงสัญญาณเดียว แต่ระบุว่าระบบจัดอันดับของ Google ใช้ Core Web Vitals และด้านอื่นของ page experience ไม่ได้ช่วยให้เว็บไซต์ติดอันดับโดยตรง แม้ยังทำให้ใช้งานได้ดีขึ้นก็ตาม

หน้าเดียวสำหรับทั้งสองหน้าจอ

Google แนะนำการออกแบบแบบ responsive เพราะเป็นรูปแบบที่ทำและดูแลง่ายที่สุด HTML เดียวกันใช้กับทุกอุปกรณ์ เนื้อหาและเมทาดาทาจึงตรงกันโดยไม่ต้องทำเพิ่ม หากคุณใช้หน้ามือถือแยกต่างหาก ให้คงสิ่งเหล่านี้ให้เหมือนเดสก์ท็อป

• เนื้อหาหลัก
• หัวข้อ
• ข้อมูลแบบมีโครงสร้าง
• แท็ก robots meta (noindex ที่หลุดเข้ามาอาจทำให้หน้ามือถือไม่ถูกจัดทำดัชนี)

เริ่มจากแท็ก viewport แล้วตรวจว่าหน้าเว็บจัดเรียงใหม่ได้ที่ความกว้าง 320 CSS พิกเซลโดยไม่ต้องเลื่อนไปด้านข้าง

<meta name="viewport" content="width=device-width, initial-scale=1">

บนมือถือ

• วางพาดหัว ชื่อผู้เขียน และวันที่ที่มองเห็นได้ไว้ก่อน แล้วตามด้วยภาพนำหรือย่อหน้าแรก
• เก็บเนื้อหาบทความไว้ใน HTML ปุ่ม “อ่านต่อ” ที่ดึงส่วนที่เหลือมาเมื่อแตะ อาจซ่อนเนื้อหานั้นจาก Google ซึ่งไม่คลิก ปัด หรือพิมพ์
• ทำเป้าสัมผัสให้ได้อย่างน้อย 24 คูณ 24 CSS พิกเซล ซึ่งเป็นขั้นต่ำของ WCAG 2.2 AA สำหรับเมนูและปุ่มปิด ให้ตั้งเป้า 44 คูณ 44 ซึ่งเป็นระดับ AAA
• ทำส่วนหัวแบบติดหน้าจอ (sticky) ให้เตี้ย และตั้ง scroll-padding-top เท่าความสูงของส่วนหัว เพื่อไม่ให้ลิงก์ที่โฟกัสอยู่ถูกบัง

บนเดสก์ท็อป

• ให้ข้อความเนื้อหามีไม่เกิน 80 ตัวอักษรต่อบรรทัด หรือ 40 สำหรับภาษาจีน ญี่ปุ่น และเกาหลี นี่คือแนวทาง WCAG ระดับ AAA และช่วยผู้อ่านทุกคน
• ตั้งระยะห่างบรรทัดอย่างน้อย 1.5 ภายในย่อหน้า
• วางเนื้อหาเสริมไว้ในแถบข้างที่ไม่ดันบทความเมื่อโหลด

โหลดเร็วขึ้น

องค์ประกอบที่ใหญ่ที่สุดในหน้าข่าวมักเป็นภาพนำ ให้ถือว่าเป็นคำขอที่สำคัญที่สุดของหน้า

<img
  src="/images/lead-1200.jpg"
  srcset="/images/lead-800.jpg 800w, /images/lead-1200.jpg 1200w"
  sizes="(min-width: 768px) 720px, 100vw"
  width="1200"
  height="675"
  alt="Describe what the photo shows"
  fetchpriority="high">

• อย่าทำ lazy-load กับภาพ LCP
• ใส่ไว้ใน HTML เริ่มต้น เพื่อให้เบราว์เซอร์พบก่อนที่สคริปต์ใดจะทำงาน
• ใช้ fetchpriority="high" กับภาพไม่เกินหนึ่งหรือสองภาพ มากกว่านั้นไม่ช่วยอะไร
• ใช้ loading="lazy" เฉพาะภาพและ iframe ที่อยู่นอกวิวพอร์ตแรก
• ลดการรีไดเรกต์ และทำให้หน้าแคชได้ พารามิเตอร์ URL ที่ไม่ซ้ำกันอาจส่งคำขอกลับไปที่เซิร์ฟเวอร์ต้นทางแทน CDN

หน้าที่นิ่ง

• กำหนด width และ height ให้ทุกภาพและวิดีโอ และคง height: auto ไว้ใน CSS
• ใช้สัดส่วนภาพเดียวกันกับทุกภาพใน srcset
• กันพื้นที่ให้โฆษณา เอ็มเบด และ iframe ก่อนโหลด บทเรื่องโฆษณา อธิบายขนาดช่องโฆษณา
• ให้ประกาศคุกกี้และหน้าต่างชวนสมัครซ้อนทับอยู่ด้านบน หรือกันพื้นที่ไว้ให้ เพื่อไม่ให้ดันบทความลง
• ใช้ font-display: optional หรือฟอนต์สำรองที่ปรับให้ตรงกับเมตริกของเว็บฟอนต์
• ทำแอนิเมชันด้วย transform การทำแอนิเมชัน top หรือ left ทำให้เลย์เอาต์ขยับ

ตอบสนองเร็ว

เวลาโต้ตอบทั้งหมดมีสามส่วน คือเวลารอก่อนโค้ดของคุณทำงาน โค้ดของคุณ และการวาดภาพที่ตามมา งานใดที่ยาวกว่า 50 มิลลิวินาทีถือเป็น long task

• ทำให้น้อยที่สุดใน event callback อัปเดตหน้าจอก่อน แล้วค่อยเลื่อนส่วนที่เหลือออกไป
• แบ่งงานยาวด้วย scheduler.yield() และใช้ setTimeout แทนในเบราว์เซอร์ที่ไม่รองรับ
• ทำให้ DOM เล็ก รายการบทความที่ยาวใช้ content-visibility เพื่อเรนเดอร์รายการนอกจอทีหลังได้
• จำไว้ว่าแต่ละ iframe มี main thread ของตัวเอง จึงควรตรวจว่าการโต้ตอบที่ช้ามาจากเฟรมใด

หน้ายาวและการเลื่อนไม่รู้จบ

หากหน้าหมวดเลื่อนไปไม่สิ้นสุด ให้ตั้ง URL ถาวรของแต่ละช่วงด้วยเลขหน้าแบบสัมบูรณ์ เช่น ?page=12 และเชื่อมลิงก์หน้าเหล่านั้นต่อกันตามลำดับ อัปเดตที่อยู่ด้วย History API ตามที่ผู้อ่านเลื่อน Google ไม่เลื่อนหรือคลิก เนื้อหาที่โหลดแบบ lazy จึงต้องโหลดเมื่อเข้าสู่วิวพอร์ตโดยไม่ต้องมีการกระทำใด

รายการตรวจสอบ

• ตรวจ LCP, INP และ CLS ใน Search Console โดยแยกมือถือและเดสก์ท็อป
• เปิดเทมเพลตบทความที่คนเข้าชมมากที่สุดบนโทรศัพท์ แล้วยืนยันว่าพาดหัวและวันที่อยู่บนหน้าจอแรก
• ยืนยันว่าข้อความบทความทั้งหมดอยู่ใน HTML ที่เซิร์ฟเวอร์ส่งมา
• เปรียบเทียบมือถือกับเดสก์ท็อปว่าเนื้อหา หัวข้อ ข้อมูลแบบมีโครงสร้าง และแท็ก robots ตรงกัน
• เอา loading="lazy" ออกจากภาพนำและเพิ่ม fetchpriority="high"
• เพิ่ม width และ height ให้ทุกภาพและวิดีโอ
• กันพื้นที่ให้ทุกโฆษณา เอ็มเบด และแบนเนอร์
• ตั้ง scroll-padding-top ให้ตรงกับส่วนหัวแบบติดหน้าจอ
• ทดสอบหน้าที่ความกว้าง 320 CSS พิกเซล
• ให้ทุกช่วงของหน้าเลื่อนไม่รู้จบมี URL ของตัวเอง

แหล่งอ้างอิง

• ทำความเข้าใจ Google Page Experience, Google Search Central
• ทำความเข้าใจ Core Web Vitals และผลการค้นหาของ Google, Google Search Central
• แนวปฏิบัติที่ดีสำหรับ Mobile-first Indexing, Google Search Central
• แก้ไขเนื้อหาเว็บไซต์ที่โหลดแบบ lazy, Google Search Central
• Web Vitals, web.dev
• ปรับ Largest Contentful Paint ให้เหมาะสม, web.dev
• ปรับ Cumulative Layout Shift ให้เหมาะสม, web.dev
• ปรับ Interaction to Next Paint ให้เหมาะสม, web.dev
• ปรับ long task ให้เหมาะสม, web.dev
• การโหลดภาพแบบ lazy ระดับเบราว์เซอร์สำหรับเว็บ, web.dev
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C
• ทำความเข้าใจ Target Size (Enhanced), W3C WAI
• ทำความเข้าใจ Visual Presentation, W3C WAI