웹사이트 정적 처리 - csi

CSI는 브라우저 측 동적 및 정적 통합 솔루션입니다. 내 기사가 게시된 후 친구가 CSI 기술이 Ajax를 통해 데이터를 로드하는 것인지 물었습니다. 당시 내 대답은 당신이 조금 이해했다는 것뿐이었습니다. 그렇다면 CSI 기술은 정확히 무엇일까요? 이는 실제로 동적 자원과 정적 자원을 통합하는 관점에서 정의되어야 합니다.

CSI 기술은 실제로 페이지가 정적 리소스에서 분리된 후 두 단계로 페이지 로딩을 나눕니다. 첫 번째 단계는 정적 리소스를 로드한 후 두 번째 단계는 동적 리소스를 로드하는 것입니다. 하지만 이 정의는 아직 불완전합니다. 불완전한 부분은 동적 리소스와 정적 리소스를 분리하는 목적을 강조해야 한다는 것입니다. 정적 리소스를 효과적으로 캐시하기 위해 페이지에서 동적 리소스와 정적 리소스를 분리해야 합니다. 페이지에 있을 수도 있고, 브라우저에 있을 수도 있습니다. 정적 리소스가 어떻게 캐시되든 우리의 목적은 정적 리소스를 더 빠르게 로드하는 것입니다. 리소스가 효율적이게 되면 CSI 양식을 사용하여 페이지를 디자인하더라도 실제로는 CSI의 장점을 활용하지 않고 실수로 CSI의 단점을 도입하게 됩니다. 그렇다면 CSI의 단점은 무엇입니까?

CSI의 단점 1 : CSI는 페이지의 SEO, 즉 검색엔진 최적화에 도움이 되지 않습니다. 검색 엔진 웹 크롤러는 일반적으로 URL을 기반으로 페이지에 액세스하여 페이지의 콘텐츠를 획득하고 CSS 스타일, js 스크립트와 같은 쓸모 없는 정보를 제거한 다음 나머지 텍스트 콘텐츠를 분석합니다. 이 로딩 제어는 JavaScript 코드로 완료되어야 하므로 웹 크롤러가 크롤링한 페이지에서는 비동기 로딩 작업을 수행할 수 없습니다. (일부 고급 크롤러는 비동기 작업을 수행하고 비동기 콘텐츠를 캡처할 수 있다고 들었습니다. 기술적으로 대부분의 주류 크롤러는 여전히 JavaScript 코드와 비동기적으로 로드된 콘텐츠를 무시하므로 크롤러가 크롤링하는 페이지의 일부 정보가 손실되므로 CSI는 SEO에 그다지 친숙하지 않습니다. 그러나 이 단점을 주의 깊게 분석하면 그다지 심각하지 않을 수 있습니다. 앞에서 정적 분리 전략에 대해 많이 이야기했습니다. 동적 및 정적 분리 전략을 잘 수행하면 동적 리소스는 기본적으로 캐시할 수 없는 콘텐츠입니다. 이러한 변경 내용은 웹 크롤러가 크롤링할 필요가 없습니다. 크롤링하더라도 검색 엔진에서는 이 페이지를 클릭하면 검색 결과를 찾을 수 없습니다. 페이지에서 검색 엔진을 사용할 때 많은 친구들이 이런 상황에 직면하게 될 것이라고 생각합니다. 하지만 개발자가 CSI를 올바르게 사용하지 않으면 이 영역을 특히 잘 처리하지 못할 수 있으므로 이러한 단점은 여전히 ​​쉽게 나타납니다.

CSI의 단점 2: 웹 사이트를 정적으로 만드는 데 너무 많은 시간과 노력을 소비합니다. 페이지 로딩 속도를 빠르게 만드는 것이 목적이므로 단순히 페이지 로딩을 두 단계로 나누는 것입니까? 정말 빠르지? 사실, 동적과 정적을 분리하는 방법은 이전 시리즈에서 언급한 데이터베이스 읽기와 쓰기의 분리와 유사합니다. 읽기 병목 현상을 해결하기 위해 웹 페이지의 동적 및 정적 분리는 정적 리소스를 쉽게 최적화할 수 있기 때문에 동적 리소스와 정적 리소스를 분할해야 합니다. 따라서 동적 리소스와 정적 리소스를 분리했지만 정적 리소스를 최적화하지 않으면 페이지 로딩 속도를 높이는 작업이 누락된 것이 한눈에 분명하므로 페이지가 더 빨리 로드될 수 있는지 여부를 말하기가 정말 어렵습니다. , 비동기 로딩에는 자바스크립트 코드 실행이 필요하지만, 정적 리소스 로딩 시 자바스크립트 스크립트가 차단되기 쉽습니다. 차단된 스크립트가 비동기 로딩 부분인 경우 결과가 이전보다 느려질 뿐입니다.

앞서 언급한 SSI와 ESI 기술은 브라우저 측에서 CSI 기술의 장점을 활용하는 데 매우 필요하다고 볼 수 있습니다. SSI와 ESI는 정적 리소스를 잘 활용했습니다. 동적 리소스와 정적 리소스를 분리할 수 있으므로 CSI 작업의 첫 번째 단계도 효율적으로 수행됩니다. 첫 번째 단계가 처리되면 페이지의 비동기 로딩에 대한 스크립트 차단의 영향만 제어하면 됩니다. 전체 페이지 로딩 효율성을 향상시킵니다. 또한 CSI가 SEO에 큰 영향을 미친다는 것은 잘못된 제안이라고 생각합니다. CSI를 사용하여 SEO 결과가 좋지 않다면 CSI 계획의 설계가 제대로 이루어지지 않은 것임에 틀림없습니다.

어떤 사람들은 CSI에 단점이 있다고 생각하는데 이건 사실 디자인 문제이고 좋고 나쁨은 개인의 운용 습관에 따라 결정되는 것 같아요. 다른 사람들이 생각하는 이 단점은 무엇입니까? CSI 기술을 사용하면 페이지가 빠르게 로드되지만 동적 콘텐츠 부분에 로딩 프롬프트가 표시될 수 있으며 이로 인해 페이지의 사용자 친화성이 저하됩니다. 실제로 이러한 종류의 동기 및 비동기 로딩 매시업 작업은 다음과 같습니다. 거의 모든 대형 포털, 전자상거래 웹사이트 및 수많은 웹사이트에서는 동기식 로딩 ​​방식과 비동기식 로딩 ​​방식을 혼합하여 사용하고 있습니다. 만약 이러한 웹사이트들이 이것을 하지 않는다면, 홈페이지 로딩과 같은 이러한 웹사이트들은 반드시 그렇게 될 것이라고 믿습니다. 속도가 너무 느려 사람들이 피를 토하게 만들 정도입니다. 많은 웹 페이지에 콘텐츠가 너무 많고 사진이 약간 부담스럽기 때문에 동기식 로딩 ​​방식과 비동기식 로딩 ​​방식을 혼합해서 사용해야 하고 심지어 사진과 같은 정적 리소스도 많이 사용해야 하기 때문입니다. 플래시도 비동기식입니다. 그럼에도 불구하고 일부 사람들은 페이지가 로드될 때 로딩 프롬프트가 마음에 들지 않을 수도 있습니다. 그러나 웹 페이지에서는 CSI의 이점이 매우 필요합니다. 이 문제는 해결하기 쉽습니다. 우선, CSI 기술을 사용할 의향이 있다면 사용자가 여전히 비동기 로딩 기술을 사용할 의향이 있다는 뜻입니다. 마음에 들지 않으면 로딩 메시지가 표시됩니다. 이는 사용자가 동기 로딩 작업을 수행할 때 비동기 작업을 혼합하지 않기를 원한다는 것을 의미합니다. 비록 Ajax 기술이 현재 매우 인기가 있지만 Ajax 기술의 동기 로딩을 해결할 방법은 없습니다. 즉, 브라우저에 웹사이트 URL을 입력합니다. 주소 표시줄을 사용하여 페이지를 요청하므로 위의 요구 사항에 따라 이 동기화 작업이 단 하나인지 확인하면 됩니다. 비동기 로딩 없이 순수 동기 작업을 사용하면 됩니다. 이 솔루션은 구현하기 쉽기 때문에 다루지 않겠습니다. 자세한 내용은 여기를 참조하세요.

동적 및 정적 분리 후에는 정적 리소스를 캐시합니다. 이전 기사에서는 서버 측의 정적 리소스 캐싱에 대해 많이 설명했습니다. 이제 CSI가 브라우저 측에 도착했습니다. . 브라우저 캐싱 작업에 대해 이야기해 보세요. 페이지의 캐싱 작업은 HTTP의 만료 및 캐시 제어를 사용하는 것입니다. 먼저 다음 작성을 살펴보겠습니다.

<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">

이것은 현재 작업 중인 Java 웹 프로젝트인 jsp와 모두에서 사용됩니다. vm 파일은 메타 구성을 사용하며 그 목적은 브라우저에서 페이지를 캐시하는 것을 방지하는 것이지만 CSI 기술을 사용하고 동적 및 정적 분리가 잘 이루어지면 실제로 더 이상 페이지 헤더에 이것을 쓸 수 없습니다. 페이지를 합리적으로 만들 수 있습니다. 시간 범위 내에서 브라우저에 의해 캐시됩니다. 페이지가 캐시되면 나중에 페이지를 방문할 때 웹 페이지의 로딩 효율성이 높아집니다.

여기에는 또 다른 문제가 있습니다. Yahoo의 웹사이트 최적화 제안에는 웹페이지의 병렬 로딩 특성을 최대한 활용하기 위해 이미지, 외부 js 및 CSS 파일을 별도의 정적 웹 컨테이너에 배치하거나 CDN을 사용하면 브라우저에서 이러한 파일을 캐시할 수 있는 경우가 많습니다. 브라우저가 이를 캐시하도록 하려면 어떻게 해야 할까요? 여기서는 Apache를 예로 들어 브라우저에서 정적 리소스를 캐시하도록 허용하려면 Apache에서 mod_expires 모듈을 사용한 다음 Apache 구성 파일에 다음 구성을 추가해야 합니다.

<FilesMatch "\.(gif|jpg|png|js|css">ExpiresDefault "access plus 10 years"</FilesMatch>

그런 다음 브라우저는 이 아파치에 액세스합니다. 정적 리소스가 생성된 후 브라우저는 서버의 이미지와 js 및 css 파일을 브라우저에서 캐시합니다.

http 응답 코드가 304이면 브라우저는 캐시에서 리소스를 읽습니다. 여기에 캐시된 리소스에 대해 http 요청이 전송되는 이유가 궁금할 수도 있습니다. 이를 이해하려면 캐싱의 메커니즘을 이해해야 합니다. 캐싱의 의미는 임시 저장이므로 저장에 대한 유효 기간이 있어야 합니다. 캐싱을 정의하는 방식은 http를 통해 이루어집니다. 따라서 캐시가 만료되었는지 여부도 http로 확인해야 하므로 캐시를 사용할 때마다 서버는 리소스가 만료되지 않았는지 확인해야 합니다. 만료되면 서버는 304 응답 코드, 304를 반환합니다. 반환 응답에는 http 메시지 본문이 없으므로 이 http 요청의 반환 데이터는 매우 작으므로 서버가 이를 발견하면 이 http 효율성은 여전히 ​​매우 높습니다. 리소스가 만료되면 서버는 새 리소스를 브라우저에 반환합니다. 실제로 리소스가 만료되었는지 여부를 감지하는 이 요청에는 조건부 가져오기 요청이라는 적절한 이름이 있습니다. 서버가 어떻게 검사 작업을 완료하는지에 대해서는 이 시리즈에서 웹 프론트엔드 최적화에 대해 이야기할 때 자세히 설명할 것이므로 여기에서는 자세히 다루지 않겠습니다. 이것을 보고 어떤 친구들은 왜 브라우저 측에서 캐시 만료를 결정할 수 없는지에 대해 다시 질문을 할 수 있습니다. 이는 주로 브라우저의 검사가 매우 부정확하기 때문이며, 사용자의 컴퓨터 시계가 정확하지 않을 수 있거나, 사용자의 컴퓨터 시계가 서버의 시계와 일치하지 않을 수 있기 때문입니다. 시간대를 추가하면 더욱 번거롭기 때문에 최선입니다. 캐시된 유효 기간의 정확성을 보장하기 위해 서버에서 캐시를 무효화합니다. html5의 출현으로 브라우저 캐싱 기능이 크게 향상되었습니다. 그러나 캐싱을 위한 html5 기술의 사용에 대해서는 깊이 있게 연구하지 않았으므로 여기서는 이에 대해 설명하지 않겠습니다.

자, CSI 기술과 브라우저에 관해서는 이 시리즈의 또 다른 중요한 콘텐츠인 프런트엔드와 백엔드의 분리를 시작하겠습니다. 이것이 내 다음 기사의 주제가 될 것입니다. 제 블로그에서 여러 번 언급한 적이 있는 프론트엔드와 백엔드 분리에 대해서는 조만간 다시 한번 말씀드리도록 하겠습니다. .