การแสดงผล SEO: Google แยกแยะเนื้อหาของคุณอย่างไร

นี่คือสำเนาบทสนทนาระหว่าง Bartosz Goralewicz, Martin Splitt จาก Google และ Jason Barnard พวกเขาโฮสต์การสัมมนาผ่านเว็บเพื่อหารือเกี่ยวกับ Rendering SEO ในทางปฏิบัติ คุณสามารถดูการบันทึกการสัมมนาผ่านเว็บได้ที่นี่ แต่เนื่องจากข้อมูลดังกล่าวอัดแน่นไปด้วยข้อมูลมากมาย เราหวังว่าคุณจะพบว่าข้อความถอดเสียงนี้มีประโยชน์เช่นกัน!

Bartosz: วันนี้ เราจะมาดูการเรนเดอร์จากมุมมองของ Google ซึ่งต่างจากที่เราเห็นใน Chrome เล็กน้อย ดังนั้น Martin จึงพร้อมที่จะนำทางเราผ่านผืนน้ำที่ขุ่นมัวเหล่านั้น

โดยสังเขปในการวิจัยของเรา และอีกครั้ง นี้ไม่ได้มาจาก Martin เราเริ่มเห็นการกล่าวถึงการแสดงภาพและการจัดวางครั้งแรกในสิทธิบัตรของ Google ประมาณปี 2011 และทฤษฎีส่วนตัวของฉันก็คือนั่นเป็นสาเหตุที่การอัปเดตคุณภาพเนื้อหาของ Google Panda และสิ่งที่ยอดเยี่ยมทั้งหมดเหล่านั้น เริ่มเกิดขึ้นประมาณวันนั้น

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

ดังที่ฉันได้กล่าวไปแล้ว สิทธิบัตรส่วนใหญ่ของ Google ที่เรากล่าวถึงในหัวข้อนี้ และนั่นคือจุดเริ่มต้นของสิ่งนี้ โดยเน้นที่การจัดวาง

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

ดังนั้นนี่คือสิ่งหนึ่ง และเป็นเวลาหลายปีที่เรามุ่งเน้นไปที่ JavaScript SEO ตามที่ Jason กล่าวถึง และเมื่อเจาะลึกลงไป เราตระหนักว่า JavaScript SEO เป็นส่วนใหญ่ "Google สามารถเห็นเนื้อหาของคุณอย่างถูกต้อง คุณสามารถเปลี่ยน JavaScript เป็น HTML ได้หรือไม่" และสิ่งต่างๆ เช่นนั้น แต่เมื่อเราดำดิ่งลึกลงไปอีกหน่อย เราเห็นว่านี่เป็นเพียงส่วนปลายของภูเขาน้ำแข็ง

หลายๆ แง่มุมของวิธีที่ Google แสดงเนื้อหาและวิธีที่พวกเขาเห็นเลย์เอาต์จะส่งผลต่อ SEO ส่วนใหญ่ที่เกิดขึ้นหลังจากระยะเริ่มต้นของการรวบรวมข้อมูล การแสดงผล และการจัดทำดัชนี

ดังนั้นในฐานะเอเจนซี่ เราจึงออกจากวงการ JavaScript SEO ไปเล็กน้อย และเราเจาะจงไปที่ Rendering SEO ซึ่งซับซ้อนกว่า น่าตื่นเต้นกว่ามาก แม้ว่าเราจะพยายามทำให้มันง่ายในวันนี้ เจสัน คุณต้องเป็นผู้พิทักษ์สิ่งนั้น

มีหลายสิ่งที่น่าตื่นเต้นทีเดียว เราอาจจะไม่ได้คำตอบที่แน่นอนจาก Martin เขาเกลียดสไลด์นี้ ฉันขอโทษ Martin

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

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

สิ่งที่ฉันอยากจะพูดถึงเมื่อเราคุยกันในวันนี้คือเว็บไซต์ของคุณมีสี่เฉดสี พวกเราหลายคนปิดบังเนื้อหาโดยไม่ทราบสาเหตุ เพราะตอนนี้เนื้อหาของคุณดูแตกต่างบนมือถือด้วย JavaScript และไม่มี JavaScript และสิ่งนี้เกิดขึ้นกับเว็บไซต์ส่วนใหญ่ในปัจจุบัน ดังนั้นจึงไม่ใช่แค่เว็บไซต์ที่ขับเคลื่อนด้วย React หรือ Angular เท่านั้น แต่ยังเกี่ยวกับ WordPress , Wix, อาจเป็น Duda เช่นกัน และเฟรมเวิร์กที่ง่ายกว่านั้นส่วนใหญ่ เรายังมีปัญหาเดียวกันกับเดสก์ท็อป จึงมีหลายวิธีที่คุณสามารถโต้ตอบกับเนื้อหาได้ และส่วนใหญ่เป็นเพราะการเรนเดอร์ โค้ดนี้จะแสดงผลบนอุปกรณ์ปลายทางอย่างไร

เพื่อไม่ให้เป็นการเสียเวลา เรามาเริ่มกันเลยดีกว่า เรามีมาร์ตินอยู่ที่นี่ ฉันจะไม่ให้เวลาคุณมากเกินไป

ฉันมีคำถามแรกเพียงเพื่อเริ่มต้นขึ้นอย่างใด มาร์ติน การแสดง SEO ช่วยให้อันดับดีขึ้นได้ไหม ฉันคิดว่านี่เป็นคำถามแรกที่อยู่ในหัวของทุกคน

มันใช้งานได้จริงหรือ เป็นสิ่งที่จะทำให้มีการเข้าชม โอกาสในการขาย สิ่งตลกและเจ๋ง ๆ เหล่านั้นหรือไม่?

Martin: ฉันหมายถึง ปกติฉันไม่ตอบคำถามจัดอันดับ ฉันจะยกเว้นที่นี่

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

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

Bartosz: สิ่งหนึ่งที่ฉันต้องการทำก่อนที่เราจะเจาะลึกคำถามจากผู้ชมคือ การเรนเดอร์ นั่งอยู่ในสถานการณ์ทั้งหมดหรือไม่

เราเข้าใจได้อย่างรวดเร็วว่าสิ่งใดคือสิ่งแรกคือไก่หรือไข่ แต่ฉันเข้าใจว่า Google สร้างคิวจากนั้นจึงรวบรวมข้อมูล แสดงผล และจัดทำดัชนีหน้าเว็บอย่างชัดเจน ซึ่งจะทำให้เข้าใจง่ายเกินไปหรือไม่

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

หากคุณมีร้านค้าออนไลน์ และพรุ่งนี้คุณมาออนไลน์ด้วยเว็บไซต์ร้านค้าออนไลน์แห่งใหม่ และคุณมี URL ผลิตภัณฑ์นับล้านรายการ เซิร์ฟเวอร์ของคุณอาจขัดข้องหากเรารวบรวมข้อมูล URL เหล่านี้ทั้งหมดพร้อมกัน เราจึงต้องกระจายเรื่องนี้ออกไป ดังนั้นจึงมีคิวอยู่ระหว่างการค้นพบ URL และ URL ที่รวบรวมข้อมูลจริงๆ

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

สิ่งที่เกิดขึ้นคือเมื่อเรารวบรวมข้อมูลแล้ว เราสามารถดู HTML ที่เราได้รับ ดูสถานะ HTTP ได้ หากเป็นสถานะ 404 การประมวลผลเกือบจะสิ้นสุดที่นี่ หากมีเมตาแท็กของโรบ็อตที่ระบุว่า noindex แสดงว่างานของเราสิ้นสุดที่นี่เช่นกัน

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

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

Jason: นั่นชัดเจนจริงๆ

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

มาร์ติน : โอ้ ใช่ นั่นเป็นเรื่องจริง

Bartosz : ดังนั้น แม้ว่าคุณจะมีเว็บไซต์ที่ไม่ใช่ Javascript เช่นไม่มี JavaScript และไม่มีการอ้างอิงสคริปต์ภายนอก คุณควรกังวลเกี่ยวกับการเรนเดอร์ด้วย

Jason: ฉันกำลังจะถามคำถาม: พวกเราหลายคนกังวลเรื่องการแสดงผลเพราะแนวคิดนั้น ความคิดที่ว่ามันเป็น JavaScript เท่านั้น เราทุกคนกังวล...?

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

Jason : โดยพื้นฐานแล้ว ถ้าคุณไม่มี JavaScript คุณต้องกังวลเกี่ยวกับเรื่องนี้หรือไม่?

มาร์ติน : คุณไม่จำเป็นต้องกังวลเกี่ยวกับเรื่องนี้ แต่คุณยังคงได้รับผลกระทบจากมัน ยังคงมีนัยที่อาจเกิดจากการเรนเดอร์

เจสัน : โอเค ยอดเยี่ยม

มาร์ติน : นั่นเชื่อมโยงกับสิ่งที่ Bartosz กล่าวไว้ก่อนหน้านี้ เช่น ข้อความในครึ่งหน้าบน หรือ Google คิดว่าเนื้อหาหลักของคุณอยู่ที่ใดและอะไรทำนองนั้น

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

Bartosz : ถูกต้องทั้งหมด

Jason : แต่โดยพื้นฐานแล้วมันตัดสินใจอย่างไร?

Martin : งั้นเราคงต้องคุยกันสักหน่อยว่าการเรนเดอร์จริงๆ คืออะไร? เพราะฉันไม่แน่ใจว่าทุกคนรู้ว่ามันหมายถึงอะไรใช่ไหม? เราควรทำอย่างนั้นหรือ?

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

มาร์ติน : เย้!

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

เจสัน : พูดเก่ง. กำหนดการแสดงผล มันคืออะไร มีขั้นตอนอย่างไร?

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

แหล่งข้อมูลของเว็บไซต์คือส่วนผสม เช่น ไฟล์ CSS, JavaScript และรูปภาพของวิดีโอ สิ่งที่คุณโหลดเพื่อทำให้หน้าเว็บดูเป็นอย่างไรในภายหลัง

เว็บไซต์ที่คุณรู้จักและใช้ในเบราว์เซอร์ของคุณที่คุณเห็นในเบราว์เซอร์ นั่นคือจานสุดท้าย

การเรนเดอร์นั้นค่อนข้างมากในการปรุงอาหาร กระบวนการเตรียมการ

โดยพื้นฐานแล้วการรวบรวมข้อมูลจะเข้าไปในหนังสือเล่มใหญ่ของสูตรอาหารและนำหน้าที่มีสูตรออกมาแล้วนำไปใส่ในขอบเขตของเรา โดยพื้นฐานแล้วเรากำลังยืนอยู่ที่นี่บนโต๊ะในครัว และเราเพียงแค่รอให้การทำอาหารเริ่มต้น และการคลานก็จะเป็นพื้นฐาน ส่งสูตรมาให้เรา

แล้วการเรนเดอร์ก็คือกระบวนการที่เรนเดอร์ไป “AHA น่าสนใจ! โปรแกรมรวบรวมข้อมูลที่อยู่ตรงนั้น คุณหาส่วนผสม 10 อย่างนี้ให้ฉันได้ไหม" และโปรแกรมรวบรวมข้อมูลก็พูดอย่างสะดวก "ใช่ ฉันมีส่วนผสม 10 อย่างนี้ที่คุณต้องการ" แล้วเราก็เริ่มทำอาหาร นั่นคือการแสดงผล

ดังนั้นการเรนเดอร์จะแยกวิเคราะห์ HTML โดยพื้นฐานแล้ว HTML เมื่อรวบรวมข้อมูลจากแบบฟอร์มเป็นเพียงกลุ่มข้อความ จัดรูปแบบที่สะดวก แต่เป็นข้อความ

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

เช่น. โอ้ มีส่วนหัวอยู่ที่นี่ ตกลง มีรูปภาพอยู่ ถัดจากรูปภาพ มีข้อความเป็นพวง และใต้รูปภาพ มีอีกหัวเรื่องหนึ่ง หัวเล็กกว่า หัวระดับล่าง เยื้องโดยทั่วไป โครงสร้างของเนื้อหา จากนั้นก็มีวิดีโอ จากนั้นด้านล่างวิดีโอจะมีข้อความเพิ่มเติม และในข้อความมี 3 ลิงก์อยู่ที่นี่ ที่นี่ ที่นี่

และกระบวนการประกอบทั้งหมดนี้ การทำความเข้าใจว่ามันคืออะไร และประกอบเป็นภาพที่คุณสามารถโต้ตอบได้ภายในหน้าต่างเบราว์เซอร์ของคุณ - นั่นคือการแสดงผล

และในส่วนของการเรนเดอร์ ในขั้นแรก เรารัน JavaScript

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

ดังนั้น ถ้าฉันไม่ได้เรียกใช้ JS และเพียงแค่ดึงทรัพยากร ฉันอาจไม่ได้รับขั้นตอนที่จำเป็นจริงๆ ในการหั่นหัวหอม หรือเปิดไข่แล้วตีให้เข้ากันก็ได้ ใครจะไปรู้

คุณบอกได้ไหมว่าฉันเพิ่งทำอาหารเย็นและตอนนี้ฉันหิวมาก ฉันเสียใจมาก!

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

ข้อมูลนี้มีความสำคัญสำหรับเราเช่นเดียวกับการรัน JavaScript เนื่องจาก JavaScript อาจเปลี่ยนแปลง ลบ หรือเพิ่มเนื้อหาที่ไม่ได้อยู่ใน HTML เริ่มต้นตามที่เซิร์ฟเวอร์ส่งมา

นั่นคือการแสดงผลโดยสังเขป จาก "เรามี HTML บางส่วน" เป็น "อาจมีพิกเซลจำนวนมากบนหน้าจอ" นั่นคือการแสดงผล

Bartosz : ฉันต้องการเพิ่มบางสิ่งที่มาร์ตินจะไม่พูด เพราะเขาทำงานที่ Google เมื่อพิจารณาจากด้านเทคนิค SEO ของสิ่งต่าง ๆ การเรนเดอร์นั้นค่อนข้างแพง – ผลกระทบที่มีต่อ Google อย่างแท้จริงนั้นเป็นปริศนาที่ยิ่งใหญ่ และนี่คือสิ่งที่เราทำการวิจัยอย่างต่อเนื่อง เรายังเปิดตัวบริษัทแยกต่างหาก ซึ่งเป็นเครื่องมือในการทำเช่นนั้น เรื่องสั้นโดยย่อ การเรนเดอร์ค่อนข้างแพงสำหรับ Google สำหรับอุปกรณ์มือถือ หากคุณมีเช่น Alcatel 1X เช่นโทรศัพท์รุ่นเก่า อาจเป็นโทรศัพท์ที่ถูกกว่า มันคงยากกับเว็บไซต์อย่าง BBC, The Guardian ซึ่งจัดส่ง JavaScript จำนวนมาก ซึ่งเป็นสิ่งที่ Google จะต้องดิ้นรนด้วย แต่เรื่องสั้นโดยย่อ การเรนเดอร์นั้นมีราคาแพง และจากประสบการณ์ของเรา สคริปต์บางรายการ บางเว็บไซต์ไม่ได้แสดงผลอย่างเหมาะสมสำหรับ Google และจบลงด้วยการเลือกไม่ถูกด้วยเหตุผลหลายประการ

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

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

คุณคิดอย่างไรกับมาร์ตินคนนี้

มาร์ติน : ฉันชอบคำถามนี้เพราะมันสร้าง ช่วงเวลาที่น่าสนใจที่นี่

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

มีคนเรียกจาวาสคริปต์ว่า CO2 ของอินเทอร์เน็ต ฉันไม่คิดว่ามันผิดทั้งหมด เป็นการเปรียบเทียบที่ดีและเหมาะสม

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

Jason : จากมุมมองของฉัน คุณกำลังพูดว่า: เพิ่มประสิทธิภาพ ทำให้ง่ายขึ้นสำหรับ Google – รางวัลที่ Google มอบให้เราคืออะไร มันเร็วกว่าสำหรับคุณ ดังนั้น คุณจึงสามารถทำสิ่งต่างๆ ได้มากขึ้นพร้อมๆ กันหรือไม่?

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

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

Jason : ใช่ ยิ่งเร็วเท่าไหร่ โอกาสที่คุณจะหยิบมันขึ้นมามากเท่าไหร่ โอกาสที่คุณจะไปส่งก่อนจะไปถึงที่นั่นก็น้อยลงเท่านั้น

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

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

มีต้นไม้มาเกี่ยวข้องด้วย และฉันไม่ต้องการให้ทุกคนสับสน โดยพื้นฐานแล้ว สิ่งที่เกิดขึ้นคือในวินาทีแรกที่เรามีข้อความ เราจะแบ่งสิ่งนั้นออกเป็นองค์ประกอบแต่ละส่วน และสร้าง Document Object Model นั่นคือ DOM ที่ผู้คนอ้างถึง โดยพื้นฐานแล้ว DOM เป็นเพียงวิธีพูดของเบราว์เซอร์: ดังนั้นฉันจึงมีชื่อนี้ ที่มีข้อความอยู่ข้างใน นั่นคือโหนดอื่นในแผนผังนี้ จากนั้นฉันก็มีบล็อกข้อความนี้ และภายในบล็อกข้อความก็มีลิงก์ที่มีข้อความอยู่ข้างใน ลิงก์ ตรงนี้คือรูปภาพ และคุณรู้ว่านั่นคือทุกอย่างที่อยู่ในหน้า และนั่นรวมถึงมาร์กอัปสคีมา เช่นเดียวกับเมตาแท็กทั้งหมด และชื่อ และทุกอย่าง

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

Jason : Bartosz คุณกำลังแสดงองค์ประกอบที่ไม่ได้จัดทำดัชนี น่าจะเป็นแผนผังเค้าโครง คุณกำลังตัดสินใจก่อนที่จะเข้าสู่ขั้นตอนการจัดทำดัชนี “เราไม่ต้องการ มันไม่น่าสนใจ ไม่ยาวเกินไป หรือสว่างเกินไป” นั่นเป็นวิธีที่คุณเข้าใจ Bartosz หรือไม่?

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

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

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

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

แต่โดยพื้นฐานแล้ว เราสามารถอ่านมันได้จากโครงสร้างเนื้อหาใน HTML แล้วและคิดออก “ดูเหมือนว่าจากการประมวลผลภาษาธรรมชาติทั้งหมดที่เราทำกับเนื้อหาข้อความทั้งหมดที่เราได้มาที่นี่ ดูเหมือนว่าหลักๆ แล้วเกี่ยวกับหัวข้อ A – อาหารสุนัข – แล้วมีสิ่งอื่นที่นี่ซึ่งดูเหมือนว่าจะเชื่อมโยงไปยังที่เกี่ยวข้อง ผลิตภัณฑ์ แต่มันไม่ได้เป็นส่วนตรงกลางจริงๆ มันไม่ใช่เนื้อหาหลักที่นี่ ดูเหมือนว่าจะเป็นส่วนเพิ่มเติม จากนั้นก็มีต้นแบบจำนวนมาก” ดังนั้นเราจึงพบว่าเมนูค่อนข้างเหมือนกันในทุกหน้าเหล่านี้ และดูเหมือนเมนูที่เรามีในหน้าอื่นๆ ทั้งหมดของโดเมนนี้ หรือเราเคยเห็นมาก่อน

จริง ๆ แล้วเราไม่ได้เรียงตามโดเมนหรือ "โอ้ นี่ดูเหมือนเมนูเลย" เราหาสิ่งที่ดูเหมือนสำเร็จรูปและมีน้ำหนักต่างกันเช่นกัน

ดังนั้น หากคุณมีเนื้อหาบนหน้าเว็บที่ไม่เกี่ยวข้องกับหัวข้อหลักของเนื้อหาที่เหลือ เราอาจไม่ได้พิจารณาเนื้อหาดังกล่าวมากเท่าที่คุณคิด เรายังคงใช้ข้อมูลดังกล่าวสำหรับการค้นหาลิงก์และค้นหาโครงสร้างเว็บไซต์ของคุณและทั้งหมดนั้น แต่ถ้าหน้าเว็บของคุณมีคำศัพท์ 10,000 คำเกี่ยวกับอาหารสุนัขและเช่น 2,000-3,000 คำบนจักรยาน เนื้อหานี้อาจไม่ใช่เนื้อหาที่ดีสำหรับจักรยาน

Jason: Semantic HTML5 ช่วยคุณได้หรือไม่?

มาร์ติน : มันช่วยเราได้ แต่ไม่ใช่สิ่งเดียวที่เรามองหา ใช่

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

มาร์ติน : ครับ

Bartosz : ดังนั้นเพียงแค่ปิดหัวข้อนี้และก้าวไปข้างหน้า เช่นบางครั้ง คุณจะเห็นส่วนหนึ่งของเนื้อหานั้น เช่นเดียวกับรายการที่เกี่ยวข้อง ซึ่งมักจะอาศัย JavaScript บ่อยมากใน JavaScript จำนวนมาก

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

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

มาร์ติน : มันไม่ใช่คำถามที่เราควรหลีกเลี่ยง แต่เป็นคำถามที่น่าสนใจ

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

มีช่วงหนึ่งที่เราพูดว่า “ตกลง นี่แสดงมานานพอแล้ว ฉันคิดว่าเราทำได้ดี” มีฮิวริสติกอีกจำนวนมากในสถานที่ แต่โดยพื้นฐานแล้ว หากผู้ใช้จริงคิดว่า "นี่ยาวเกินไป" เราก็ถือว่ายาวเกินไปเช่นกัน

ใช่เลย

Bartosz : ดังนั้น ฉันคิดว่าสำหรับผู้ชม สิ่งหนึ่งที่ต้องเน้นเล็กน้อย นี่คือสิ่งที่เราพูดถึงก่อนการสัมมนาทางเว็บ คุณพูดถึงแหล่งข้อมูลค่อนข้างน้อย แหล่งข้อมูลใดที่เราควรกังวลเพื่อทำให้ชีวิตของ Google ง่ายขึ้น

มาร์ติน : ส่วนใหญ่ฉันจะกังวลเกี่ยวกับไฟล์ JavaScript จริงๆ แล้ว

Bartosz : ไม่ ทรัพยากรเช่น ทรัพยากรเซิร์ฟเวอร์ คราวที่แล้วคุณอธิบายได้ค่อนข้างดี และฉันคิดว่านี่น่าจะสร้างคุณค่าให้กับผู้ฟัง

Martin: เมื่อกี้ฉันพูดว่าอะไรนะ?

Bartosz: คุณบอกว่าคุณไม่สนใจ RAM ขนาดนั้น คุณกังวลเกี่ยวกับ CPU เป็นต้น ฉันจำไม่ได้ว่าคุณพูดอะไรเกี่ยวกับพื้นที่เก็บข้อมูล แต่นั่นก็อยู่ในการสนทนาด้วย แต่จากสมมติฐานของฉัน CPU เป็นองค์ประกอบหลักที่ต้องระวังในขณะนี้ ดังนั้นหากเว็บไซต์ของคุณต้องใช้เวลาของ CPU มากในการเรนเดอร์ นี่คือสิ่งที่ต้องพิจารณา นี่คือสิ่งที่ต้องปรับให้เหมาะสม มันจะถูกต้องไหม?

มาร์ติน : ใช่ ตอนนี้ฉันรู้แล้วว่าเราจะไปที่ใดกับคำถามนี้ ขอบคุณมากที่ช่วยฉันออกไปที่นั่น Bartosz

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

ส่วนสุดท้ายไม่เป็นความจริงสำหรับ Google Search บริการ Google Web Rendering ซึ่งเป็นส่วนหนึ่งของ Google Search ที่แสดงผลจริง ๆ ไม่สนใจพิกเซลดังนั้นเราจึงไม่ได้ทาสีพิกเซลจริงดังนั้นหากคุณเห็นสิ่งที่มีราคาแพงมากฉันยินดีที่จะอธิบายว่าถ้า ซึ่งทำให้เกิดความสับสน หากคุณมีบางอย่างที่มีราคาแพงมาก คุณไม่ต้องกังวลเรื่องนี้เพราะเราไม่ได้ใช้ GPU จริงในการวาดภาพพิกเซลใดๆ ดังนั้นเราจึงไม่สนใจเกี่ยวกับสีใดๆ ที่เกี่ยวข้องกับการระบายสี

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

Jason : และคำถามหนึ่งที่นี่เช่นกัน ก้าวไปข้างหน้าด้วยนั่นคือ: ยิ่งคุณเห็นไซต์ประเภทใดประเภทหนึ่งมากขึ้น การแสดงผลจะง่ายขึ้นหรือไม่? หรือไม่มีผลอะไรจากการใช้แพลตฟอร์มอย่าง Duda หรือ WordPress? มันช่วยได้หรือว่ามันนอกกรอบโดยสิ้นเชิง?

มาร์ติน : อาจจะหรือไม่ช่วยก็ได้ เหตุผลก็คือในทางทฤษฎี สิ่งที่ดีเกี่ยวกับแพลตฟอร์มคือเมื่อใดก็ตามที่พวกเขาเพิ่มประสิทธิภาพแพลตฟอร์มจริง คุณจะได้รับการเพิ่มประสิทธิภาพนี้ฟรี คุณไม่จำเป็นต้องทำอะไรกับเรื่องนั้นจริงๆ ก็ดีแล้ว หากคุณสร้างสิ่งของคุณเอง คุณต้องทำงานปรับให้เหมาะสมและไม่เคยมีการเพิ่มประสิทธิภาพใด ๆ ที่ตกลงไปในตักของคุณอย่างน่าอัศจรรย์และสิ่งต่าง ๆ จะดีขึ้น แต่นั่นก็เป็นความจริงสำหรับ CMS หรือแพลตฟอร์มที่สร้างไว้ล่วงหน้าหรือโอเพ่นซอร์สหรือแชร์แบบสาธารณะ ในทางกลับกัน แพลตฟอร์ม เนื่องจากเป็นแพลตฟอร์มที่กว้างและมีลักษณะทั่วไป จึงมักจะมีน้ำหนักที่ตายได้มาก เพียงเพราะบางเว็บไซต์อาจใช้ฟังก์ชันบางอย่าง และหากเว็บไซต์ของคุณไม่รองรับ แสดงว่าแพลตฟอร์มนั้นมีน้ำหนักจริง ยังคงและนั่นอาจไม่ดีนัก

เจสัน : ในฐานะเว็บมาสเตอร์หรือนักพัฒนา จำเป็นไหมที่จะต้องเอา Dead Weight ออก แม้ว่ามันจะไม่ได้ทำอะไรเพียงเพื่อกำจัดมันออกไป มันจะไม่มาขวางทาง?

มาร์ติน : ขอโทษค่ะ คุณช่วยวิ่งผ่านฉันอีกได้ไหม

Jason : คุณกำลังพูดถึง Dead Weight ถ้าฉันสามารถเอาออกได้ มันจะเป็นชัยชนะที่มหัศจรรย์สำหรับฉันไหม

Martin: ใช่ แต่สิ่งที่เกี่ยวกับแพลตฟอร์มคือโดยปกติคุณไม่สามารถ...

Bartosz : ฉันคิดว่าเราสามารถย้อนกลับไปใช้งบประมาณของโปรแกรมรวบรวมข้อมูลได้เล็กน้อย ดังนั้น สิ่งหนึ่งที่เกี่ยวกับการเรนเดอร์ก็คือบางครั้ง สมมติว่า นี่คือสิ่งที่เราไม่ได้พิจารณาเมื่อดูงบประมาณของโปรแกรมรวบรวมข้อมูล และในฐานะ SEO ของเรา มันไม่ได้เป็นเพียงเกี่ยวกับไฟล์ HTML หลักเท่านั้น แต่ถ้าคุณมี JavaScript ไฟล์ที่จะขยาย กำลังจะถูกประมวลผล และจะขอเพิ่มอีก 10 ไฟล์ ตามที่ผมเข้าใจ ทั้งหมดนี้รวมอยู่ในงบประมาณของโปรแกรมรวบรวมข้อมูลด้วย

อย่างที่ผมเห็นว่ามีค่าค่อนข้างมากในการลดจำนวนคำขอ เห็นได้ชัดว่านี่ซับซ้อนกว่าแค่การลดจำนวนคำขอและสร้างไฟล์ขนาดใหญ่เพียงไฟล์เดียว แต่ก็มีประโยชน์มากมายในการลดความซับซ้อนของทั้งโค้ด จำนวนคำขอ และน้ำหนัก โดยพื้นฐานแล้ว ค่าใช้จ่ายในการแสดงผล

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

มาร์ติน : สิ่งที่ดีคือบริการแสดงผลเว็บใช้โครงสร้างพื้นฐานการรวบรวมข้อมูลเพื่อดึงทรัพยากร ซึ่งหมายความว่าจะใช้โครงสร้างพื้นฐานที่สร้างขึ้นโดยเฉพาะเพื่อรวบรวมข้อมูลเว็บตามขนาด

ดังนั้นส่วนเครือข่ายก็ไม่ได้แย่ที่สุด ที่ยุ่งยากก็คือ เรียงตามลำดับ โอเค...

มีปัญหาอื่นหรือความท้าทายอื่นที่นี่ซึ่งเป็นความท้าทายของเวลาและลำดับความสำคัญ

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

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

นั่นคือการดำเนินการที่จะต้องมีการกระทืบตัวเลขใน CPU CPU ถูกสร้างมาเพื่อการคำนวณตัวเลข ดังนั้นมันจะเร็วมากในการทำเช่นนั้น แต่โปรแกรมของเราจะเป็นสิ่งที่เรียกว่า CPU-bound

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

IO-bound หมายถึงอะไร

IO-bound หมายถึง ถ้าฉันพูดว่า "เขียนโปรแกรมที่แสดงรายการไฟล์ทั้งหมดบนฮาร์ดไดรฟ์ของฉัน หรือในซีดีรอมนี้ หรือไดรฟ์ USB นี้"

โปรแกรมนี้ไม่จำเป็นต้องรันผ่าน CPU อีกต่อไปและโดยพื้นฐานแล้วจะเพียงแค่พลิกตัวเลขไปที่ CPU แต่ตอนนี้ ที่จริงแล้ว โปรแกรมของฉันถามถึงฮาร์ดแวร์ภายนอก โดยภายนอกฉันหมายถึงนอก CPU

ซีพียูต้องถามฮาร์ดไดรฟ์ ไดรฟ์ซีดีรอม ไดรฟ์ปากกา ไม่สำคัญหรอก ในการรับข้อมูลและต้องใส่ข้อมูลในที่ที่ CPU สามารถเข้าถึงได้ จากนั้น CPU จะอ่านข้อมูลและทำให้ ตัดสินใจจากข้อมูลที่พบ

โดยทั่วไป มันจะอ่านไดเร็กทอรีแรกและพบไฟล์แรกในไดเร็กทอรี อ่านมัน ไฟล์กลับมา ตอนนี้มันจำเป็นต้องอ่านไฟล์ที่สอง… และนั่นคือสิ่งที่ IO – input-output – bound เป็น

The choking factor, the thing that determines how fast something can be done here is no longer the CPU, it's the input-output, how long does this take.

The fastest is… if you talk to what is called a CPU cache, that memory that's usually inside what we would call the CPU, the central processing unit, the second fastest is if you read from local memory, from RAM. The next fastest would be a local SSD drive. And so on and so forth.

Network, unfortunately, is thousands and thousands of times slower than any of these local file accesses and these are a thousand times slower than memory access, and that's thousands of times slower than the access of the cache in the CPU.

And be careful, when I say cache, I mean a very specific tiny type of memory chip.

There is another cache, which we are using because we are IO-bound, as you can imagine, we have to fetch the resources. So it's not about the CPU or executing the JavaScript.

What takes a lot of time is going to the network and fetching the JavaScript from your server and getting that back, that is always going to be thousands of times slower than having it stored somewhere on a, let's say, hard drive, on an SSD drive somewhere in our data center.

So, we have a completely different cache, not the cache I mentioned earlier, that's a CPU internal bit and piece and we don't care about that.

We have a cache where basically whenever our crawler infrastructure fetches a resource, we store it on a drive inside our data center. So we are reducing these thousands of thousands of seconds down to a few seconds. And the problem is that if you split up your application across lots of files, let's say, a dozen files, a dozen of JavaScript files specifically, then we have to fetch all of these, now we only have to fetch these once probably and we can cache them.

But what if these files constantly change? Then we can't cache them. What's worse is, you may think “Oh, that's just one big file and all of it is in one file and that's better to cache!” No!

Because if you split it up the right amount, let's say instead of dozens of files, you now have 4 files, and from these 4 files only 2 change on a daily basis or on a weekly basis, then we can use the cache for at least the other files that never change. Good job.

But if you have all of this in one big file and it will constantly change and we can never make use of our cache. So we always have to go through the much slower network – that's a consideration that's very tricky to navigate.

And I can't give you hard and fast rules or numbers for it either.

It's a case-by-case basis, you wanna figure out how much of the stuff really has to change a lot, what other stuff is kind of stable and doesn't change as much, you wanna separate these two things.

Jason : Does that also mean that the network, the slowness of the network if you're pulling in files from different sites? That also?

Martin : Yes.

Jason : Which brings us to the question from Simox Cox, which is aimed at you, Martin: what can we do to help render Google's own scripts, analytics, and fonts?

Martin : You don't have to worry about analytics, because as far as I'm aware we are skipping analytics, with fonts, I think we are skipping them as well.

Jason: So we don't have to worry about them from the rendering perspective.

Martin: No, not from the rendering perspective, let's stick with that.

Bartosz : Just to add to that, one thing, at least to my knowledge, that you don't have to worry about with that is image fetches. That's why it's worth having image dimensions in the code because WRS – Web Rendering Service – also doesn't request images.

If you think about that, if you have a lean website of just HTML, CSS, like a lean JavaScript file, this does the trick. In our experience, this can improve rendering, indexing, crawling quite a bit just by cleaning up, a little bit of code-housekeeping, let's call it that.

Jason : You said about images though, it's very interesting because from a rendering, and getting the layout tree perspective, setting the size of the image or specifying is phenomenally important, and most lazy developers like myself don't bother doing it.

Bartosz : So, if you do that, according to my knowledge, Google doesn't have to request those files. So that's quite cool because you also cut the time of those requests, and you make Google's job a bit easier. Let's go to other questions.

Jason : Johann had a question: Is the rendering stage mandatory for a page to get indexed or could it be considered for indexing without the rendering stage?

Martin : It could hypothetically happen, but in practice it normally doesn't.

Jason: So all pages need rendering, with 1 or 2 exceptions, but none of us are likely to be concerned by that specific exception.

Bartosz: So I'm assuming this comes from those two waves of indexing. So Martin, what's the status on that right now? It's complicated as far as I can remember.

Martin : So I joined Google in April 2018, I remember that. Once I did my onboarding, Google onboarding, all of that lovely, cuddly nice time that you get when you get onboarded at Google, once that was over I sat down at my desk, and then I talked to John, Maria, Tom, and eventually, they were like, “We're prepping for Google I/O” and I saw the slide deck and I looked at two waves of indexing and I said to John, “Are you sure we wanna go with that?”, and he's like, “Yes, I think that makes it clearer, what happens”, and I'm like, “Yes, okay, I can see that it's a nice and easy explanation.”

And at least I, I know that John wasn't surprised, but I was surprised by the conclusions people drew from that.

And I was like oh God, okay, lesson learned here, that was an oversimplification. It was making what happens behind the scenes to simple and it implied a bunch of stuff that were not meant to be implied, for instance there's like “Yeah, things get indexed without the rendering happening, and then the rendering happens afterwards and changes the indexing.”

Jason: But that isn't the case?

Martin: It can be in certain cases, but it's very rare. It's also my fault because I looked at it and I said, okay, that's good.

Bartosz: To be fair, we saw, and everyone in the community dealing with JavaScript saw, quite often JavaScript would change metadata. Why you'd do that is beyond me.

Anyhow, sometimes you have one title, or one meta description with JavaScript disabled, without rendering, and you have a different one when Google renders.

And we saw websites when different pages were indexed differently. And that's why many people in the SEO community were like, okay, this page is waiting for the second wave of indexing.

Anyhow, Jason, let's go with another question.

Jason: No, right, the question you were asking there, people rewriting titles, for example, people do it with Google Tag Manager because they can't get their hands on their titles because they can't get the access to it.

That is a phenomenal problem for you guys. I mean, what you're saying is, from what I understand, sometimes you pick up the original one, sometimes you pick up the one inserted by Google Tag Manager.

Martin: Yeah, yeah.

Bartosz: And this goes beyond just meta title and description. You will see JavaScript rewriting the links, rewriting the whole structure, breadcrumbs, and with this happening, this must be really difficult to index that page and crawl that page quickly and efficiently.

Jason: So maybe we can change that to the question about, when a page changes overtime with the JavaScript even as it's loading which is the case with the meta title I just gave, how much of a problem is that for Google, so we're turning that into a more general question?

Martin: Sorry, can you run that past me again?

Jason: The fact that as the page, the page loads and things change before the users even interact with it, because you coded the things in to override because you're not very good at your job. How much of a problem does that cause?

Martin: Unless you have proof that it really is a problem for you, I wouldn't worry about it.

Normally it shouldn't be that much of a problem because normally, the clearly better content and information should definitely be there after rendering and might or might not be there previous to rendering.

What is tricky is when that's not the case, one, and the other thing is coming back to what I said earlier, the earlier you can get us data, the better, and I'll append to that.

Because when you think about it, if we were having a conversation, and I tell you oh, by the way, the restaurant to the left is terrible and the restaurant on the right is really, really good, but then 10 seconds later I'm like, no, actually, the restaurant on the left is amazing, the restaurant on the right I wouldn't bother with.

What do you do with that? That's kind of the same, if I have a title and a canonical at the beginning of the process and then that changes, then which one is the right one? How do we find out?

Bartosz: One thing to remember is, if you're leaving that decision to crawlers, and I'm not only talking about Google, because that also goes to Twitter, Facebook, Bing, all the other creatures of the web, if you leave that decision to Google, you create like a layer of chaos in your structure.

Because you don't know which pages are gonna be picked up which way, and even if just some of them won't be picked up properly, which again, sorry Martin, probably I'm not helping, but we're seeing a lot of cases where the signals from your end, so you have one version with HTML, one version with JavaScript – oversimplifying – then we're seeing different artifacts when this website is being crawled and rendered and indexed.

And I think this is proper development, this is something we need to, that's why we try to talk about these topics with Martin quite a bit, because this is something in the gray area between SEOs and devs.

Because, you know, it's a very difficult topic right now, is this something that technical SEOs should focus on? Not all companies have the luxury of technical SEOs in-house. Or is it something that the dev team should worry about? I guess the main topic is to look into that.

We have a tool – What Would JavaScript Do? – and if you google the tool, you can see, okay, which elements of the page are being changed with JavaScript. So this is very simple, just do that, look into those elements, just match those two and you're good. Even if you have to depend on JavaScript.

Martin: To be the devil's advocate for the developers, if all you have is client-side rendering and there are situations where you might for some reason have to do that, then it's not super easy to provide something server-side first, like in the initial HTML, and then updating something that is missing or that's very generic into something more specific and more high-quality, with JavaScript, is still a good thing over not doing it at all.

I'm not saying it's good, I'm not saying it's optimal and I absolutely 100% agree with Bartosz that you should make it match, but if you really can't, it is a way of doing things, it's just more shaky and error-prone than if you can avoid that.

Jason : One question many people are asking is, do authoritative sites get more “rendering” resources from Google or it doesn't matter?

Martin: No. You have to have this one meta tag, meta cheese=”” and then your favorite cheese, if it's the right kind of cheese and it changes weekly, then you get more rendering resources from John personally.

Bartosz: To support Martin's statement, being 100% serious right now, we're seeing websites, like home pages of newspapers, of huge eCommerce stores where you'd see main content not being picked up and we're seeing small websites indexed properly with similar technological stack, so I have to confirm, we're also not seeing like huge websites or heavily linked websites having some kind of benefit.

(…)

Bartosz : In general, something that we talked about with Martin. Rendering is so crucial with all the websites pushing so much JavaScript right now. And I guess, Martin, what would be…

Is there any way we can make rendering more interesting, more sexy in a way as SEO community?

I think this is something we talked about it so many times. We both know that rendering is so important and for the first time Google is not that black box anymore, we have so much data, Martin is available with all the answers, just… Not too many people seem to care about it.

We launched the Rendering SEO manifesto like June last year, I was thinking this would change the industry, I was thinking, this was gonna be this explosion within the industry, but this is not being picked up. And Martin, is there anything we as SEOs can do to push the envelope on this one?

Martin : That's again a tricky one because technically, I spoke to the rendering team about this, and they're like, “We like that rendering is not sexy”, and I'm like “Yeah, but there are people very worried about it and there is a bunch of stuff where you can miss out.”

I would just love people to experiment more. There are a few people in the community that are experimenting a lot, Giacomo Zecchini being one of them, I know that Dave Smart is experimenting a lot. And it's just really, really cool to see people experimenting and telling me what they're observing and checking in why what they're observing is what they're observing.

ฉันจะยกตัวอย่างง่ายๆ ให้คุณ Adam Gent เป็นคนแรกที่ชี้ให้เห็นต่อสาธารณะว่าพวกเขาเห็นคุณลักษณะที่สนับสนุนโดย Googlebot ในการเรนเดอร์ JavaScript ที่ไม่ได้รับการสนับสนุนมาก่อน เขาเป็นคนที่ทำให้เราเปิดเผยต่อสาธารณะในการเปิดตัว Googlebot ที่ไม่เคยหยุดนิ่ง และนั่นทำให้ฉัน มีความสุขมาก. เพราะมีคนถามมาเยอะมากๆ ว่าเมื่อไหร่ และฉันพูดไม่ได้จริงๆ เพราะเราไม่สามารถประกาศบางอย่างล่วงหน้าได้อย่างชัดเจน เพราะการประกาศอาจย้อนเวลากลับไปหรืออาจเกิดปัญหาขึ้นได้ แต่ถ้ามีคนพูดว่า “เฮ้ มาร์ติน เราเห็นสิ่งนี้อยู่ เกิดอะไรขึ้นที่นี่” ฉันสามารถพูดได้ว่า นี่คือสิ่งที่กำลังเกิดขึ้น เรากำลังเพิ่มเปอร์เซ็นต์ของการแสดงผลที่ใช้ Googlebot ที่ไม่เคยหยุดนิ่ง และหน้านี้ที่คุณเพิ่งมี เป็นหน้าที่เห็น Googlebot ใหม่ตลอดกาลจริงๆ

ฉันคิดว่าเป็น Giacomo Zecchini ที่จับฉันเกี่ยวกับพฤติกรรมแปลก ๆ กับคนทำงานเว็บ ซึ่งน่าสนใจจริงๆ เพราะฉันได้คุยกับทีมเรนเดอร์เรื่องนี้มาเป็นเวลานานแล้ว พวกเขาแบบว่า "ไม่มีใครใช้เลย ข้ามไป มัน!" และตอนนี้ก็เริ่มมีคนใช้กันแล้ว และแบบว่า เราต้องดูให้ดีก่อน

มีเรื่องเซอร์ไพรส์เล็กๆ น้อยๆ ที่น่าสนใจมากมายที่ปกติไม่สำคัญ ไม่มีผลกระทบใหญ่หลวงในแง่ของการจัดอันดับหรือการจัดทำดัชนีหรืออะไรก็ตาม แต่การสังเกตสิ่งเหล่านั้นก็น่าสนใจ

และฉันก็อยากจะรักพวกนอกรีตมากขึ้นเพื่อเข้าร่วมกับเราและเพียงแค่เล่นและสำรวจ

Jason: นั่นใช้ได้กับ SEO ทุกด้าน ยิ่งเราทดลอง สำรวจ และแบ่งปัน ชุมชนของเรายิ่งเรียนรู้มากขึ้น แต่ยิ่งคุณเรียนรู้มากขึ้นว่าเราเข้าใกล้สิ่งนี้อย่างไร และคุณสามารถช่วยเราช่วยเหลือตัวเองได้อย่างไร