เมื่อไม่กี่วันมานี้ ผมอ่านหลายบทความที่กล่าวถึงการเปลี่ยนแปลงในแผนของ Google ที่จะปรับ Site Ranks ใน Google Search ตั้งแต่ปีหน้า วันนี้ สูตรรวม User Interactiveness Elements หลายอย่าง ที่เรียกว่า Core Web Vitals เร็วๆ นี้จะรวม Page Performance ด้วย ผมคิดว่า นี่เป็น Bad Idea
อินสติงค์ต์แรกคือ "โย่ ดinosaurs แบบเก่า" และของผมก็เหมือนกัน ดังนั้นผมตัดสินใจตรวจสอบจริง Google มีบริการหลายอย่าง เช่น Google Search Console (Webmaster Tools ใหม่) PageSpeed Insights และอื่นๆ ที่ช่วยตรวจสอบประสิทธิเว็บไซต์ ผมเช็ค Dedoimedo แล้วเขียนบทความนี้ ไปดูกัน
ทำไม Page Speed ไม่มีความหมาย
ผมเขียนเรื่องนี้หลายๆ ปีก่อน Mobile Hype และ Argument ยังคง stand แต่เพิ่มเติม Page Speed ไม่ได้เป็น Indicator ของ User Experience ในทางใดทางหนึ่ง มันเป็น Indicator ของ Software Stack ที่ Serve หน้าเว็บ บนดี มันยังเป็น Indicator ของ Technical Wealth ซึ่งผมจะอธิบายในไม่ช้า
ก่อนอื่น คณิตศาสตร์ง่ายๆ Core Web Vitals แยกไว้ หน้าที่มี 100 บรรทัดข้อความ และ 10 รูปภาพ เล็กกว่า/สั้นกว่า หน้าที่มี 1,000 บรรทัด และ 100 รูป ไม่มีพารามิเตอร์อื่น หน้าที่มี Data มากกว่าควรโหลดนานกว่า สิ่งนี้บอกอะไรเกี่ยวกับ Content? ไม่ได้บอกอะไรเลย
ดังนั้น ยกเว้นพารามิเตอร์อื่น Less Content = More Speed วิบัติ - หรือไม่ - นี่เข้ากับ Dumbification Patterns ของ Modern Web ที่กลายเป็น Dominant Force ประมาณ 2014 ประมาณเวลาเดียวกับที่ Mobile Internet (Smartphones ในเปลือกหอย) กลายเป็น Prolific
นี่แปลว่า Short Attention Span และ Cheap Consumerism เขียนเนื้อหาให้สั้นที่สุด แทนที่จะส่งมุมข้อความที่แม่นยำและมีประโยชน์ที่สุด Video และ Images แทน Text แน่นอน นี่คือสิ่งที่คุณต้องการเพื่อให้ Low-IQ Masses เพลิดเพลิน เพราะพวกเขาไม่ถนัดหัวข้อซับซ้อนยาวๆ หลังจากนั้น Stupid People ดีต่อ Business พวกเขา Traits ที่ทำให้ใช้เงินซื้อของไร้ค่า แก้ไขง่าย ควบคุมง่าย Hello, Profits!
ที่สอง Page Loading ไม่บอกอะไรเกี่ยวกับ Nature ของหน้า หน้าที่ต้องกรอก Form ต่างจากหน้าทีสรุป History of Norman Conquests ในกรณีแรก Responsiveness เทียบกับ Pure Speed อาจสำคัญ ในกรณีหล者 มันค่าไร้ความหมาย ตอนนี้ไม่ใช่หัวข้อ Trivial มี Deep, Complex Science ด้านหลัง ผมเองก็ Research แบบจริงจัง และ Present ที่ Conference ต่างๆ ในอดีต แต่ไว้ก่อน
ตัวอย่างปฏิบัติ: Linux Review ทั่วไปที่ผมเผยแพร่ที่นี่ ค่อนข้างยาว ปกติ ~40K Characters (~2,500-3,000 คำ) และ ~30-40 รูปภาพในหน้าเดียว เนื้อหานี้ใช้เวลาโหลด - ไม่นานมาก แต่นานบ้าง
อย่างไรก็ตาม... บทความเริ่มต้นด้วย 2 ย่อหน้าข้อความ ซึ่งอ่านใช้เวลา 15-20 วินาที ถ้าไม่กว่านั้น จนกว่าผู้ใช้อ่านจบ Assets ทั้งหมดโหลดเสร็จ 10 รอบแล้ว Speed ไม่มีผลต่อ User Experience เลย
แต่... หากมองจากมุมมอง "SEO" มัน "ยาวเกินไป" สำหรับ Pundits ที่มโนกัน ไม่ได้ลงรายละเอียดหรือให้ Spotlight กับ Software/Ideas ที่ผมเกลียด ผมเคยเห็น "SEO" Tools ต่างๆ แนะนำว่า Article ควรไม่เกิน 500-600 คำ หรือคล้ายๆ กัน ตัวเลขนี้ meaningless เอง แต่เกิดขึ้นเมื่อพยายามวาง Pseudo-science รอบสิ่งที่ Machines ไม่สามารถ Quantify ได้จริง
และนั่นคือ Quality
สิ่งหนึ่งที่ไม่เคยกล่าวถึงใน "SEO" Stuff คือ Quality นี่คือสิ่งที่ Machine ไม่มีวัน Check ได้ Quality เหมือน Trust ใช้เวลาหา สร้าง บำรุง Quality มี Long Temporal Function คุณไม่จำเป็นตัดสินว่า "Quality Content" จากแค่ 1-2 ประโยคของ Blog (ได้ ถ้าคุณ Skilled ใน Domain) โดยทั่วไป ต้องการ Experiences หลายๆ ครั้ง ซ้ำๆ เพื่อวัด Consistency และ Accuracy ของเนื้อหาที่เผยแพร่
กลับไปที่ Speed เล่นกันดู หากอยากหน้าโหลดเร็วที่สุด คุณอยาก Content สั้นที่สุด ซึ่งอาจหมายถึง Cut Down Quality แล้วคุณอาจ Split Content หลายหน้า แต่แล้วคุณบังคับ Readers คลิกเลขหรือลูกศรซ้ำๆ ผมไม่แน่ใจ Sentiment ทั่วไป แต่ผมรู้สึก Tedious และพยายามหลีกเลี่ยงมากที่สุด (ยกเว้น Exception เล็กๆ น้อยๆ)
แนวคิด Web Pages (หลายหน้า Serve "Pages" ของเนื้อหาเดียวกัน) เป็นผลลัพธ์ของ Pointless Chase หลัง Speed ที่ Speed ไม่จำเป็น เพราะถ้าพูดถึง Images Image Galleries โดยนิยามคือ Set ของ Frames อิสระและ獨立 หากเป็น Text คือ Long Content น่าจะ Justified ผู้ที่ตั้งใจอ่าน มี Patience สำหรับทั้งหมดตั้งแต่แรก ดังนั้น Speed Consideration จริงๆ เป็น Catch-22
ดีแล้ว มา Score หน้าเว็บกัน
แต่เหมือนที่พูด ต้องมีตัวเลขจริง ผมทำ Speed Tests สำหรับ dedoimedo.com มาแสดงผล โปรดทราบ คุณได้ 2 ชุดผลลัพธ์แยกกัน - Desktop และ Mobile Score 0-100 ยิ่งสูงยิ่งดี
ดูข้อมูล Desktop Performance ดี Mobile - ไม่ค่อยดี เนื้อหา EXACTLY THE SAME ความต่างเล็กน้อย จากที่เห็น มีแค่ 200ms ความต่างใน FCP Parameter
Lab Data ให้มากกว่า - และที่นี่ได้ข้อมูลเพิ่มเติม แต่อีกครั้ง โดยไม่คำนึงถึง Nature ของหน้า ตัวเลขไม่หมายความมาก ตัวอย่าง Time to Interactive ไม่มี Interactiveness จริงบนหน้าผม - Text และ Images อ่าน ดู ส่วนหนึ่งของเวลา - เนื้อหา Visibly Populated เร็วแค่ไหน แสดงโดย Speed Index กลับไปที่ Argument ของผมว่า Speed ไร้ความหมาย Index Page บน Dedoimedo แสดง News Headings ของเนื้อหาที่เผยแพร่ไปหลายเดือน แน่นอน หากน้อยลง จะโหลดเร็วขึ้น แต่นั่นไม่ใช่จุด
ตัวเลขดูน่ากลัว แต่เชื่อผม Dedoimedo ได้ Score สูงกว่าเว็บไซต์อื่นส่วนใหญ่ ลอง Punch In Tech Publications ยอดนิยม ดูเอง
ตอนนี้ เพื่อเข้าใจมากขึ้น ผมขยายผลลัพธ์ ดู Opportunities และ Diagnostics ในรายงาน - 基本上 คือ Recommendations ที่ Algorithms ด้านหลังรายงานเสนอ โปรดทราบ ไม่ส่งผลต่อ Score แต่บ่งบอกด้วยตัวเอง
Diagnostics - โค้ด Third-party บางอย่าง Block Main Thread ประมาณ 1 วินาทีเต็ม Breakdown แสดงว่า Primary Culprit คือ Google Ads Code ที่ผมใช้บนหนต่างๆ Document.write() ถูก Flag เป็น Issue อีกอย่างสำหรับ Slow Connections และอีกครั้ง เป็น Third-party Code
Opportunities - สิ่งน่าสนใจ Images แนะนำใช้ "Next-gen" Formats แทน JPG/PNG เก่า คาดว่าประหยัด 2.7 วินาทีโหลด แต่ 2.7 วินาทีน้อยกว่าเวลาอ่าน 1 บรรทัดบนหน้าใดหนึ่งของผม ใช้งานจริง ไม่มีความแตกต่าง แต่กลับไปที่การใช้ Image Sets ใหญ่ในบทความ นี่คือสิ่งที่ช่วยให้คนได้ Best Value จาก Guides และ Tutorials ของผม Images เองอาจ Useless
สิ่งที่น่าสนใจอีก - Unused JavaScript - ทั้งหมดเป็น Third-party Content เกี่ยวกับ Google Stuff ที่ผมใช้บน Dedoimedo ผมภูมิใจในความ Precise และ Meticulous ลอง Implement Best Solutions เพื่อ Users - Readers, People Who Matter - ได้ Best Experience
นี่เป็นเหตุผล Dedoimedo มี ZERO Organic JavaScript - และเหตุผลที่ควร Brisk ไม่มี Cookies, Comments, Nothing Third-party Code แค่ Analytics พื้นฐาน Search บาง Ads พยายามหาเงิน และ Cookie Overlay Applet ที่ GDPR และ CCPA ต้องการ แต่ดูผลข้างต้น สิ่งที่ดีที่สุดคือ Scrap Third-party Scripts ทั้งหมด
ผมไม่ได้ Invent Code ข้างต้น ใช้ Ads Code ตามที่ Google กำหนด ใช้ Cookie Applet Code ตามที่ Civic กำหนด หากมี Opportunities ปรับปรุง Loading เช่น Async Functions ผม Powerless ในการ Implement ไม่มี Control Over Third-party Companies สร้าง Code อย่างไร Control เดียวคือเลือกใช้ - และอาจต้อง Revisit การเลือกนั้นด้วย
แล้วผลลัพธ์ก็ต่างกันค่อนข้างระหว่าง Test กับ Test นี่คือ Mobile Result จากสองวันหลัง Test แรก - ผมไม่แคร์ แต่มันทำให้ผมจะนำผลลัพธ์ไปใช้ยังไง หากเปลี่ยนมากโดยไม่มี Input จากผม?
ตัวเลขขัดแย้งกับ Google Search Console Report - ทุกหน้าระบุ Good Page Performance - แต่ Field Data Text Report ดูเหมือน Agree ในทางด้าน Mobile Usability Issues เพียง 2 หน้าจาก Indexed Pages ทั้งหมด และทั้งคู่ดูเป็น False Positives เพราะ Live Test Report All Green (และ Render ถูกต้องบนโทรศัพท์) ตัวอย่าง หนึ่งใน 2 หน้าที่ Flagged คือ Windows 10 Exploit Guide:
พูดถึง Friendly ฟอนต์สีเทาอ่อนบนพื้นหลังเทา ไม่ Friendly จริงๆ ไกลมาก
สรุป
นี่คือ Findings ของผม ตัวเลขที่ไม่บอกอะไรมากเอง - โดยไม่มี Context คุณไม่รู้ว่าเกิดอะไรขึ้น ตัวเลขต่างกันมากระหว่าง Desktop/Mobile และต่างกันจาก Sample ถึง Sample ตัวเลขไม่ Agree กับ Tool Set อื่นที่ให้ฟังก์ชันคล้ายกัน ตัวเลขดูได้รับอิทธิพลหลักจาก Third-party Scripts ส่วนใหญ่สร้างโดย Google Data บางอย่างมี False Positives
นี่คือ Short, Simple Test - และแสดง Variation และ Ambiguity มากในการตีความ Performance/Speed อีกครั้ง เราไม่รู้ Content ด้านหลังตัวเลข ไม่รู้ Quality จริง หน้าอาจมี Perfect Score แต่ Modern Internet ส่วนใหญ่คือ Cesspit นี่คือสิ่งที่ต้อง Address ก่อน แต่ขอโทษ ผมแค่ Cook ต่ำๆ
ไม่แน่ใจใครสนใจสิ่งที่ผมเขียน - 'tis One Man's Opinion แต่ผมเชื่อว่าเพิ่ม Speed ใน Formula จะทำให้แย่ลง Things แย่อยู่แล้วกับคนไล่ "SEO" Unicorn แม่น้ำ Speed จะนำไปสู่ "Fast" Content ที่เจือจางมากขึ้น Fluff ไร้สาระ มากขึ้น ที่ออกแบบมาเพื่อ Please The Machine Hint: ผมไม่เคยลอง "SEO" Recommendation เลย และ Popularity ของไซต์ผม โต, ตก, โตอีก (Zero Intervention) ตก, โต ตาม Beat ของ Financial Considerations ที่ควบคุมไม่ได้ แทนที่จะ Focus ที่ Quality และ Fun แต่ผมรู้ว่าผมเป็น Dying Breed ของ Old School Techies และ Future 属于 Touch-happy Idiots 没关系 因为那是他们的未来 我将从某个阳光岛屿的颓废退休生活中向他们致敬 享受那些从低智商人群中获取暴利的公司的股息
Cheers.
