javascript - Ajax를 너무 많이 사용하면 어떤 부작용이 있습니까? 어떻게 해결하나요?

개발 백엔드 관리 시스템에서 데이터를 비교할 때 AJAX를 프런트엔드에서 많이 사용한다면 단점은 무엇인가요? 개선하는 방법은 무엇입니까?

답글 내용:

개발 백엔드 관리 시스템에서 데이터를 비교할 때 AJAX를 프런트엔드에서 많이 사용한다면 단점은 무엇인가요? 개선하는 방법은 무엇입니까?

프론트엔드에는 기본적으로 IO가 없고, Ajax가 절대적인 주요 통신방식입니다.

결론적으로 보면 Ajax는 요청일 뿐입니다. 요청이 너무 많으면 당연히 성능에 영향을 미칠 것입니다. 그러나 Ajax가 한꺼번에 많은 양의 데이터를 요청하고 이를 페이지에서 구문 분석하는 경우에도 매우 문제가 됩니다.
페이지에는 분명히 많은 데이터가 포함됩니다. 이 데이터를 분할하는 방법은 작성 효율성, UI 상호 작용 등 모든 측면에서 고려되어야 합니다.

일반적으로 여전히 경험과 최소 단위 처리 방법에 따라 다릅니다.

Magento2는 knockoutjs를 광범위하게 사용하고 있으며, 많은 데이터가 AJAX에서 제공됩니다.

가장 일반적인 문제는 다수의 요청에 대한 아키텍처 설계와 부분적인 데이터 새로 고침입니다.

• AJAX에서 다운로드한 데이터는 캐시되어야 하며 알림을 받은 후 다시 검색됩니다.

• 다른 블록의 데이터에 영향을 주지 않고 데이터를 부분적으로 새로 고치는 방법.

위의 문제를 해결하려면 상대적으로 거시적인 아키텍처 설계가 필요합니다.

Ajax가 부작용이 있다고는 생각하지 않습니다. 문제가 있으면 SPA가 어떻게 살아남을 수 있을까요? .

사용자 상호작용의 관점에서 볼 때 AJAX는 더 많은 이점을 갖고 있으며 사용자 경험을 향상시킵니다.
요청 동시성의 관점에서는 좋지 않지만, 물론 일반적으로 서버 측에서 해결할 수도 있습니다. 그것도 마찬가지다.

현재 개발 중인 모든 백엔드 관리 시스템은 js로 라우팅되고 단일 페이지여야 하지 않나요? 왜 아직도 아약스 같은 것이 존재하는 걸까요?

여러 개의 아이콘을 하나의 이미지로 합치는 CSS Sprite(CSS 스프라이트) 기술은 실제로 네트워크 요청을 줄이기 위한 것입니다.
네트워크 요청을 줄이면 브라우저와 서버 모두의 성능이 향상될 수 있음을 알 수 있습니다.
AJAX 너무 많으면 네트워크 요청이 많아지고, 너무 많으면 좋지 않습니다.
그러나 AJAX를 일부 백그라운드 페이지 넘김 및 메시지 알림에 사용하면 경험은 여전히 ​​좋습니다.

앞뒤 분리라면 Ajax는 핵심적인 대화형 통신 방식인데, 여기서 다루어야 할 것은 Ajax의 비동기 제어 프로세스이다.