각 부분의 주요 부분을로드하는 아약스 기능으로 사이트를 개발해서는 안되는 확실한 이유가 있습니까 (헤더, 탐색 등과 같은 요소가 동일하다고 가정)?

서버가 모든 페이지에 나타나는 콘텐츠를 제공 할 필요가 없으므로 호스트와 최종 사용자 모두에게 이익이되므로 리소스를 덜 사용하게됩니다.

다음을 고려하여 질문에 답하십시오.

• 모든 사이트에서 자바 스크립트 동작이 정상적으로 저하됩니다.

• 내 질문에 대해서는이 행동을 오프에서 구현할 수있는 새로운 사이트에 대해 이야기하고 있으므로 기술적으로 비용이 들지 않습니다. 우리는 완성 된 제품으로 돌아가서 구현하지 않습니다.

JavaScript가 활성화되지 않은 상태에서 컨텐츠에 도달 할 수 있으면 질문이 의미가 없습니다. 다른 방법으로 콘텐츠에 접근 할 수 있다면 "완전히 Ajaxified"되지 않습니다. 실제로 당신이 요구하는 것은 "Ajax를 통해 사용자의 경험을 향상시키는 것이 괜찮습니까?"입니다. 대답은 분명히 "예"입니다.

편집하다

Google이 크롤링 가능한 Ajax 제안서를 만들었을 때, 그것은 정말 나쁜 생각 으로 패닝되었습니다 . 흥미로운 읽을 거리를 만듭니다.

먼저 첫 번째 것들

프로

• AJAX를 사용하면 공통 "기본"페이지를 사용하고 컨텐츠 영역 만로드하면 페이지의 많은 부분이 이미로드되어 있으므로 사용자의로드 시간이 단축 될 수 있습니다.
• 내용 영역을 페이드 인 및 페이드 아웃하는 것과 같은 눈 사탕을 허용 할 수 있습니다.

단점

• 페이지가 다운로드되면 잘 재생되지 않습니다.
• 장애 장치를 망칠 수 있습니다.
• 자바 스크립트가 꺼져있는 뷰어는 자바 스크립트가 아닌 버전을 사용하지 않는 한 콘텐츠를 전혀 사용할 수 없습니다.
• 훨씬 더 많은 일 (실제로 말해야합니까?).

이제 당신의 질문에

Javascript가없는 사이트의 사이트 성능이 저하되었다고 가정하면 사이트의 수행 방식에 따라 그 정도가 달라집니다. 예를 들어, 자바 스크립트가 아닌 버전에 대한 링크를 파란색으로 표시하면 시청자가 다른 링크를 클릭해야하는 불편이 있습니다. 반면, 기존 링크를 사용하는 "스크립트 메인 페이지"라는 노 스크립트가있는 경우 대부분의 사용자에게 더 효과적이지만 장애 장치를 사용하는 사용자, 즉 사용자가 특정 "페이지"를 방문한 경우에는 지원하지 않습니다. 링크 등

웹 연결 속도가 점점 빨라지는 세상에서 소량의 파일 크기를 자르는 것을 실제로 정당화하지는 않습니다 (우리는 모든 Javascript 자체, CSS 및 이미지를 캐시하고 캐시 할 수 있다고 가정합니다) "베이스"페이지 자체는 바이트를 절약 할 수있는 단점을 제공합니다. 즉, 추가 어려움 (항상 단점은 아니지만 문제가 있지만)과 일부 사용자에게 제공 할 수있는 지원 부족입니다.

전체적으로, 나는 그것이 당신에게 달려 있다고 말할 것입니다. 아마도 잘 작동 할 것입니다. 대부분의 사용자에게는 사이트가 의도 한 것으로 보일지 모르지만 개인적으로는 그렇지 않습니다. 파일 크기를 약간 개선하는 데 어려움을 겪을 가치가 없으므로 귀찮게합니다.

http://gawker.com/을 확인하십시오 -이 사이트는 사실 이후 거의 완전히로드됩니다. "hashbangs"( http://mydomain.com/#!some_section)를 사용하여로드 할 컨텐츠 페이지를 판별하고 기본 탐색은 정적 상태를 유지합니다.

Gawker가 사용하는 개념에 대한 간단한 자습서는 http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ 를 확인하십시오 .

장단점이 있습니다. 검색 엔진 ( http://code.google.com/web/ajaxcrawling/docs/getting-started.html 참조 ), 자바 스크립트를 사용하지 않는 사용자 및 많은 테스트 를 고려해야 합니다.

그에 대한 가장 큰 논쟁은 아마도 사용자가 페이지가로드 될 때까지 기다렸다가 더 많은 로딩을 기다려야 할 때 참을성이 없다는 것입니다. 필자의 견해로는 모범 사례는 기본 사이트, 탐색 및 기본 컨텐츠를 한 번에 (요청시)로드하고 필수적이지 않은 부수적 인 경우 AJAX를 저장하는 것입니다. 그것은 점진적 향상 이라는 아이디어와 함께 작동하며 두 가지 방법 중 가장 좋은 방법을 혼합합니다.

아마도 필요하지 않기 때문입니다.
기본 HTML 문서를로드하는 것은 간단하고 작동합니다. Ajax를 도입하면 브라우저, 코드 및 Javascript, 백엔드 항목, 이상한 해시 방 URL 등에 대한 유지 보수를위한 다른 전체 프로세스 계층이 추가됩니다. 때때로 이것은 정당화 될 수 있으며 때로는 그렇지 않을 수도 있습니다. 일부 서버 리소스를 절약 할 수는 있지만 유지 보수를 상쇄하기에 충분합니까? 프로젝트별로 평가해야합니다.

예를 들어, 트위터가 최신 재 설계를 받았을 때, 그들은 단지 웹 (페이지) 사이트가 아니라 애플리케이션이라는 접근 방식을 취했습니다. 정기적 인 페이지 요청으로 처리됩니다. 지금까지는 훨씬 덜 발생하는 가장 큰 문제 중 하나는 Ajax에 문제가 발생하여 빈 페이지가 표시되는 것입니다.

실제로 '완전 AJAX'웹 사이트, 특히 매우 복잡한 주요 웹 사이트의 경우 많은 작업이 필요합니다. 이를 시도하는 일부 웹 사이트는 Google과 Facebook이지만 완벽하게 수행하지는 않습니다.

일반적인 문제는 탐색 (앞뒤로) 및 북 마킹이지만 많은 개발자가 처리하지 않아도되는 다른 버그가 많이 있습니다. 그리고 그것은 기본적으로 Javascript 및 비 Javascript 사용자와 호환되도록 두 가지 버전의 웹 사이트를 만드는 것을 의미합니다 (잘못된 AJAX 지원이있는 모든 브라우저의 수정 사항).

그렇습니다, 그러나 그것은 다른 방향이어야합니다.

페이지의 공통 부분은 HTTP를 통해 전송되어야합니다. 그런 다음 작은 아약스 (또는 더 나은 웹 소켓) 제어는 동적 컨텐츠를 비동기 적으로로드합니다.

물론 쿠키로 자바 스크립트가 활성화되어 있는지 여부를 먼저 감지하고 활성화 된 경우에만이 방법을 사용해야합니다.

따라서 정상적인 전체 HTTP 경로와 웹 소켓 경로가 필요합니다. node.js와 같은 도구를 사용하지 않으면 코드 복제가 필요합니다.

대부분의 사람들은 추가 노력의 가치가 없다고 생각합니다. 때로는 그렇지 않습니다.

많은 사람들이 제쳐두고 잘못된 페이지를 아약시합니다. 그들은 실제로 자바 스크립트가 아닌 버전이 필요하지 않다고 결정하고 이상한 모든 해시 뱅 URL과 깨진 앞으로 / 뒤로 버튼이 필요합니다. 아약스를 올바르게 사용하려면 HTML5 히스토리가 필요합니다 (IE9에는 없습니다). 또한 개발자는 웹 사이트 버전을 완성해야합니다.

자바 스크립트가 비활성화 된 방문자에게는 정상적으로 성능이 저하 될 것이라고 말 했으므로 두 가지 실제 문제 (및 가능한 문제) 만 볼 수 있습니다.

손쉬운 사용

스크린 리더 및 기타 보조 기술은 종종 동적 DOM 변경으로 인해 발생합니다. 그들은 선형으로 페이지를 처리하고 읽으며 페이지가로드 된 후 페이지의 내용을 변경하면 올바르게 처리되지 않을 수 있습니다.

이 문제를 해결하는 기술이있을 수 있지만 너무 철저히 조사하지는 않았습니다.

복잡성 증가

이런 종류의 사이트를 유지 관리하는 것은 까다로울 수 있습니다. 예를 들어 : 새 레이아웃을 생성하고 AJAX 링크로 교체 할 컨텐츠 영역의 ID를 변경 한 경우 탐색 방식이 매우 복잡 할 수 있습니다.

이러한 종류의 AJAX 동작은 수행중인 트래픽 분석을 복잡하게 만듭니다. Google 웹 로그 분석은에 대한 수동 호출없이 이러한 AJAX로드를 올바르게 등록하지 않습니다 pageTracker._trackPageview('this_page');.

페이지 운영 방식에 복잡성을 더하면 새로운 개발자의 기준이 높아집니다. 사이트에서 작업하는 사람이라면 누구나이 동작이 페이지로드에 어떤 영향을 미치는지 알고 있어야합니다.

가능 : 초기 방문시 페이지로드 속도가 느림

구조를 구성하는 방법에 따라 AJAX 코드를 가져 오는이 페이지는 문서가 완전히로드 된 후에 만 ​​시작할 수 있습니다. 따라서 방문자가 전체 페이지를 다운로드 한 다음 Javascript (외부 파일 인 경우)를 다운로드하고 브라우저가 AJAX를 통해 콘텐츠를 가져 와서 가져온 후에 만 ​​페이지 콘텐츠를 볼 수 있습니다.

클릭 한 각 링크는 더 빠르지 만 사용자가 방문한 첫 페이지를 가져 오는 것은 실제로 정적 버전보다 오래 걸립니다.

내가 이것을 가능한 문제라고 분류 한 이유는 항상 첫 페이지를 정적으로 보낼 수 있기 때문입니다 (정적 버전은 이미 폴백으로 설정되어 있기 때문에) 후속 링크에 AJAX를 사용하기 때문입니다.

그것이 가치있는 것에 대해, 이것은 나에게 끔찍한 생각처럼 들리지 않습니다. 특히 모바일 페이지와 같은 대역폭에 민감한 용도에 적합합니다. 그러나 귀하의 경우에 가치가 있는지 확인하기 위해 단점을 신중하게 고려해야합니다.

작은 사용자 기반이 있지만 더 많은 트래픽이있는 경우 페이지에 아약스 요소를 사용하는 것이 좋습니다. 보다 정적 인 접근 방식을 사용하여 리소스 남용을 줄이려고합니다.

예를 들어, 초당 200 명의 사용자가 한 페이지에 액세스하려고합니다. ajax 호출에 대한 약 7 개의 데이터베이스 쿼리가 있습니다. 즉, 1400 개의 데이터베이스 호출이 1 초이며 웹 사이트가 다운 될 수 있습니다.

더 높은 트래픽을 위해 디자인해야하는 웹 사이트는 정적 방식으로 표시 될 수있는 내용을 위해 정적 외부 페이지를 가져야합니다. 이는 최종 사용자를 위해 페치 된 정적 페이지를 다시 빌드하기 위해 1 초마다 실행되는 서버 측 스크립트를 사용하여로드를 1400 개의 데이터베이스 호출에서 1 초에서 7로 줄였습니다.

웹 사이트 구축에 대한 SOA 접근 방식입니다.