ทุกสิ่งที่คุณต้องการรู้เกี่ยวกับหน้ามือถือเร่งความเร็วของ Google

ในเดือนพฤษภาคมปี 2015 Facebook ได้เปิดตัวแพลตฟอร์มการเผยแพร่ในแอปใหม่ Instant Articles หนึ่งเดือนต่อมา Apple ประกาศว่าประสบการณ์แผงหนังสือแบบเก่า (โดยพื้นฐานแล้วเป็นโฟลเดอร์แฟนซีที่เต็มไปด้วยแอพข่าว) จะถูกแทนที่ใน iOS 9 ด้วยแพลตฟอร์มการรวบรวมข่าวและการค้นพบใหม่ล่าสุดที่เรียกว่า Apple News

อ่านเพิ่มเติม เกี่ยวกับ Smashing:

• การรับรู้ประสิทธิภาพ
• พรีโหลด: ใช้ทำอะไร?
• เตรียมพร้อมสำหรับ HTTP/2
• การเพิ่มประสิทธิภาพแบบก้าวหน้า
• เว็บ AMP แบบโปรเกรสซีฟ

สี่เดือนต่อมา ถึงตาของ Google ที่จะประกาศแผนการที่จะปฏิวัติการบริโภคข่าวบนมือถือด้วยโซลูชันบนเว็บแบบโอเพนซอร์สที่เรียกว่า Accelerated Mobile Pages หรือ AMP ซึ่งแม้จะค่อนข้างล่าช้า แต่ก็มีความทะเยอทะยานไม่น้อย ในเวลาเพียงไม่กี่เดือน เราได้เห็นความสงบสุขของการเผยแพร่ดิจิทัลบนมือถือที่ปะทุขึ้นในสงครามแพลตฟอร์มเต็มรูปแบบอีกครั้งเมื่อ Facebook, Apple และตอนนี้ Google แข่งขันกันเพื่อทั้งความภักดีของผู้จัดพิมพ์และความสนใจของผู้อ่าน

แม้ว่า Facebook และ Apple จะมีจุดเริ่มต้นที่สำคัญใน Google แต่ก็มีทุกเหตุผลที่เชื่อได้ว่า AMP จะตามทันได้อย่างรวดเร็ว (และอาจแซงหน้าคู่แข่งคนใดคนหนึ่งหรือทั้งคู่) หากคุณเป็นนักพัฒนาหรือผู้เผยแพร่โฆษณาที่ต้องการทราบสาเหตุ อะไร และอย่างไรกับ Accelerated Mobile Pages ของ Google ให้รวดเร็วและมีประสิทธิภาพมากที่สุด คุณก็มาถูกที่แล้ว

แต่ปัญหาคืออะไร?

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

• การแทรกแซงของบุคคลที่สาม โฆษณาและเทคนิคการติดตามที่เกี่ยวข้องไม่เพียงแต่เพิ่มจำนวนมากและคำขอเพิ่มเติมไปยังอุปกรณ์ที่มีข้อจำกัดแบนด์วิดท์และ CPU อยู่แล้ว แต่หน้าต่างๆ มักจะทำตัวราวกับว่าถูกครอบงำขณะที่พวกเขาชักชวนเกี่ยวกับการเรียก document.write() หลายครั้ง New York Times ได้ทำการทดสอบเมื่อเร็ว ๆ นี้ซึ่งแสดงให้เห็นว่าขนาดหน้าลดลงอย่างมีนัยสำคัญและอายุการใช้งานแบตเตอรี่เพิ่มขึ้นหลังจากติดตั้งตัวบล็อกเนื้อหา iOS
• ความเสียหายหลักประกันจากการออกแบบ ที่ตอบสนอง แม้ว่าเว็บไซต์ที่ออกแบบให้ตอบสนองได้ดีส่วนใหญ่จะดูดีบนหน้าจอทุกขนาด แต่มักจะมีสัมภาระของเว็บไซต์เดสก์ท็อปจำนวนมากเมื่อดูบนมือถือ เมื่อ Paul Irish ตรวจสอบประสิทธิภาพของ Reddit เขาพบว่าค่าใช้จ่ายจำนวนมากสามารถตรวจสอบย้อนกลับไปยังสินทรัพย์ที่เรียกว่า SnooIcon ซึ่งเป็นมาสคอตของ Reddit ที่แสดงใน SVG เพื่อให้สามารถเคลื่อนไหวได้ (โดยห้องสมุดบุคคลที่สาม ความหมาย โอเวอร์เฮดมากกว่า) บนเมาส์โอเวอร์ — ไม่ใช่สถานการณ์ที่สินทรัพย์มักพบว่าตัวเองอยู่ในอุปกรณ์มือถือ

เข้าสู่ Facebook Instant Articles, Apple News และ Accelerated Mobile Pages — ผู้ช่วยให้รอดของเราจากโลกที่ตาม Facebook (PDF, 3.4 MB) เวลาในการโหลดบทความบนอุปกรณ์มือถือโดยเฉลี่ยคือ 8 วินาที ในขณะที่โทรไป 8 วินาทีว่านิรันดรนั้นเป็นอติพจน์อย่างเห็นได้ชัด เนื่องจากคุณสามารถเข้าดูวิดีโอ Vine ที่สองของคุณในช่วงเวลานั้นได้ มันอาจยุติธรรมที่จะพูดได้ว่าตามมาตรฐานของวันนี้ อย่างน้อยก็เป็นเวลาหนึ่งวัน

ตัวอย่างสั้นๆ ของ Facebook Instant Articles, Apple News และ Accelerated Mobile Pages โปรดทราบว่าบทความทันใจของ Facebook และ Apple News เป็นประสบการณ์ในแอป ในขณะที่ AMP ทำงานบนเบราว์เซอร์ทั้งหมด

AMP ต่างกันอย่างไร?

บริบทบางประการสำหรับความแตกต่างของ AMP จาก Facebook Instant Articles และ Apple News จะทำให้การตัดสินใจบางอย่างของ Google ชัดเจนขึ้นสำหรับโครงการริเริ่มการเผยแพร่ดิจิทัลแบบใหม่

Facebook Instant Articles และ Apple News มีลักษณะที่เหมือนกันหลายประการ:

• ประสบการณ์ในแอป ผู้อ่านเข้าถึง Facebook Instant Articles ผ่าน Facebook บนอุปกรณ์เคลื่อนที่ และ Apple News เป็นแอปแบบสแตนด์อโลนที่มาพร้อมกับ iOS 9 ในปัจจุบัน ทั้งสองแพลตฟอร์มไม่อนุญาตให้ผู้ใช้ดูบทความในรูปแบบเฉพาะของตนภายนอกแอปนั้นๆ คิดว่าทั้งคู่เป็นการรีเฟรช RSS เฉพาะแอปพลิเคชัน
• ขับเคลื่อนโดยการเผยแพร่ แม้ว่าบทความโต้ตอบแบบทันทีของ Facebook และ Apple News ใช้รูปแบบการเผยแพร่ที่แตกต่างกันมาก (รูปแบบ Apple News เป็นแบบ JSON และมาร์กอัปบทความโต้ตอบแบบทันทีนั้นรวม HTML ไว้ในฟีด RSS ไม่มากก็น้อย) แต่ก็ใช้หลักการที่คล้ายคลึงกัน: เกลี้ยกล่อม CMS ของคุณให้สร้าง รูปแบบการเผยแพร่ที่จำเป็น และ Facebook หรือ Apple News จะแยกวิเคราะห์ แยกวิเคราะห์ และทำให้ทั้งสวยงามและรวดเร็วผ่านตัวแสดงภาพที่ปรับแต่งและปรับแต่งให้เหมาะสม
• ที่เน้นประสบการณ์ แม้ว่าบทความโต้ตอบแบบทันทีของ Facebook และ Apple News จะเน้นที่ประสิทธิภาพ แต่ก็มีความกังวลเกี่ยวกับการทำให้บทความดูและรู้สึกทันสมัยไม่แพ้กัน ทั้งสองแพลตฟอร์มมีองค์ประกอบที่ช่วยให้มีการโต้ตอบที่ลื่นไหลและราบรื่น ซึ่งโดยปกติแล้วเราจะเชื่อมโยงกับประสบการณ์การอ่านที่สร้างขึ้นเองด้วยมือ

ในทางตรงกันข้าม Accelerated Mobile Pages มีจุดเน้นที่ชัดเจน:

• ประสบการณ์บนเว็บ เอกสาร AMP ได้รับการออกแบบให้แสดงผลในเบราว์เซอร์หรือใน WebViews
• เอกสารปรมาณู แม้ว่าเอกสาร AMP จะได้รับการตรวจสอบ แยกวิเคราะห์ และแสดงผลบางส่วนโดยรันไทม์ AMP (มีอีกมากมายที่ด้านล่าง) เอกสารเหล่านี้เป็นเอกสารที่สมบูรณ์และเป็นอิสระซึ่งอาศัยอยู่บนเว็บเซิร์ฟเวอร์ของคุณเอง (และในแคช CDN หรือไม่ก็ได้) แทนที่จะเป็นคอลเล็กชันของ ข้อมูลเมตาที่ในบางจุดจะถูกแปลงเป็นบทความและแสดงผลในแอป
• เน้น ประสิทธิภาพ AMP ให้ความสำคัญกับประสิทธิภาพของเอกสาร AMP มากกว่าเรื่องความสวยงามหรือรูปแบบการโต้ตอบ ไม่ได้หมายความว่าเอกสาร AMP นั้นเรียบง่ายโดยเนื้อแท้ (อาจดูน่าดึงดูดพอๆ กับบทความทันทีของ Facebook หรือบทความ Apple News ที่มีสไตล์ที่ถูกต้อง) แต่รันไทม์นั้นเกี่ยวข้องกับการทำให้บทความแสดงผลได้เร็วกว่าการให้เอฟเฟกต์ภาพแฟนซี เช่น สิ่งเล็ก ๆ น้อย ๆ ที่กระตุกอย่างบ้าคลั่ง

AMP คืออะไรกันแน่?

ปรัชญาที่เพียงพอและโบกมือระดับสูง มาดูรายละเอียดกันดีกว่า ในขณะที่การทำความเข้าใจบทความโต้ตอบแบบทันทีของ Facebook และ Apple News นั้นค่อนข้างง่าย (โดยพื้นฐานแล้วพวกเขาเป็นผู้รวบรวมข่าวที่แปลกใหม่พร้อมตัวแสดงที่กำหนดเองซึ่งสร้างขึ้นจากรูปแบบการเผยแพร่ที่เป็นกรรมสิทธิ์) AMP นั้นมีค่าผิดปกติ เข้าใจยากขึ้นเล็กน้อย ด้วยเหตุผลสองประการ:

• ไม่มีรูปแบบที่ง่ายที่จะเปรียบเทียบ เมื่อ RSS มาใหม่ เราทุกคนต่างประหลาดใจกับพลังของมัน เขียนบทความและบล็อกโพสต์นับไม่ถ้วนเกี่ยวกับศักยภาพในการก่อกวน ประกาศหน้าแรกตาย (อีกครั้ง) และจากนั้นก็ลืมมันไปทั้งหมด บทความโต้ตอบแบบทันทีของ Facebook และ Apple News เป็นการรีบูท RSS เป็นหลัก ยกเว้นว่าพวกเขาจะจัดการกับความไม่สะดวกของมาตรฐานทั้งหมด และแต่ละรายการจะทำงานได้ในแอปพลิเคชั่นเดียว
• AMP ไม่ใช่ลูกค้า . แม้ว่าบทความทันใจของ Facebook, Apple News และ AMP จะมีองค์ประกอบหลายอย่างที่เหมือนกัน เช่น รูปแบบการเผยแพร่ที่เป็นกรรมสิทธิ์และตัวแสดงภาพที่กำหนดเอง แต่ AMP เป็นองค์ประกอบเดียวที่ไม่มีไคลเอ็นต์เฉพาะ (นอกเหนือจากเบราว์เซอร์) มากกว่าพี่น้องของตน AMP คือชุดของข้อกำหนด ข้อตกลง และเทคโนโลยีที่สามารถรวมกันเป็นโซลูชัน แทนที่จะเป็นโซลูชันแบบ end-to-end (ผู้เผยแพร่สู่ผู้อ่าน) ในตัวของมันเอง

ตอนนี้เรารู้แล้วว่าให้นึกถึง AMP เป็นชุดของส่วนผสม แทนที่จะเป็นเค้กที่อบจนสุกแล้ว เรามาดูกันว่าส่วนประกอบแต่ละอย่างมีอะไรบ้าง:

• แอมป์ HTML,
• รันไทม์ของ AMP
• แคช AMP

AMP HTML

เอกสาร AMP เขียนด้วย HTML แต่ไม่ใช่เฉพาะ HTML ใดๆ แท็กบางแท็กถูกแบน ในขณะที่มีการแนะนำแท็กใหม่สองสามแท็ก (บางส่วนเพื่อแทนที่แท็กที่ถูกแบนและบางส่วนเพื่อห่อหุ้มฟังก์ชันการโต้ตอบ) คุณสามารถนึกถึง AMP HTML ว่า HTML จะเป็นอย่างไรหากได้รับการออกแบบโดยไม่ได้คำนึงถึงประสิทธิภาพบนอุปกรณ์เคลื่อนที่ (ซึ่งต่างจากการเปิดตัว 14 ปีก่อนการเปิดตัว iPhone)

เนื่องจาก AMP HTML ได้รับการออกแบบมาเพื่อประสิทธิภาพสูงสุด เพื่อให้เข้าใจและเห็นคุณค่าของมัน เราจึงต้องเข้าใจปัญหาที่แก้ไขได้ ต่อไปนี้คือสามสิ่งที่ใหญ่ที่สุดที่ทำให้การโหลดและการแสดงผลหน้าเว็บบนอุปกรณ์เคลื่อนที่บกพร่อง:

• ขนาดบรรทุก . การออกแบบเว็บที่ตอบสนองตามอุปกรณ์ได้ให้บริการเราเป็นอย่างดีเพราะช่วยให้เราสร้างเว็บไซต์เดียวสำหรับอุปกรณ์และหน้าจอทุกเครื่องได้ แต่นั่นก็หมายถึงการส่งเพย์โหลดขนาดเดสก์ท็อป (HTML, JavaScript, CSS และทรัพยากร) ไปยังอุปกรณ์พกพาที่มีแบนด์วิดท์และ CPU สูงด้วยเช่นกัน (ผู้ที่คิดว่าโทรศัพท์ของตนเป็นคอมพิวเตอร์เดสก์ท็อปตัวเล็ก ๆ ให้เครดิตกับฮาร์ดแวร์มือถือมากเกินไป iPhone 6s ของคุณมี RAM 2 GB ในขณะที่แล็ปท็อปของคุณอาจมี 8 หรือ 16)
• กำลัง โหลดทรัพยากร ทรัพยากรไม่ได้ถูกโหลดในลำดับที่เหมาะสมเสมอไป ซึ่งหมายความว่าแบนด์วิดท์ CPU และ RAM มักจะทุ่มเทให้กับทรัพย์สินที่ผู้ใช้อาจไม่เคยเห็นด้วยซ้ำ นอกจากนี้ ทรัพยากรมักไม่ประกาศความกว้างและความสูง (โดยเฉพาะอย่างยิ่งเมื่อแสดงผ่านเครือข่ายโฆษณาหรือแทรกผ่านการเรียก document.write() ) ซึ่งไม่เพียงแต่ทำให้หน้าปรับขนาดตัวเองเนื่องจากขนาดของทรัพยากรถูกกำหนดอย่างเกียจคร้าน แต่ยังทริกเกอร์โดยไม่จำเป็น และการคำนวณเลย์เอาต์ใหม่ราคาแพง นั่นเป็นสาเหตุที่ทำให้หน้าเว็บกระโดดไปมาเหมือนลูกแมวที่วิ่งไล่ด้วยเลเซอร์ ซึ่งปรากฏให้เห็นอย่างเชื่องช้า
• การดำเนินการจาวาสคริปต์ ฉันไม่ได้กำลังจะพูดถึงหัวข้อของประสิทธิภาพของ JavaScript ที่นี่ แต่เว็บไซต์สมัยใหม่มักใช้เมกะไบต์ซ้อนกัน และในขณะที่มันอาจทำงานโดยไม่มีเวลาแฝงที่มองเห็นได้บนคอมพิวเตอร์เดสก์ท็อป แต่อุปกรณ์เคลื่อนที่ยังคงเป็นสภาพแวดล้อมที่แตกต่างกันมาก ซึ่งฉันคิดว่า เราทุกคนสามารถตกลงกันได้ JavaScript ถูกเก็บไว้ให้น้อยที่สุด

ด้วยอุปสรรค 3 ประการนี้ในการมอบประสบการณ์เว็บที่ลื่นไหลบนอุปกรณ์เคลื่อนที่ AMP HTML จึงมีไว้เพื่อวัตถุประสงค์สามประการเป็นหลัก:

• ส่งเสริมให้กระชับ เอกสาร AMP ไม่ใช่เว็บไซต์เดสก์ท็อปเวอร์ชันตอบสนอง แม้ว่าเอกสาร AMP จะตอบสนองได้ (และโดยปกติ) แต่ก็ตอบสนองได้ในบริบทของอุปกรณ์เคลื่อนที่ กล่าวอีกนัยหนึ่ง เอกสาร AMP ได้รับการออกแบบมาโดยเฉพาะเพื่อให้ทำงานได้ดีในอุปกรณ์เคลื่อนที่ทุกแห่ง (เดสก์ท็อปและอุปกรณ์เคลื่อนที่)
• ควบคุมการโหลดทรัพยากรภายนอก รันไทม์ AMP ควบคุมการโหลดทรัพยากรภายนอกเพื่อให้แน่ใจว่ากระบวนการนี้มีประสิทธิภาพสูง ส่งผลให้เนื้อหาปรากฏบนหน้าจอของผู้ใช้อย่างรวดเร็วและชาญฉลาดที่สุด
• สรุปการทำงานแบบโต้ตอบ แม้ว่าเอกสาร AMP มักจะมุ่งไปที่ธุรกิจในการนำเสนอประสบการณ์การอ่านที่ตรงไปตรงมาแก่ผู้อ่าน แต่ก็ไม่ได้หมายความว่าจะทันสมัยและโต้ตอบไม่ได้ รันไทม์ของ AMP มีฟังก์ชันที่ห่อหุ้มผ่าน JavaScript ที่เพิ่มประสิทธิภาพสูง เพื่อให้นักพัฒนาไม่ต้องเสี่ยงที่จะขัดขวางประสิทธิภาพด้วยการเขียนของตนเอง

AMP HTML Tags

ด้านล่างนี้คือรายการแท็กที่ถูกแบนใน AMP HTML:

• script นี้เห็นได้ชัดว่าเป็นเรื่องใหญ่ ฉันจะให้รายละเอียดเพิ่มเติมเกี่ยวกับตำแหน่งของ AMP ใน JavaScript ด้านล่าง สำหรับตอนนี้ แค่สมมติว่าแท็ก script เดียวที่คุณมีในเอกสาร AMP คือแท็กที่โหลดรันไทม์ AMP และแท็กสำหรับข้อมูลที่เชื่อมโยงตาม JSON หรือไม่ก็ได้
• base แท็ก base ดูเหมือนจะถูกห้ามด้วยความระมัดระวังอย่างมาก และอาจจบลงด้วยรายการที่อนุญาตพิเศษหากชุมชนบ่น (ฉันเดาว่าไม่มีใครสนใจไม่ทางใดก็ทางหนึ่ง)
• frame และ frameset ไม่ใช่การใช้งานที่ดีของอสังหาริมทรัพย์บนมือถืออยู่ดีดังนั้นการกำจัดที่ดี
• object , param , applet และ embed น่าเศร้าที่เอกสาร AMP ของคุณจะไม่มี Flash หรือ Java applet (นั่นเป็นการเสียดสีในกรณีที่ไม่ชัดเจนทั้งหมด)
• องค์ประกอบ form และ input (ยกเว้นแท็ก button ) การสนับสนุนแบบฟอร์มมักจะถูกนำไปใช้เป็นส่วนประกอบที่ห่อหุ้มไว้ในที่สุดเนื่องจากถูกจำกัดการใช้งานโดยไม่มีการเขียนสคริปต์

ต่อไปนี้คือรายการแท็กที่แทนที่คู่ HTML เพื่อเพิ่มประสิทธิภาพการโหลดทรัพยากรและบังคับใช้แนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุด:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) แทนที่แท็ก img และเพิ่มประสิทธิภาพการโหลดทรัพยากรโดยคำนึงถึงปัจจัยต่างๆ เช่น ตำแหน่งของวิวพอร์ต ทรัพยากรระบบ และการเชื่อมต่อ
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) แทนที่แท็ก video HTML5 เพื่อให้สามารถโหลดเนื้อหาวิดีโอได้อย่างเกียจคร้าน (คำนึงถึงวิวพอร์ตด้วย)
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) แทนที่แท็ก audio HTML5 เพื่อให้สามารถโหลดเนื้อหาเสียงได้อย่างเกียจคร้าน (พิจารณาวิวพอร์ตด้วย)
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) แท็ก amp-iframe บังคับใช้แนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุดโดยทำสิ่งต่างๆ เช่น เนื้อหาแซนด์บ็อกซ์โดยค่าเริ่มต้นและการวางข้อจำกัด โดยที่ iframes อาจปรากฏขึ้นเพื่อให้แน่ใจว่าจะไม่ครอบงำเอกสาร AMP

สุดท้าย ต่อไปนี้คือแท็กทั้งหมดที่ AMP HTML นำมาใช้เพื่อเพิ่มฟังก์ชันการทำงานหรือการโต้ตอบให้กับเอกสารของคุณ โดยไม่ต้องให้คุณเขียน JavaScript

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) แท็ก amp-ad ช่วยให้รันไทม์ AMP จัดการการโหลดโฆษณาได้เช่นเดียวกับทรัพยากรอื่นๆ ที่โหลดจากภายนอก (ปัจจุบัน โฆษณาจะถูกโหลดครั้งสุดท้าย) และช่วยให้แน่ใจว่า JavaScript จากเครือข่ายโฆษณาไม่สามารถดำเนินการภายในเอกสาร AMP หลัก หรือเรียกการคำนวณรูปแบบที่ไม่จำเป็น (ลาก่อน document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) เฟรมเวิร์กขนาดเล็กนี้รวมข้อมูลการวิเคราะห์และส่งไปยังผู้ให้บริการบุคคลที่สาม ณ วันนี้ การสนับสนุน AMP มาจาก Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen และ Parse.ly
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) ใช้สำหรับฝังเว็บบีคอน และรองรับโทเค็นสำหรับส่งตัวแปรไคลเอ็นต์หลายตัวไปยังเซิร์ฟเวอร์
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) คอมโพเนนต์ที่เพิ่มประสิทธิภาพนี้จะแสดงรูปภาพย่อยในแนวนอนแบบอินเทอร์แอกทีฟ
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) ซึ่งช่วยให้ผู้อ่านเปิดภาพในมุมมอง "ไลท์บ็อกซ์" แบบเต็มหน้าจอได้ รองรับข้อกำหนดของทั้งภาพขนาดย่อและภาพขนาดเต็ม
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) ซึ่งจะโหลด GIF แบบเคลื่อนไหวและมีฟังก์ชันตัวยึดตำแหน่งที่จำเป็นมาก
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) ตั้งค่าการหมดเวลาการโหลดแบบอักษรที่กำหนดเอง และระบุแบบอักษรสำรองหากแบบอักษรที่กำหนดเองของคุณไม่โหลดภายในเวลาที่กำหนด .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) ข้อความภายในแท็ก amp-fit-text จะได้รับการกำหนดขนาดแบบอักษรที่ปรับให้เหมาะสมโดยอัตโนมัติ พื้นที่ว่าง คิดว่าเป็นการตอบสนองแบบ prepackaged เล็กน้อย
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) ด้วยแท็ก amp-list คุณสามารถโหลดข้อมูล JSON ซ้ำแบบไดนามิกและแสดงผลโดยใช้ HTML แม่แบบ (ดูแท็ก amp-mustache ด้านล่าง)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) รองรับการแสดงเทมเพลต HTML ของ Mustache
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) หากคุณเลือกที่จะไม่ใช้แคช AMP (มีการแคชเพิ่มเติมด้านล่าง) แท็ก amp-install-serviceworker โหลดและติดตั้งพนักงานบริการสำหรับหน้าปัจจุบัน พนักงานบริการมีไหวพริบ แต่ในความคิดของฉัน ยังเร็วเกินไปที่จะพึ่งพาพวกเขา
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) คาดการณ์ได้ว่าจะฝังวิดีโอ YouTube ด้วยรหัสวิดีโอที่ระบุ
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) ทวีตแบบฝัง (ไม่บังคับการ์ด Twitter)
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) ฝังรูปภาพ Instagram
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) คอมโพเนนต์นี้จะโหลดและแสดงวิดีโอ (และโปรแกรมเล่นวิดีโอ) จาก Brightcove
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) ฝังวิดเจ็ต Pinterest หรือปุ่ม "ตรึง" ในเอกสาร AMP
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) ฝังวิดีโอ Vine ที่ระบุในเอกสาร AMP

โปรดทราบว่าแม้ว่าแท็กที่ amp- คำนำหน้าจะไม่ใช่ HTML มาตรฐานทุกประการ แต่ก็ไม่ใช่กรรมสิทธิ์เช่นกัน แต่เป็นองค์ประกอบที่กำหนดเองที่ถูกต้องตามกฎหมายซึ่งมีการใช้งาน JavaScript ที่ทำสิ่งต่างๆ เช่น บังคับใช้แนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุดและจัดลำดับความสำคัญในการโหลดทรัพยากรระยะไกล (เพิ่มเติมในส่วน "AMP Runtime" ด้านล่าง) กล่าวอีกนัยหนึ่ง แม้ว่า AMP HTML อาจดูน่าสงสัยเหมือนกับกลยุทธ์การโอบกอด ขยาย และดับ แต่จริงๆ แล้วเป็นเพียงแอปพลิเคชันที่ชาญฉลาดของมาตรฐานเว็บ และไม่ได้แตกต่างไปจากแอตทริบิวต์ data- ที่กำหนดเองมากนัก

จัดแต่งทรงผม AMP HTML

การจัดรูปแบบเอกสาร AMP ทำได้โดยใช้ CSS มาตรฐานและไม่ได้แตกต่างจากการจัดรูปแบบเนื้อหามากนัก อย่างไรก็ตาม พึงระลึกไว้หลายประการ:

• การใส่สไตล์ทั้งหมดต้องทำด้วยสไตล์ชีตแบบอินไลน์ — ไม่มีสไตล์ชีตที่ลิงก์ภายนอกและไม่มีสไตล์อินไลน์ระดับองค์ประกอบ (สไตล์ชีตที่ลิงก์ภายนอกจะต้องดาวน์โหลดเอกสารเพิ่มเติมก่อนจึงจะคำนวณเลย์เอาต์ได้ และสไตล์ระดับองค์ประกอบแบบอินไลน์อาจทำให้เอกสารขยายได้)
• รูปแบบถูกจำกัดไว้ที่ 50 KB ปรัชญาของ Google คือ 50 KB เพียงพอสำหรับเอกสารหรือบทความที่ดี แต่ไม่เพียงพอสำหรับเว็บไซต์ที่ดี
• สไตล์ชีตแบบอินไลน์ของคุณต้องมีแอตทริบิวต์ amp-custom (เช่น <style amp-custom> )
• กฎ @ — @font-face (เพิ่มเติมเกี่ยวกับแบบอักษรด้านล่าง), @keyframes และ @media — ได้รับอนุญาต
• ตัวเลือกบางตัวมีข้อจำกัดที่ทราบว่าท้าทายประสิทธิภาพ เช่น ตัวเลือกสากล ( * ) และตัวเลือก :not()
• ตัวระบุ !important ถูกห้ามเพื่อให้แน่ใจว่ารันไทม์ AMP มีคำสุดท้ายในการปรับขนาดองค์ประกอบ
• การจัดรูปแบบองค์ประกอบ AMP ที่กำหนดเอง เช่น amp-carousel ทำได้โดยการแทนที่คลาสเริ่มต้น เช่น .amp-carousel-button-prev หรือโดยใช้ชุดคุณสมบัติที่กำหนดเอง CSS ที่กำหนดไว้ล่วงหน้า เช่น --arrow-color
• ทรัพยากรที่โหลดจากภายนอกทั้งหมดต้องมีคุณสมบัติความกว้าง ความสูง และเค้าโครงที่ระบุ (เพิ่มเติมเกี่ยวกับเค้าโครงด้านล่าง) เพื่อลดการคำนวณเค้าโครง DOM ที่มีราคาแพง
• อนุญาตให้ใช้การเปลี่ยนภาพและภาพเคลื่อนไหวที่เร่งด้วย GPU ได้ (และไม่ทำให้เกิดการคำนวณใหม่) ปัจจุบัน opacity และ transform เป็นรายการที่อนุญาตพิเศษ

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับเอกสารการจัดรูปแบบ โปรดดูข้อกำหนด AMP HTML

แบบอักษร

AMP สนับสนุนแบบอักษรที่กำหนดเองอย่างมีความสุข โดยมีคุณสมบัติบางประการดังนี้

• แบบอักษรต้องโหลดด้วยแท็กลิงก์หรือกฎ CSS @font-face กล่าวคือ คุณไม่สามารถโหลดแบบอักษรโดยใช้ JavaScript
• แบบอักษรทั้งหมดต้องให้บริการผ่าน HTTPS
• ผู้ให้บริการแบบอักษรต้องได้รับอนุญาตพิเศษ ในปัจจุบัน ผู้ให้บริการที่ได้รับอนุญาตพิเศษคือ fonts.googleapis.com และ fast.fonts.net แต่เมื่อพิจารณาว่าผู้เผยแพร่โฆษณา ผู้ลงโฆษณา และผู้ให้บริการวิเคราะห์เพิ่มการรองรับ AMP ได้เร็วเพียงใด ฉันสงสัยว่าจะมีอีกมากในเร็วๆ นี้

เค้าโครง

แนวทางการจัดวางของ AMP เกิดขึ้นจากเป้าหมายหลักสองประการ:

• รันไทม์ต้องสามารถสรุปขนาดของทรัพยากรที่โหลดจากภายนอกทั้งหมดก่อนที่จะโหลดจริง เพื่อให้สามารถคำนวณโครงร่างสุดท้ายได้โดยเร็วที่สุด เมื่อคำนวณเลย์เอาต์แล้ว สามารถแสดงผลบทความและผู้อ่านสามารถเริ่มโต้ตอบกับมันได้ แม้ว่าโฆษณา รูปภาพ เสียง และวิดีโอจะยังโหลดไม่เสร็จ (และเมื่อทรัพยากรเหล่านั้นโหลด ทรัพยากรเหล่านั้นจะแสดงผลได้อย่างราบรื่น โดยไม่รบกวนประสบการณ์การอ่านด้วยการอัปเดตเค้าโครงของเอกสาร)
• บทความ AMP ควรตอบสนอง ตามชื่อ "Accelerated Mobile Pages" เอกสาร AMP มีไว้สำหรับอุปกรณ์เคลื่อนที่โดยเฉพาะ ดังนั้น ในบริบทนี้ "ตอบสนอง" จึงไม่รวมถึงความละเอียดของเดสก์ท็อป ในทางกลับกัน เอกสาร AMP ควรดูดีบนอุปกรณ์พกพาทั้งหมด ตั้งแต่ iPhone 4 รุ่นเก่าๆ ที่ผู้คนยังคงใช้งานจนถึง iPad Pro ที่ค่อนข้างใหญ่โต

เป้าหมายเดิมบรรลุผลสำเร็จตามข้อกำหนดที่ว่าทรัพยากรที่โหลดจากภายนอกทั้งหมดมีแอตทริบิวต์ width และ height (และบังคับใช้เพิ่มเติมโดยการจำกัดสคริปต์ ซึ่งทำให้แน่ใจได้ว่าทรัพยากรใหม่ไม่สามารถเสียบรองเท้าได้) อย่างหลังทำได้โดยการสืบค้นสื่อมาตรฐาน แอตทริบิวต์ media แอตทริบิวต์ sizes และแอตทริบิวต์ layout เฉพาะ AMP

ต่อไปนี้คือภาพรวมของเลย์เอาต์ที่ AMP รองรับในปัจจุบัน

• nodisplay องค์ประกอบจะไม่แสดงในตอนแรก แต่การแสดงผลสามารถถูกทริกเกอร์โดยการกระทำของผู้ใช้ (ใช้ร่วมกับส่วนประกอบต่างๆ เช่น amp-lightbox )
• fixed องค์ประกอบมีความกว้างและความสูงคงที่ ซึ่งหมายความว่ารันไทม์ไม่สามารถใช้พฤติกรรมตอบสนองได้
• ใน responsive คิดของฉัน ตัวเลือกเลย์เอาต์ของ AMP นี้มีประโยชน์และวิเศษที่สุด องค์ประกอบนี้ใช้พื้นที่ใดก็ตามที่ได้รับการจัดสรรโดยยังคงอัตราส่วนกว้างยาวไว้ (โดยทั่วไป "ทำให้สิ่งนี้ดูดีในการแก้ปัญหาใด ๆ โปรดและขอบคุณ")
• fixed-height ที่ องค์ประกอบใช้พื้นที่ที่กำหนดแต่คงความสูงคงที่
• fill องค์ประกอบเติมคอนเทนเนอร์ที่อยู่ในโดยไม่คำนึงถึงอัตราส่วนกว้างยาว (คิด width: 100% และ height: 100% .)
• container องค์ประกอบคือคอนเทนเนอร์ ดังนั้น อนุญาตให้ลูกของมัน (ตรงข้ามกับพาเรนต์) กำหนดขนาดขององค์ประกอบ เหมือนกับองค์ประกอบ div มาตรฐาน

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

แล้ว SVG ล่ะ?

ได้รับการสนับสนุน! SVG พื้นฐานได้รับการสนับสนุนอย่างครอบคลุมทั้งบนเดสก์ท็อปและเบราว์เซอร์มือถือ และกราฟิกไม่ได้ตอบสนองมากไปกว่าเวกเตอร์ ดังนั้น AMP และ SVG จึงสร้างทีมที่ดีมาก ข้อจำกัดที่ใหญ่ที่สุดคือ เนื่องจากข้อจำกัดในการเขียนสคริปต์ คุณจะไม่สามารถทำให้เวกเตอร์ของคุณเคลื่อนไหวด้วย JavaScript ได้ ซึ่งหากเราพูดกันตามจริง คุณก็ไม่ควรทำบนมือถืออยู่ดี อย่างไรก็ตาม หากคุณต้องเติมชีวิตชีวาให้กับ SVG ของคุณจริงๆ คุณยังคงสามารถทำได้โดยใช้ภาพเคลื่อนไหว CSS ตามข้อจำกัดเดียวกันที่อธิบายไว้ในส่วนการจัดรูปแบบด้านบน โปรดจำไว้ว่า SVG เป็นส่วนหนึ่งของ DOM จึงสามารถจัดสไตล์และเคลื่อนไหวได้เหมือนกับองค์ประกอบอื่นๆ

ปรัชญาของ AMP เกี่ยวกับ JavaScript

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

ดังที่กล่าวไปแล้ว การแบน JavaScript ทั้งหมดอย่างถาวรนั้นทั้งไม่สมจริงและค่อนข้างเข้มงวด ความจริงก็คือเว็บใช้ JavaScript มาระยะหนึ่งแล้ว แม้กระทั่งในบริบทของประสบการณ์การอ่านที่เรียบง่ายและค่อนข้างไม่สุภาพ สำหรับสิ่งต่างๆ เช่น การโฆษณา การวิเคราะห์ และคุณลักษณะเชิงโต้ตอบ นอกจากนี้ หนึ่งในสิ่งที่ดีที่สุดเกี่ยวกับเว็บก็คือความเปิดกว้างและความสามารถที่ดูเหมือนไม่มีที่สิ้นสุดสำหรับการทดลอง การแสดงออก และความคิดสร้างสรรค์ ซึ่งส่วนใหญ่ขับเคลื่อนโดย JavaScript

ทีมงาน AMP ตระหนักถึงทั้งภาระที่จาวาสคริปต์ที่ผู้ใช้เขียนขึ้นเองตามอำเภอใจในการรับประกันประสิทธิภาพ และความแพร่หลายและความหลีกเลี่ยงไม่ได้ของ JavaScript ในสภาพแวดล้อมเว็บสมัยใหม่ ทีมงาน AMP จึงมีหลักการการเขียนสคริปต์ดังต่อไปนี้:

• ไม่รองรับหรืออนุญาต JavaScript ที่ผู้ใช้เขียนในขณะนี้ คุณอาจมีแท็กสคริปต์เพียง 2 ประเภทในเอกสาร AMP ได้แก่ แท็กข้อมูลที่เชื่อมโยง (ซึ่งมีประเภทเป็น application/ld+json ) และแท็กสำหรับรวมทั้งรันไทม์ AMP และคอมโพเนนต์ AMP แบบขยาย
• ผู้เขียนโครงการ AMP คาดการณ์ความต้องการส่วนใหญ่สำหรับ JavaScript ในบริบทของการใช้บทความบนมือถือ ดังนั้น AMP จึงสนับสนุนทางเลือกอื่น ( amp-pixel รวมถึงแบบอักษรที่กำหนดเองพร้อมแท็กลิงก์ หรือ @font-face rule เป็นต้น) หรือ มีการใช้งานที่เข้ากันได้กับรันไทม์ AMP ดังนั้นจึงรับประกันทั้งความปลอดภัยและประสิทธิภาพ ( amp-ad , amp-analytics , amp-carousel ฯลฯ )
• หากคุณต้องใช้ JavaScript สำหรับคุณลักษณะแบบอินเทอร์แอกทีฟจริงๆ คุณสามารถสร้างคุณลักษณะนี้แยกจากกัน แล้วรวมเข้ากับ [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) แท็ก เนื้อหาที่รวมอยู่ใน amp-iframe ยังอนุญาตให้มีการสื่อสารแบบจำกัดกับเอกสารหลักสำหรับสิ่งต่าง ๆ เช่นคำขอปรับขนาด
• ส่วนประกอบ AMP เป็นโอเพ่นซอร์ส (Apache 2) และเปิดให้มีส่วนร่วม ดังนั้นส่วนประกอบใหม่จะปรากฏขึ้นเมื่อเวลาผ่านไป (อันที่จริง ส่วนประกอบใหม่หลายรายการปรากฏขึ้นระหว่างการเขียนและแก้ไขบทความนี้ ดังนั้นฉันจึงได้อัปเดตแล้วสองสามครั้ง) แม้ว่าทีม AMP จะจัดลำดับความสำคัญขององค์ประกอบทั่วไปมากกว่าฟังก์ชันเฉพาะของบริการ (เช่น วิดเจ็ตสำหรับการเริ่มต้นทางสังคมโดยเฉพาะ) แต่ก็มุ่งมั่นที่จะจัดหาความหลากหลายที่เพียงพอเพื่อรองรับเนื้อหาที่หลากหลายที่สุดเท่าที่จะเป็นไปได้
• สุดท้าย นโยบายทั้งหมดเหล่านี้อาจมีการเปลี่ยนแปลง เนื่องจากคุณลักษณะของเบราว์เซอร์ เช่น ผู้ทำงานบนเว็บ องค์ประกอบที่กำหนดเองและ Shadow DOM ได้รับการสนับสนุนอย่างกว้างขวางมากขึ้น ตัวเลือกสำหรับการสนับสนุน JavaScript ที่ผู้ใช้เขียนและส่วนประกอบที่กำหนดเอง - ในขณะที่ยังคงรับประกันความปลอดภัยและประสิทธิภาพ - จะขยายตัวอย่างมาก

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับอนาคตของคอมโพเนนต์ AMP โปรดดูส่วน "ส่วนประกอบเพิ่มเติม" ของข้อกำหนด "ส่วนประกอบ AMP HTML"

กายวิภาคของเอกสาร AMP

ตอนนี้ คุณมีความเข้าใจอย่างถ่องแท้เกี่ยวกับ AMP HTML แล้ว มาแยกย่อยเอกสารประกอบกัน

แน่นอน คุณจะเริ่มเอกสาร AMP ด้วยการประกาศ doctype :

 <!doctype html>

ถัดไป กำหนดเอกสาร HTML ของคุณเป็น AMP HTML ซึ่งเชื่อหรือไม่ว่าคุณใช้อีโมจิแรงดันสูงเป็นแอตทริบิวต์ในแท็ก html

 <html >

หรือหากคุณเป็นคนขี้งอนหัวเก่าและคลั่งไคล้แนวคิดในการประดับโค้ดของคุณด้วยอิโมจิที่น่ารัก คุณสามารถใช้แอตทริบิวต์ amp ที่อนุรักษ์นิยมมากกว่าแทน:

 <html amp> <!-- A good sign that you're boring! -->

ในแท็ก head อย่าลืมคำแนะนำในการเข้ารหัสอักขระ utf-8 :

 <meta charset="utf-8">

และลิงก์ไปยังเวอร์ชันที่ไม่ใช่ AMP ของเอกสารของคุณ (ทำเครื่องหมายเป็น canonical เพื่อไม่ให้ปรากฏเป็นเนื้อหาที่ซ้ำกัน):

 <link rel="canonical" href="my-non-amp-index.html">

ในทางกลับกัน เวอร์ชันที่ไม่ใช่ AMP ของคุณควรมีการอ้างอิงถึงเอกสาร AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

เนื่องจากหน้า AMP มีไว้สำหรับอุปกรณ์เคลื่อนที่ (และคุณต้องการการแรสเตอร์ GPU ด้วย) อย่าลืมใส่แท็ก meta viewport :

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

โค้ดบรรทัดถัดไปอาจดูแปลกๆ เล็กน้อย นั่นก็เพราะว่าเป็นเช่นนั้น คุณรู้ไหมว่าบางครั้งคุณจะเห็นหน้าเว็บแสดงข้อความชั่วครู่ก่อนที่จะโหลดและปรับใช้แบบอักษร จากนั้นจึงกะพริบและแสดงผลอีกครั้งในลักษณะที่ผู้ออกแบบต้องการ แท็กด้านล่างจะคงความทึบของหน้าไว้ที่ 0 (มองไม่เห็น) จนกว่าจะจัดรูปแบบอย่างเหมาะสม

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

ปัญหาของแนวทางนี้คือ หากรันไทม์ AMP ล้มเหลวในการโหลด เป็นไปได้ในทางเทคนิคที่ความทึบของหน้าจะไม่เปลี่ยนจาก 0 เป็น 1 เพื่อชดเชยกรณีฉุกเฉินดังกล่าว โค้ดด้านบนอาจมีการเปลี่ยนแปลงเป็นสิ่งที่ใกล้เคียงกับสิ่งนี้:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

สิ่งต่อไปที่ต้องทำคือรวมรันไทม์ AMP JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

และรวมการใช้งาน JavaScript สำหรับส่วนประกอบเพิ่มเติมที่คุณต้องการ:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(โปรดสังเกตการใช้แอตทริบิวต์ async ซึ่งไม่ใช่ทางเลือก ยิ่งบล็อกน้อยยิ่งดี)

หรือคุณสามารถโรยข้อมูลที่เชื่อมโยงเล็กน้อยได้ดังนี้:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

ตอนนี้ มาเพิ่มแบบอักษรสองสามแบบ โดยใช้แท็ก link หรือกฎ @font-face ใน CSS ของคุณ:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

จากนั้นเราจะบางสไตล์ (มูลค่าไม่เกิน 50 KB) พร้อมแอตทริบิวต์ amp-custom จำเป็น:

 <style amp-custom>

ตอนนี้คุณพร้อมที่จะสร้างเอกสาร HTML มาตรฐานมากหรือน้อยโดยใช้ทุกสิ่งที่คุณเพิ่งเรียนรู้เกี่ยวกับ AMP HTML

แอมป์รันไทม์

ฉันจะไม่ใช้เวลามากขนาดนั้นกับรันไทม์ AMP เพราะเหมือนรันไทม์ทั้งหมด มันเป็นกล่องดำเล็กน้อย ไม่ได้หมายความว่าไม่สามารถเข้าถึงรันไทม์ AMP ได้ (เป็นโอเพ่นซอร์ส เช่นเดียวกับส่วนที่เหลือของโปรเจ็กต์) เช่นเดียวกับรันไทม์ที่ดีทั้งหมด นักพัฒนาไม่จำเป็นต้องรู้ว่ามันทำงานอย่างไรเพื่อใช้ประโยชน์จากมัน ตราบใดที่พวกเขาโดยทั่วไปเข้าใจว่ามันทำงานอย่างไร

รันไทม์ AMP มีการใช้งานทั้งหมดใน JavaScript และเริ่มต้นโดยรวมรันไทม์ในเอกสาร AMP เช่นเดียวกับที่คุณทำกับไฟล์ JavaScript ภายนอก:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

จากที่นั่น รันไทม์ AMP จะทำสามสิ่งเป็นหลัก:

• จัดการการโหลดทรัพยากรและการจัดลำดับความสำคัญ
• ใช้ส่วนประกอบ AMP
• รวมตัวตรวจสอบรันไทม์สำหรับ AMP HTML หรือไม่ก็ได้

เครื่องมือตรวจสอบมีความสำคัญต่อการเขียนเอกสารที่สอดคล้องกับ AMP สามารถเปิดใช้งานได้ง่ายๆ โดยผนวก #development=1 ต่อท้าย URL ของเอกสาร จากนั้น สิ่งที่คุณต้องทำคือเปิดคอนโซลเพื่อดูการ์ดรายงานของคุณ

ข้อผิดพลาดมีลักษณะดังนี้:

เอกสาร AMP ที่ดี สะอาด และเป็นไปตามข้อกำหนดจะมีลักษณะดังนี้:

แคช AMP (ไม่บังคับ)

เอกสาร AMP สามารถให้บริการจากเว็บเซิร์ฟเวอร์เช่นเดียวกับเอกสาร HTML อื่นๆ แต่สามารถให้บริการจากแคช AMP พิเศษได้เช่นกัน แคชเสริมใช้เทคนิคต่างๆ เพื่อเพิ่มประสิทธิภาพเอกสาร AMP ให้ดียิ่งขึ้นไปอีก:

• การอ้างอิงรูปภาพสามารถแทนที่ด้วยรูปภาพที่มีขนาดเฉพาะกับวิวพอร์ตของผู้ชม
• สามารถแทรกรูปภาพในครึ่งหน้าบนเพื่อบันทึกคำขอ HTTP เพิ่มเติมได้
• ตัวแปร CSS สามารถฝังไว้เพื่อลดโอเวอร์เฮดฝั่งไคลเอ็นต์
• โหลดการใช้งานคอมโพเนนต์ AMP แบบขยายล่วงหน้าได้
• HTML และ CSS สามารถลดขนาดลงเพื่อลดจำนวนไบต์ที่ส่งผ่านสาย (หรือในกรณีนี้คือคลื่นวิทยุ)

ทุกคนสามารถเรียกใช้แคช AMP ของตนเองบน CDN ของตนเอง หรือผู้เผยแพร่สามารถใช้ Google ได้ฟรี เนื่องจาก Google ดูเหมือนจะรู้เรื่องหนึ่งหรือสองอย่างเกี่ยวกับความสามารถในการปรับขนาด ฉันเดาว่าผู้ใช้ AMP ส่วนใหญ่ยินดีที่จะรับข้อเสนอนั้น (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

แหล่งข้อมูลเพิ่มเติม

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11