Enterprise SEO: เหตุใด 'แนวทางปฏิบัติที่ดีที่สุด' จึงไม่สามารถตัดออกได้ และควรทำอย่างไรแทน

ผู้เชี่ยวชาญด้าน SEO หลายคนพึ่งพา "แนวทางปฏิบัติที่ดีที่สุด" ในความพยายามด้าน SEO

แต่เมื่อเพิ่มประสิทธิภาพเว็บไซต์องค์กรที่ใช้ JavaScript เพื่อความเร็วไซต์ คุณต้องมีมากกว่า “แนวทางปฏิบัติที่ดีที่สุด”

นี่คือสาเหตุที่โซลูชันมาตรฐานไม่นำไปใช้กับไซต์ขององค์กรเสมอไป และสิ่งที่คุณสามารถทำได้แทน

การปรับปรุงความเร็วไซต์: การย้ายไปยังการแสดงผลฝั่งเซิร์ฟเวอร์ไม่ใช่คำตอบที่ถูกต้องเสมอไป

ลองนึกภาพการไปหา CEO (หรือใครก็ตามที่เป็นผู้นำระดับสูง) และแนะนำพวกเขาว่า “เราจำเป็นต้องเปลี่ยนเว็บไซต์ของเราเป็นการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)”

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

ผลกระทบทางธุรกิจและค่าใช้จ่ายที่เกี่ยวข้องกับการย้ายข้อมูล SSR นั้นไม่คุ้มกับความพยายามสูงและผลกระทบต่ำ

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

คิดเกี่ยวกับค่าใช้จ่ายที่อ่อนนุ่มและแข็งที่จะเกิดขึ้น:

• การตรวจสอบระบบและ API ทั้งหมดเพื่อยืนยันความเข้ากันได้ ซึ่งอาจไม่ได้มีการจัดทำเป็นเอกสารทั้งหมด (อาจเป็นหลักร้อยหรือหลักพัน)
• ใช้เวลาหลายพันชั่วโมงในการรีแฟคเตอร์ QA และตรวจสอบการช่วยสำหรับการเข้าถึงเว็บไซต์ทั้งหมด
• ฝึกอบรมพนักงานที่มีอยู่ในกรอบงานใหม่ (หลายสิบคนหรือหลายร้อยคนทั่วทั้งองค์กร)
• การจ้างหรือเลิกจ้างนักพัฒนาและวิศวกรที่ไม่เต็มใจหรือไม่เป็นไปตามข้อกำหนดของเฟรมเวิร์กใหม่
• เงินที่ใช้ไปกับค่าธรรมเนียมเซิร์ฟเวอร์มากขึ้น

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

ในบทบาทองค์กรก่อนหน้านี้ ฉันได้พูดคุยเกี่ยวกับสถานการณ์นี้กับวิศวกรระบบอาวุโสคนหนึ่งของเราเพื่อความสนุกสนาน

เราประเมินว่าบริษัทจะใช้เวลาหนึ่งปีครึ่งในการเป็นเผ่าที่มีความว่องไวโดยเฉพาะ (ปกติประมาณ 70 คน) และอย่างน้อย 2 ล้านเหรียญสหรัฐ (AUD) ในการทำ และนั่นอาจเป็นการประมาณการแบบอนุรักษ์นิยม

แล้วเราจะทำอย่างไรเพื่อให้ความก้าวหน้า?

ทำความรู้จักกับทีมอื่นๆ ของคุณและช่วยเหลือพวกเขา

ในระดับองค์กร SEO จำเป็นต้องเป็นกิ้งก่าเพราะคุณต้องพึ่งพาทีมอื่นในการจัดลำดับความสำคัญและทำงานให้คุณ

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

SEO คือ “สิ่งนี้จะปรับปรุงความเร็วไซต์ของเรา/ช่วยให้เราตอบสนองความต้องการการเข้าถึง/อื่นๆ” SEO คือทุกสิ่ง แต่ SEO

Tom Critchlow ได้กล่าวไว้ในหลักสูตร SEO MBA ของเขาและในพอดแคสต์ Engage: On Enterprise SEO ของเขา

เป็นการสรุปชีวิตการเป็น SEO ขององค์กรได้เป็นอย่างดี

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

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

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

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

ทำงานร่วมกับนักพัฒนาและผู้ผลิต

ในหลายๆ องค์กรในปัจจุบัน ความเร็วของไซต์เป็นปัจจัยที่ทราบกันดีว่าช่วย (หรือขัดขวาง) อัตราการแปลง

ทีมพัฒนาหลายๆ ทีมในบริษัทอาจมีความเร็วของไซต์เป็น KPI แตะเข้าไปที่

คุณทั้งคู่ต่างก็ชอบสิ่งเดียวกัน และนักพัฒนาของคุณจะรู้จัก codebase ดีกว่าคุณ และถ้าทำได้ดี คุณทั้งคู่อาจได้รับโบนัส

โอกาสความเร็วไซต์ทั่วไปบางส่วนที่ฉันพบว่านักพัฒนาสามารถช่วยคุณได้ ได้แก่:

ขนาด/น้ำหนักของรหัส

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

สะท้อนกลับมาที่พวกเขาและยอมรับการทำงานหนักของพวกเขา

การโหลดรูปภาพและการเปลี่ยนเลย์เอาต์แบบสะสม (CLS)

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

การจัดการการเปลี่ยนเส้นทาง

นี่ไม่ใช่สิ่งที่ฉันสามารถอธิบายได้เนื่องจากการจัดการการเปลี่ยนเส้นทางของเราถูกแยกส่วนอย่างมาก

หากระบบของคุณเป็นแบบรวมศูนย์มากขึ้นเล็กน้อย การจัดการการเปลี่ยนเส้นทาง การลบฮ็อพ การรวมกฎเข้ากับ regex และการปรับปรุงหนี้ทางเทคนิคนั้นอาจช่วยได้ไม่น้อย

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

<ปุ่ม> แทนที่ <a href>

อันนี้เหมาะสมกว่าเล็กน้อย แต่ฉันมักจะพบว่านักพัฒนา JS ผิดนัดรวมลิงก์ ahref เป็นปุ่ม

ซึ่งมักเป็นเพราะพวกเขาไม่มีเวลา และเป็นค่าเริ่มต้นดั้งเดิมของเฟรมเวิร์กที่พวกเขากำลังทำงานอยู่

เมื่อฉันสร้างเทมเพลตหน้าใหม่ให้กับ QA ฉันมักจะตั้งค่าสถานะนี้เพื่อให้อัปเดตเป็น <a href>

รับจดหมายข่าวรายวันที่นักการตลาดไว้วางใจ

กำลังดำเนินการ...โปรดรอสักครู่

ติดตาม

ดูข้อกำหนด

ทำงานร่วมกับนักออกแบบ

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

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

เมื่อฉันเริ่มต้นด้านองค์กร ฉันจำได้ว่าเห็นภาพที่มีขนาด 10MB ในหน้าผลิตภัณฑ์สำหรับผลิตภัณฑ์เรือธงบางรายการของเรา มันพัดใจของฉัน

รูปภาพไม่จำเป็นต้องมีขนาด 10MB บนเว็บ หยุดเต็ม

ดังนั้นฉันจึงได้พูดคุยกับนักออกแบบของเราอย่างละเอียดและทำงานร่วมกับพวกเขาเพื่อลดขนาดรูปภาพของเราในช่วงเวลาประมาณ 8 เดือน

100KB ไม่ใช่เนินเขาที่ฉันยอมตาย ดังนั้นถ้าฉันบอกนักออกแบบ 100KB สำหรับแบนเนอร์หัวเรื่องหรือ a-frame และพวกเขาเพิ่มเป็น 300KB ก็ยังถือว่าเป็นการปรับปรุง

SEO สำหรับองค์กรมักจะเกี่ยวกับการชนะที่เพิ่มขึ้น

ทำงานร่วมกับนักวิเคราะห์

นักวิเคราะห์เข้าร่วมการสนทนาเพราะพวกเขาอาจจะจัดการระบบการแท็กของคุณและแท็กของบุคคลที่สามทั้งหมดบนเว็บไซต์ของคุณ

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

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

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

• เฉพาะการเริ่มการทำงานของ HotJar, Fullstory หรือสคริปต์การตรวจสอบประสบการณ์ผู้ใช้รายอื่นบนหน้าเว็บที่กำลังถูกแผนที่ความร้อนหรือติดตามอยู่
• ตรวจสอบการใช้งานของคุณเพื่อหารายการที่ซ้ำกัน (เกิดขึ้นมากกว่าที่คุณคิด)
• ดูว่าแชทบ็อตหรือแท็กการบริการลูกค้าใดที่สามารถเปิดใช้งานบนคลิกแทนที่จะเป็นเมื่อโหลดหน้าเว็บ

ทำงานร่วมกับทีม QA

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

• ข้อมูลเมตาต้องเหมือนกันระหว่างแหล่งที่มาของหน้าและหน้าที่แสดงผลฝั่งไคลเอ็นต์
• Canonical ต้องแสดงอยู่ในหน้าที่แสดงผลฝั่งไคลเอ็นต์
• ลิงก์ควรอยู่ในรูปแบบ <a href="”> แทนที่จะเป็น <button>
• โหลดแบบอักษรล่วงหน้า
• เชื่อมต่อกับทรัพยากรขนาดใหญ่ล่วงหน้า

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

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

การสนับสนุนทีมอื่นๆ ที่คุณทำงานด้วย

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

มีสองวิธีที่แข็งแกร่งมากในการทำเช่นนั้นในระดับองค์กร

เคารพเวลาของพวกเขา

สมมติว่าคุณมีความคิดที่ยิ่งใหญ่ เช่น "เราควรเปลี่ยนไปใช้การแสดงผลฝั่งเซิร์ฟเวอร์"

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

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

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

ขยายความพยายามของพวกเขา

สิ่งที่นัก SEO ทำได้ไม่ดีคือการสื่อสารและแบ่งปันความสำเร็จ

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

คุณ SEO ไม่ใช่ศูนย์กลางของความสนใจอีกต่อไป ทีมงานที่ทำจริงคือ.

การทำงานร่วมกัน การสนับสนุน และชัยชนะที่เพิ่มขึ้น

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

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

พวกเขาสามารถช่วยให้คุณไปถึงจุดนั้นได้ดีกว่าบทความในสิ่งพิมพ์ SEO

การทำสิ่งต่าง ๆ ให้สำเร็จในระดับองค์กรนั้นไม่ใช่เรื่องของ “อะไร” แต่เป็นเรื่องของ “วิธีการ” มากกว่า

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