Những hạn chế của việc gửi XML đến các trình duyệt và để chúng áp dụng XSLT là gì?

Bối cảnh

Làm việc như một nhà phát triển tự do, tôi thường tạo các trang web hoàn toàn dựa trên XSLT. Nói cách khác, trên mỗi yêu cầu, một tệp XML được tạo, chứa mọi thứ chúng ta cần biết về nội dung trang: tên của người dùng hiện đang đăng nhập, các mục menu trên cùng, nếu menu này là động / có thể định cấu hình, văn bản sẽ hiển thị trong một khu vực cụ thể của trang, v.v. Sau đó, quy trình XSL (bộ nhớ cache, v.v.) nó đến trang HTML / XHTML để gửi đến trình duyệt.

Nó có một điểm tốt để giúp dễ dàng tạo các trang web quy mô nhỏ, đặc biệt là với PHP. Nó là một loại công cụ mẫu, nhưng tôi thích các công cụ mẫu khác vì nó mạnh hơn hầu hết các công cụ mẫu và vì tôi biết nó tốt hơn và thích nó. Khi có thể, cũng có thể cung cấp quyền truy cập vào dữ liệu XML thô theo yêu cầu cho quyền truy cập tự động mà không cần phải tạo các API riêng biệt.

Tất nhiên, nó sẽ thất bại hoàn toàn trên bất kỳ trang web quy mô trung bình hoặc quy mô lớn nào, vì ngay cả với các kỹ thuật bộ nhớ đệm tốt, XSL vẫn làm giảm hiệu suất tổng thể của trang web và yêu cầu nhiều máy chủ CPU hơn.

Câu hỏi

Các trình duyệt hiện đại có khả năng lấy tệp XML và chuyển đổi tệp đó bằng tệp XSL được liên kết được khai báo bằng XML như thế nào <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 có thể làm điều đó. Internet Explorer 8 cũng có thể làm điều đó.

Điều đó có nghĩa là có thể di chuyển xử lý XSL từ máy chủ sang phía máy khách cho 50% người dùng (theo thống kê của trình duyệt trên một số trang web nơi tôi có thể muốn thực hiện việc này). Điều đó có nghĩa là 50% người dùng đó sẽ chỉ nhận được tệp XML theo từng yêu cầu, do đó làm giảm băng thông của họ và máy chủ (tệp XML ngắn hơn nhiều so với HTML tương tự được xử lý) và giảm mức sử dụng CPU của máy chủ.

Nhược điểm của kỹ thuật này là gì?

Tôi đã nghĩ về một vài cái, nhưng nó không áp dụng trong tình huống này:

• Việc triển khai khó khăn và cần phải lựa chọn, dựa trên yêu cầu của trình duyệt, khi nào nên gửi XML thô và khi nào cần chuyển đổi nó sang HTML. Rõ ràng, hệ thống sẽ không khó khăn hơn nhiều so với thực tế. Thay đổi duy nhất cần thực hiện là thêm liên kết tệp XSL vào mỗi XML và thêm kiểm tra trình duyệt.
• Sử dụng IO và băng thông nhiều hơn, vì tệp XSLT sẽ được trình duyệt tải xuống, thay vì được lưu trữ bởi máy chủ. Tôi không nghĩ đó sẽ là một vấn đề, vì tệp XSLT sẽ được các trình duyệt lưu vào bộ nhớ cache (như hình ảnh hoặc CSS hoặc tệp JavaScript thực sự được lưu trong bộ nhớ cache).
• Có thể một số vấn đề về phía máy khách, như có thể có vấn đề khi lưu một trang trong một số trình duyệt.
• Khó gỡ lỗi mã: không thể có được nguồn HTML mà trình duyệt thực sự đang sử dụng, vì nguồn duy nhất được hiển thị là XML đã tải xuống. Mặt khác, tôi hiếm khi nhìn vào mã HTML ở phía máy khách và trong hầu hết các trường hợp, nó không thể sử dụng trực tiếp (khoảng trắng bị xóa).

Các trình duyệt không thể kết xuất XSLT dần dần

Điều này có nghĩa là không có gì khác tải và không có gì được hiển thị cho đến khi tất cả dữ liệu và toàn bộ biểu định kiểu được tải và xử lý.

Bạn đang bỏ lỡ việc hiển thị lũy tiến và tìm nạp trước hình ảnh, CSS & JS.

Tải ban đầu bị trì hoãn bởi một yêu cầu khác

Đối với các tệp yêu cầu nhỏ (<20kb) , không phải băng thông, là nút cổ chai cho hiệu suất của giao diện người dùng và hầu hết các trang và biểu định kiểu sẽ thuộc danh mục này.

Nếu bạn có các trang lớn, thì nó thậm chí còn tệ hơn - xem điểm đầu tiên.

Bạn có thể không tiết kiệm bất kỳ băng thông

Bản thân XSLT khá dài dòng và có thể cần chứa các mẫu cho toàn bộ trang web và logic cho tất cả các trường hợp hiếm gặp, không chỉ những thứ được sử dụng trên trang hiện tại.

Bạn vẫn phải bao gồm tất cả dữ liệu được đánh dấu trong tệp XML chính mà bạn đang gửi, ví dụ: nếu bạn đang gửi một bài đăng trên blog, thì XSLT không thể làm gì để làm cho nó nhỏ hơn đáng kể. Nếu bạn đang gửi dữ liệu phức tạp, thì dù sao nó cũng sẽ có nhiều đánh dấu.

Bộ nhớ cache được đánh giá cao

Bộ nhớ cache của trình duyệt không phải là tuyệt vời :

40-60% người dùng của Yahoo có trải nghiệm bộ đệm trống và ~ 20% tổng số lượt xem trang được thực hiện với bộ đệm trống.

và trên thiết bị di động, nơi độ trễ làm cho các yêu cầu thêm đắt tiền hơn, bộ nhớ cache thậm chí còn tồi tệ hơn .

Kiểm tra tỷ lệ thoát của bạn - đó là những người dùng không được hưởng lợi từ XSLT được lưu trong bộ nhớ cache và thậm chí phải trả thêm giá để tải xuống biểu định kiểu và chờ xử lý.

gzip là một XSLT ngược

Hầu hết các phép biến đổi được thực hiện thông qua XSLT đều chuyển sang đánh dấu terse thành một đoạn dài hơn và thêm sự lặp lại. Nhưng gzip là tuyệt vời trong việc loại bỏ sự lặp lại / dư thừa từ các tập tin!

Dù sao thì bạn cũng nên sử dụng gzip (thật lãng phí khi gửi XML không nén). Rất có khả năng kích thước được nén của tài liệu đã xử lý sẽ tương đương với kích thước được nén của XML chưa được xử lý - nhưng bạn sẽ không phải gửi thêm XSLT và các trình duyệt sẽ có thể bắt đầu hiển thị ngay khi các gói đầu tiên đến.

Khách hàng có thể chậm

Ngay cả khi giả sử trường hợp tải từ bộ đệm tốt nhất, xử lý XSLT ở phía máy khách chỉ nhanh hơn nếu CPU của người dùng nhanh hơn và công cụ XSLT của họ nhanh hơn.

Về phía máy chủ, bạn có thể thực hiện tất cả các loại thủ thuật tối ưu hóa (ví dụ: các đoạn được xử lý bộ đệm hoặc thậm chí toàn bộ trang). Bạn có thể sử dụng bộ xử lý XSLT mới nhất, nhanh nhất (trình duyệt chỉ có XSLT 1.0 và có thể không được tối ưu hóa cho lắm). Và máy chủ của bạn có thể có CPU mạnh hơn nhiều máy tính văn phòng, điện thoại giá rẻ, v.v.

Không có lý do tại sao làm máy chủ này không nên mở rộng quy mô cũng như tạo HTML trực tiếp. Cũng không có nhiều lý do cho một chi phí lớn liên tục so với PHP. Rõ ràng có các trình biên dịch XSLT> JVM / CLR và tôi cho rằng bạn thậm chí có thể dịch nó sang mã gốc.

Tuy nhiên, ý tưởng vận chuyển dữ liệu và cấu trúc trình bày riêng biệt là tốt.
Nó có thể tiết kiệm rất nhiều băng thông và thậm chí hiệu suất máy chủ. Nhưng pomeL đã đề cập đến một số điểm.

Để được hỗ trợ phù hợp trên các trình duyệt, xslt.js có thể giúp đỡ.

Cá nhân tôi không phải là người hâm mộ XML, vì vậy tôi sẽ sử dụng JSON thay thế và một công cụ mẫu JS, sẽ thực thi trong trình duyệt. Hoặc một số loại công cụ mẫu, chuyển đổi đánh dấu mẫu thành js thực thi ở phía máy chủ, được sử dụng để hiển thị ở phía máy khách.
JavaScript là hợp lý nhanh chóng và có sẵn hầu như ở khắp mọi nơi. JSON và JS nhỏ gọn hơn nhiều so với XML và XSLT.

Gửi XML nhỏ gọn và có XSLT được lưu trong bộ nhớ cache trên máy khách thậm chí có thể tiết kiệm băng thông của bạn.

Bạn bỏ qua mọi trình duyệt không hỗ trợ XSLT, như điện thoại thông minh. Nhưng dù sao bạn cũng nên tạo một phiên bản speialized cho những cái này.

Vấn đề chính được sử dụng là chỉ có một vài trình duyệt hỗ trợ tốt điều này, do đó, nó không đáng để gặp rắc rối về cơ bản tạo ra một nền tảng mới để hỗ trợ. Ngoài ra, các phiên bản IE cũ hơn không hỗ trợ tốt điều này và nếu tôi nhớ lại chính xác thì ít nhất một IE có một phương ngữ XSLT khác nhau gây ra tất cả các vấn đề thú vị.