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

แน่นอนว่ามันจะใช้ทรัพยากรน้อยลงเนื่องจากเซิร์ฟเวอร์ไม่ต้องให้บริการเนื้อหาที่ปรากฏในทุกหน้าซึ่งเป็นประโยชน์ต่อทั้งโฮสต์และผู้ใช้ปลายทาง

ตอบคำถามโดยคำนึงถึง:

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

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

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

แก้ไข

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

สิ่งแรกก่อน

ข้อดี

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

ข้อเสีย

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

ตอนนี้สำหรับคำถามของคุณ

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

ในโลกแห่งการเชื่อมต่อเว็บที่รวดเร็วขึ้นมันไม่ได้เป็นเพียงการตัดไฟล์ขนาดเล็ก (เราจะเข้าใจ Javascript ทั้งหมดเอง CSS และรูปภาพสามารถและจะถูกแคชทิ้งไว้เพียงแค่ หน้า "ฐาน" ตัวเองเพื่อบันทึกไบต์บน) สำหรับข้อเสียที่สามารถให้กล่าวคือความยากลำบากพิเศษ (แม้ว่าจะไม่ท้าทายเสมอ con - ดี) และขาดการสนับสนุนที่สามารถให้ผู้ใช้บางคน

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

ตรวจสอบhttp://gawker.com/ - เว็บไซต์นี้โหลดเกือบสมบูรณ์หลังจากข้อเท็จจริง พวกเขาใช้ "hashbangs" ( http://mydomain.com/#!some_section) เพื่อตรวจสอบว่าหน้าเนื้อหาใดควรจะโหลดการนำทางหลักยังคงอยู่

ตรวจสอบhttp://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/สำหรับการสอนสั้น ๆ เกี่ยวกับแนวคิดของ Gawker ที่ใช้

มีข้อดีข้อเสียคุณต้องพิจารณาเครื่องมือค้นหา (ดูhttp://code.google.com/web/ajaxcrawling/docs/getting-started.html ) ผู้ที่ปิดการใช้งานจาวาสคริปต์และทำการทดสอบจำนวนมาก

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

เพราะมันอาจจะไม่จำเป็น
การโหลดเอกสาร HTML พื้นฐานนั้นง่ายและใช้งานได้ ขอแนะนำ Ajax เพิ่มกระบวนการเลเยอร์อื่นทั้งหมดสำหรับเบราว์เซอร์รหัสและการบำรุงรักษาสำหรับ Javascript เนื้อหาแบ็คเอนด์ URL hashbang แปลก ๆ และอื่น ๆ บางครั้งสิ่งนี้สามารถเป็นธรรมได้บางครั้งก็ไม่เป็นเช่นนั้น อาจช่วยให้คุณประหยัดทรัพยากรเซิร์ฟเวอร์ (อาจ) แต่นั่นจะเพียงพอที่จะชดเชยค่าบำรุงรักษาหรือไม่ คุณต้องประเมินว่าต่อโครงการ

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

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

ปัญหาที่พบบ่อยคือการนำทาง (เช่นไปข้างหน้าและข้างหลัง) และการทำบุ๊กมาร์ก แต่มีข้อบกพร่องอื่น ๆ มากมายที่นักพัฒนาจำนวนมากไม่ต้องการจัดการ และโดยทั่วไปหมายถึงการสร้างเว็บไซต์สองรุ่นเพื่อให้สามารถใช้งานร่วมกับ Javascript และผู้ใช้ที่ไม่ใช่ javascript (และการแก้ไขสำหรับเบราว์เซอร์ทั้งหมดที่มีการสนับสนุน AJAX ที่ไม่ดี)

ใช่มันควรจะเป็น แต่มันควรจะเป็นวิธีอื่น ๆ

ส่วนทั่วไปของหน้าควรส่งผ่าน HTTP จากนั้นตัวควบคุม ajax ขนาดเล็ก (หรือเว็บซ็อกเก็ตที่ดียิ่งขึ้น) จะโหลดเนื้อหาไดนามิกแบบอะซิงโครนัส

แน่นอนคุณต้องตรวจสอบก่อนว่าจาวาสคริปต์เปิดใช้งาน (โดยคุกกี้) และใช้วิธีนี้เฉพาะเมื่อเปิดใช้งาน

ดังนั้นคุณต้องใช้เส้นทาง HTTP แบบเต็มตามปกติจากนั้นจึงเป็นเส้นทางเว็บซ็อก สิ่งนี้ต้องการการทำสำเนารหัสยกเว้นว่าคุณใช้เครื่องมือเช่น node.js

คนส่วนใหญ่ "คิด" ว่ามันไม่คุ้มค่ากับความพยายามพิเศษ และบางครั้งมันก็ไม่

ในฐานะที่เป็นคนจำนวนมากแยกหน้า ajaxify ผิด พวกเขาตัดสินใจว่าคุณไม่ต้องการรุ่นที่ไม่ใช่จาวาสคริปต์และคุณต้องการ URL แฮชปังแปลก ๆ เหล่านี้และปุ่มไปข้างหน้า / หลังหัก การทำอาแจ็กซ์อย่างถูกต้องต้องมีประวัติ HTML5 (IE9 ไม่มี) นอกจากนี้ยังต้องการนักพัฒนาเพื่อให้เว็บไซต์ของคุณสมบูรณ์

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

ไม่ดีสำหรับการเข้าถึง

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

อาจมีเทคนิคในการแก้ไขปัญหานี้ แต่ฉันก็ไม่ได้มองอย่างถี่ถ้วน

ความซับซ้อนที่เพิ่มขึ้น

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

พฤติกรรม AJAX แบบนี้จะทำให้การวิเคราะห์ทราฟฟิกของคุณซับซ้อน Google Analytics จะไม่ลงทะเบียนโหลด AJAX เหล่านี้อย่างเหมาะสมโดยไม่ต้องโทรหาpageTracker._trackPageview('this_page');ด้วยตนเอง

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

เป็นไปได้: โหลดหน้าเว็บที่ช้าลงในการเข้าชมครั้งแรก

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

แต่ละลิงค์ที่คลิกมาจะเร็วขึ้น แต่การดึงหน้าแรกที่ผู้ใช้เข้าชมจะใช้เวลานานกว่าเวอร์ชันคงที่

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

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

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

ตัวอย่างเช่นสมมติว่าคุณมี 200 คนที่พยายามเข้าถึงหน้าเว็บต่อวินาที คุณมีการสืบค้นฐานข้อมูลประมาณ 7 รายการสำหรับการโทร ajax ของคุณ นั่นคือฐานข้อมูล 1400 เรียกวินาทีซึ่งสามารถชะงักเว็บไซต์

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

มันเป็นวิธีการSOAเพื่อสร้างเว็บไซต์