Có lý do chắc chắn nào về lý do tại sao các trang web không nên được phát triển với chức năng ajax tải các phần chính của mỗi phần (giả sử có các yếu tố như tiêu đề, điều hướng, v.v. vẫn giữ nguyên)?

Chắc chắn nó sẽ ít tốn tài nguyên hơn vì máy chủ sẽ không phải phục vụ nội dung xuất hiện trên mỗi trang, mang lại lợi ích cho cả máy chủ và người dùng cuối.

Trả lời câu hỏi đang cân nhắc:

• Các trang web hành vi javascript xuống cấp duyên dáng trong mọi trường hợp

• Đối với câu hỏi của tôi, tôi đang nói về các trang web mới, nơi hành vi này có thể được thực hiện thay vì tắt, vì vậy về mặt kỹ thuật, nó không tốn bất kỳ khoản tiền nào - chúng tôi sẽ không quay lại một sản phẩm hoàn chỉnh để thực hiện nó.

Nếu nội dung có thể đạt được mà không cần bật JavaScript thì câu hỏi của bạn không có ý nghĩa gì. Nó không "hoàn toàn được Ajax hóa" nếu bạn có thể truy cập nội dung thông qua các phương tiện khác. Thực sự, điều bạn đang hỏi là "có ổn không khi nâng cao trải nghiệm người dùng của tôi thông qua Ajax?". Câu trả lời rõ ràng là "có".

biên tập

Quay lại khi Google đưa ra đề xuất Ajax có thể thu thập dữ liệu của mình, nó đã bị chỉ trích là một ý tưởng thực sự tồi tệ . Làm cho một đọc thú vị.

Điều đầu tiên

Ưu

• AJAX có thể cho phép bạn sử dụng một trang "cơ sở" chung và chỉ tải các vùng nội dung, có thể cắt giảm thời gian tải cho người dùng, vì một phần lớn của trang đã được tải.
• Có thể cho phép một số kẹo mắt như làm mờ dần khu vực nội dung trong và ngoài.

Nhược điểm

• Không chơi tốt nếu trang được tải xuống.
• Có thể gây rối với các thiết bị khuyết tật.
• Người xem bị tắt javascript sẽ hoàn toàn không thể sử dụng nội dung trừ khi phiên bản không phải là javascript được sử dụng.
• Nhiều công việc hơn (có thực sự cần phải nói không?).

Bây giờ cho câu hỏi của bạn

Giả sử trang web của bạn xuống cấp một cách duyên dáng cho những người không có Javascript, thì điều đó tốt đến mức nào tùy thuộc vào cách nó được thực hiện. Ví dụ: nếu bạn chỉ hiển thị một liên kết đến một phiên bản không có javascript, điều đó gây bất tiện cho những người xem đó khi phải nhấp vào một liên kết khác. Mặt khác, nếu có một "trang chính" được sử dụng các liên kết truyền thống, sẽ hoạt động tốt hơn cho hầu hết người dùng, nhưng vẫn thiếu hỗ trợ cho những người sử dụng thiết bị khuyết tật, trong trường hợp người dùng đến một "trang" cụ thể từ liên kết, vv

Nói chung, trong thế giới kết nối web ngày càng nhanh, nó không thực sự biện minh cho việc cắt giảm một lượng nhỏ kích thước tệp (chúng tôi sẽ giả sử tất cả Javascript, CSS và hình ảnh có thể được lưu vào bộ nhớ cache, chỉ để lại chính trang "cơ sở" để lưu byte trên) cho những nhược điểm mà nó có thể mang lại, cụ thể là khó khăn thêm (mặc dù điều đó không phải lúc nào cũng là một thách thức là tốt) và thiếu sự hỗ trợ mà nó có thể cung cấp cho một số người dùng.

Nói chung, tôi nói điều đó tùy thuộc vào bạn, nó có thể hoạt động khá tốt và đối với đại đa số người dùng, họ có thể sẽ xem trang web như dự định, nhưng cá nhân tôi, tôi không nói làm phiền, vì nó không đáng để cải thiện biên như vậy để tập tin hóa.

Kiểm tra http://gawker.com/ - trang web này gần như tải hoàn toàn sau khi thực tế. Họ sử dụng "hashbangs" ( http://mydomain.com/#!some_section) để xác định trang nội dung nào sẽ được tải, điều hướng chính vẫn ở trạng thái tĩnh.

Hãy xem http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ để biết hướng dẫn ngắn về khái niệm Gawker đã sử dụng.

Có những ưu và nhược điểm, bạn phải xem xét các công cụ tìm kiếm (xem http://code.google.com.vn/web/ajaxcrawling/docs/getting-started.html ), những người bị javascript bị vô hiệu hóa và thực hiện nhiều thử nghiệm.

Với tất cả những gì đã nói, lập luận lớn nhất đối với họ có lẽ là khi người dùng chờ tải trang, sau đó phải chờ tải thêm, họ có thể thiếu kiên nhẫn. Theo quan điểm của tôi, cách tốt nhất là tải trang web chính, điều hướng và nội dung chính trong một lượt (theo yêu cầu) và lưu AJAX cho các sự cố không cần thiết. Điều đó làm việc với ý tưởng tăng cường tiến bộ , và pha trộn tốt nhất của cả hai phương pháp.

Bởi vì nó có lẽ không cần thiết.
Tải các tài liệu HTML cơ bản là đơn giản và hoạt động. Giới thiệu Ajax bổ sung toàn bộ một lớp quy trình khác cho trình duyệt, mã và bảo trì cho Javascript, nội dung phụ trợ, URL hashbang kỳ lạ, v.v. Đôi khi điều này có thể được biện minh, đôi khi không. Nó có thể giúp bạn tiết kiệm một số tài nguyên máy chủ (có thể), nhưng liệu nó có đủ bù đắp cho bảo trì không? Bạn phải đánh giá mỗi dự án.

Ví dụ, khi Twitter có thiết kế lại mới nhất, họ đã sử dụng cách tiếp cận rằng đó không chỉ là một trang web (trang), mà là một ứng dụng và toàn bộ mọi thứ đều dựa trên Ajax, mặc dù hầu hết những gì nó có thể được xử lý với các yêu cầu trang thông thường. Một trong những vấn đề lớn nhất, hiện vẫn xảy ra mặc dù ít hơn nhiều, là đến đó và được chào đón với một trang trống vì có gì đó trong Ajax thất bại.

Trong thực tế, có rất nhiều công việc tạo ra một trang web 'hoàn toàn AJAX', đặc biệt là đối với các trang web lớn rất phức tạp. Một số trang web cố gắng này là Google và Facebook, nhưng thậm chí họ không làm điều đó một cách hoàn hảo.

Các vấn đề phổ biến là điều hướng (tức là tiến và lùi) và đánh dấu trang, nhưng có nhiều lỗi khác mà nhiều nhà phát triển không muốn phải giải quyết. Và về cơ bản, điều đó có nghĩa là tạo hai phiên bản của trang web để tương thích với người dùng Javascript và không phải javascript (và sửa lỗi cho tất cả các trình duyệt có hỗ trợ AJAX xấu).

Vâng, nó phải như vậy, tuy nhiên nó phải là cách khác.

Các phần chung của trang sẽ được gửi qua HTTP. Sau đó, một điều khiển ajax nhỏ (hoặc thậm chí tốt hơn websockets) tải nội dung động không đồng bộ.

Tất nhiên trước tiên bạn cần phát hiện xem javascript có được bật hay không (bằng cookie) và chỉ sử dụng phương thức này nếu nó được bật.

Vì vậy, bạn cần tuyến HTTP đầy đủ bình thường và sau đó là tuyến websockets. Điều này yêu cầu sao chép mã trừ khi bạn sử dụng một công cụ như node.js

Hầu hết mọi người "nghĩ" rằng nó chỉ không xứng đáng với nỗ lực thêm. Và đôi khi không.

Như một bên rất nhiều người ajaxify trang sai. Họ thực sự quyết định rằng bạn không cần một phiên bản không có javascript và bạn cần tất cả các url băm kỳ lạ này và các nút chuyển tiếp / quay lại bị hỏng. Làm ajax đúng cách yêu cầu lịch sử HTML5 (IE9 không có nó). Nó cũng yêu cầu nhà phát triển hoàn thành các phiên bản của trang web của bạn.

Vì bạn đã tuyên bố rằng nó sẽ xuống cấp một cách duyên dáng cho khách truy cập bị tắt Javascript, tôi chỉ có thể thấy hai vấn đề thực sự (và một vấn đề có thể xảy ra) có thể xảy ra.

Xấu cho khả năng truy cập

Trình đọc màn hình và các công nghệ hỗ trợ khác thường bị loại bỏ bởi các thay đổi DOM động. Họ xử lý và đọc trang theo kiểu tuyến tính và thay đổi nội dung của trang sau khi được tải có thể không được xử lý chính xác.

Có thể có các kỹ thuật để khắc phục điều này, nhưng tôi đã không xem xét nó quá kỹ lưỡng.

Độ phức tạp tăng

Duy trì loại trang web này có thể là khó khăn. Ví dụ: Nếu bạn đã tạo bố cục mới và thay đổi ID của khu vực nội dung bạn đang thay thế bằng các liên kết AJAX của mình, nó có thể phá vỡ sơ đồ điều hướng của bạn theo cách khá khó hiểu.

Loại hành vi AJAX này cũng sẽ làm phức tạp bất kỳ phân tích lưu lượng truy cập nào bạn có thể thực hiện; Google Analytics sẽ không đăng ký chính xác các tải AJAX này mà không có cuộc gọi thủ công pageTracker._trackPageview('this_page');.

Thêm sự phức tạp hơn vào cách trang của bạn hoạt động cũng làm tăng thanh cho các nhà phát triển mới; bất cứ ai làm việc trên trang web có thể sẽ phải được biết về cách hành vi này ảnh hưởng đến tải trang.

Có thể: Tải trang chậm hơn khi truy cập ban đầu

Tùy thuộc vào cách bạn cấu trúc mọi thứ, trang này tìm nạp mã AJAX sẽ chỉ có thể khởi động sau khi tài liệu được tải đầy đủ. Vì vậy, chỉ sau khi khách truy cập của bạn tải xuống toàn bộ trang và sau đó là Javascript (nếu đó là tệp bên ngoài), và trình duyệt của họ đã hiển thị và tải nội dung qua AJAX, họ mới thấy nội dung trang.

Mỗi liên kết được nhấp sau đó sẽ nhanh hơn, nhưng tìm nạp trang đầu tiên mà người dùng đã truy cập thực sự sẽ mất nhiều thời gian hơn phiên bản tĩnh.

Lý do tôi gắn nhãn này là một vấn đề có thể xảy ra là bạn luôn có thể gửi trang đầu tiên một cách tĩnh (vì bạn đã có phiên bản tĩnh dưới dạng dự phòng) và sau đó sử dụng AJAX cho các liên kết tiếp theo.

Đối với những gì nó có giá trị, điều này nghe có vẻ không phải là một ý tưởng tồi tệ đối với tôi - đặc biệt đối với việc sử dụng nhạy cảm với băng thông như các trang di động. Tuy nhiên, bạn phải cân nhắc cẩn thận những nhược điểm để đảm bảo rằng nó đáng giá trong trường hợp của bạn.

Có các yếu tố ajax trên một trang là tốt khi bạn có một cơ sở người dùng nhỏ, nhưng khi bạn có nhiều lưu lượng truy cập hơn; bạn muốn sử dụng một cách tiếp cận tĩnh hơn để giảm bớt lạm dụng tài nguyên.

Ví dụ: giả sử bạn có 200 người cố gắng truy cập một trang một giây. Bạn có khoảng 7 truy vấn cơ sở dữ liệu cho các cuộc gọi ajax của bạn; đó là 1400 cơ sở dữ liệu gọi một giây, có thể làm hỏng trang web.

Một trang web cần được thiết kế cho lưu lượng truy cập cao hơn nên có các trang hướng ra ngoài tĩnh, cho nội dung có thể được hiển thị theo cách tĩnh. Điều này đạt được bằng cách sử dụng tập lệnh phía máy chủ chạy mỗi giây để xây dựng lại trang tĩnh, được tìm nạp cho người dùng cuối và do đó bạn đã giảm tải từ 1400 cuộc gọi cơ sở dữ liệu xuống còn 7 giây.

Đây là một cách tiếp cận SOA để xây dựng trang web.