ข้อเสียของการส่ง XML ไปยังเบราว์เซอร์คืออะไรและปล่อยให้พวกเขาใช้ XSLT?

บริบท

ทำงานเป็นนักพัฒนาอิสระฉันมักจะทำเว็บไซต์อย่างสมบูรณ์ตาม XSLT กล่าวอีกนัยหนึ่งในทุกคำร้องขอไฟล์ XML จะถูกสร้างขึ้นซึ่งมีทุกสิ่งที่เราจำเป็นต้องรู้เกี่ยวกับเนื้อหาของหน้า: ชื่อของผู้ใช้ที่เข้าสู่ระบบในปัจจุบันรายการเมนูด้านบนหากเมนูนี้เป็นแบบไดนามิก / กำหนดค่าข้อความ แสดงในพื้นที่เฉพาะของหน้า ฯลฯ จากนั้นกระบวนการ XSL (แคช ฯลฯ ) ไปยังหน้า HTML / XHTML เพื่อส่งไปยังเบราว์เซอร์

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

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

คำถาม

เบราว์เซอร์ที่ทันสมัยมีความสามารถในการใช้ไฟล์ XML และแปลงมันด้วยไฟล์ XSL ที่เกี่ยวข้องประกาศในรูปแบบ XML <?xml-stylesheet href="demo.xslt" type="text/xsl"?>เช่น Firefox 3 สามารถทำได้ Internet Explorer 8 ก็ทำได้เช่นกัน

หมายความว่าเป็นไปได้ที่จะโยกย้ายการประมวลผล XSL จากเซิร์ฟเวอร์ไปยังฝั่งไคลเอ็นต์สำหรับผู้ใช้ 50% (ตามสถิติของเบราว์เซอร์บนเว็บไซต์หลายแห่งที่ฉันอาจต้องการใช้งาน) หมายความว่า 50% ของผู้ใช้จะได้รับเฉพาะไฟล์ XML ในแต่ละคำขอซึ่งจะช่วยลดแบนด์วิดท์และเซิร์ฟเวอร์ของพวกเขา (ไฟล์ XML จะสั้นกว่าอะนาล็อก HTML ที่ประมวลผลมาก) และลดการใช้ CPU ของเซิร์ฟเวอร์

ข้อเสียของเทคนิคนี้คืออะไร?

ฉันคิดเกี่ยวกับหลาย ๆ คน แต่มันไม่ได้ใช้ในสถานการณ์นี้:

• การใช้งานที่ยากและจำเป็นต้องเลือกขึ้นอยู่กับคำขอของเบราว์เซอร์เมื่อใดที่จะส่ง XML ดิบและเมื่อใดที่จะเปลี่ยนเป็น HTML แทน เห็นได้ชัดว่าระบบจะไม่ยากขึ้นมากแล้วระบบจริง การเปลี่ยนแปลงเพียงอย่างเดียวคือการเพิ่มลิงก์ไฟล์ XSL ให้กับทุก XML และเพื่อเพิ่มการตรวจสอบเบราว์เซอร์
• การใช้งาน IO และแบนด์วิดธ์เพิ่มขึ้นเนื่องจากไฟล์ XSLT จะถูกดาวน์โหลดโดยเบราว์เซอร์แทนที่จะถูกแคชโดยเซิร์ฟเวอร์ ฉันไม่คิดว่ามันจะเป็นปัญหาเนื่องจากไฟล์ XSLT จะถูกแคชโดยเบราว์เซอร์ (เช่นรูปภาพหรือ CSS หรือไฟล์ JavaScript ถูกแคชจริง)
• อาจมีปัญหาเกี่ยวกับฝั่งไคลเอ็นต์เช่นอาจเป็นปัญหาเมื่อบันทึกหน้าเว็บในเบราว์เซอร์บางตัว
• ความยากในการดีบักรหัส: เป็นไปไม่ได้ที่จะได้รับแหล่ง HTML ที่เบราว์เซอร์ใช้งานจริงเนื่องจากแหล่งที่แสดงเพียงอย่างเดียวคือ XML ที่ดาวน์โหลดมา ในทางกลับกันฉันไม่ค่อยไปดูโค้ด HTML ทางฝั่งไคลเอ็นต์และในกรณีส่วนใหญ่มันไม่สามารถใช้งานได้โดยตรง (ลบช่องว่าง)

เบราว์เซอร์ไม่สามารถสร้างการแสดงผล XSLT ได้อย่างต่อเนื่อง

ซึ่งหมายความว่าไม่มีอะไรโหลดและไม่มีอะไรแสดงจนกว่าข้อมูลทั้งหมดและสไตล์ชีททั้งหมดจะถูกโหลดและประมวลผล

คุณกำลังพลาดการแสดงผลแบบโปรเกรสซีฟและการดึงภาพล่วงหน้า CSS & JS

โหลดเริ่มต้นล่าช้าโดยคำขออื่น

สำหรับจำนวนคำขอขนาดเล็ก (<20kb) ไม่ใช่แบนด์วิดท์เป็นคอขวดสำหรับประสิทธิภาพของส่วนหน้าและหน้าและสไตล์ส่วนใหญ่จะอยู่ในหมวดหมู่นี้

หากคุณมีหน้าเว็บขนาดใหญ่แสดงว่ายิ่งแย่กว่านั้น - ดูจุดแรก

คุณอาจไม่ได้บันทึกแบนด์วิดท์ใด ๆ

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

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

แคชถูก overrated

แคชของเบราว์เซอร์นั้นยอดเยี่ยม :

ผู้ใช้ของ Yahoo! 40-60% มีประสบการณ์แคชว่างเปล่าและประมาณ 20% ของการดูหน้าเว็บทั้งหมดจะทำด้วยแคชเปล่า

และบนมือถือที่เวลาแฝงทำให้คำขอพิเศษแพงที่สุดแคชยิ่งแย่ไปกว่านั้น

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

gzip เป็น XSLT ย้อนกลับ

การแปลงส่วนใหญ่ที่ทำผ่าน XSLT จะเป็นการเปลี่ยนมาร์กอัป terse ให้มีความละเอียดมากขึ้นและเพิ่มการซ้ำซ้อน แต่ gzip นั้นยอดเยี่ยมในการลบการซ้ำซ้อน / ความซ้ำซ้อนออกจากไฟล์!

คุณควรใช้ gzip อยู่ดี (ไม่ต้องบีบอัด XML เพื่อส่ง) มีความเป็นไปได้สูงมากที่ขนาดเอกสารที่ประมวลผลแล้วจะมีขนาดเท่ากับ gzipped ของ XML ที่ยังไม่ได้ประมวลผล แต่คุณไม่ต้องส่ง XSLT เพิ่มเติมและเบราว์เซอร์จะสามารถเริ่มแสดงผลทันทีที่แพ็กเก็ตแรกมาถึง

ไคลเอนต์อาจช้า

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

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

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

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

เพื่อรองรับเบราว์เซอร์ที่เหมาะสมxslt.jsสามารถช่วยได้

โดยส่วนตัวแล้วฉันไม่ใช่แฟนของ XML ดังนั้นฉันจะใช้ JSON แทนและเครื่องมือเทมเพลต JS ที่จะทำงานในเบราว์เซอร์ หรือเครื่องมือเทมเพลตบางประเภทที่แปลงมาร์กอัปแม่แบบเป็น js ที่ทำงานได้บนฝั่งเซิร์ฟเวอร์ซึ่งใช้สำหรับการแสดงผลในฝั่งไคลเอ็นต์
จาวาสคริปต์นั้นเร็วพอสมควรและสามารถใช้ได้แทบทุกที่ JSON และ JS มีขนาดกะทัดรัดกว่า XML และ XSLT มากขึ้น

การส่ง XML ขนาดกะทัดรัดและการมี XSLT ที่แคชไว้บนไคลเอนต์อาจช่วยประหยัดแบนด์วิดท์ของคุณ

คุณปล่อยให้เบราว์เซอร์ใด ๆ ที่ไม่รองรับ XSLT เช่นสมาร์ทโฟน แต่คุณควรสร้างรุ่นที่พูดสำหรับสิ่งเหล่านี้อยู่ดี

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