얼마 전 Xiao Du가 그룹에서 "HTML 쓰기가 gzip 압축률에 미치는 영향"이라는 기사를 공유하는 것을 보고 이 점에 대해서도 분석했습니다.
이 글을 읽어보셨을지는 모르겠지만, 글쓴이는 웨이보 게으른 교류회 출신입니다.
Gzip 알고리즘은 크게 Haferman 알고리즘과 LZ77 알고리즘으로 구성됩니다.
파일에 동일한 콘텐츠가 두 개 있는 경우 이전 콘텐츠의 위치와 크기를 알고 특정 압축 식별자를 통해
콘텐츠를 확인할 수 있습니다. 다음 작품의. 따라서 우리는 후자의 콘텐츠를 위치 길이와 같은 정보 쌍으로 대체할 수 있습니다.
예
<html><head> <title></title> <meta charset="utf-8" /></head><body> <form action=""> <input class="J_Textarea" type="text" name="name123" id="id1"/> <input class="J_Textarea" type="password" name="name223" id="id2"/> <input class="J_Textarea" type="radio" name="name323" id="id3"/> <input class="J_Textarea" type="checkbox" name="name423" id="id4"/> </form></body></html>
gzip으로 압축한 후 Chrome 개발자 도구에 표시되는 크기는 563B입니다.
입력 태그의 속성 순서를 섞은 후:
<html><head> <title></title> <meta charset="utf-8" /></head><body> <form action=""> <input class="J_Textarea" type="text" name="name123" id="id1"/> <input name="name123" class="J_Textarea" type="password" id="id2"/> <input type="radio" id="id3" name="name323" class="J_Textarea"/> <input id="id4" type="checkbox" class="J_Textarea" name="name423"/> </form></body></html>
gzip 압축 결과 표시되는 크기는 578B입니다.
기사 내용은 대충 이렇습니다. 그러면 CSS도 비슷한 효과가 있을까라고 곰곰히 생각해 봤습니다.
먼저 CSS 파일에 속성을 순서대로 작성하세요:
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; line-height: 26px; color:green;}
gzip으로 본 크기는 463B입니다
속성이 무질서해진 후:
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f2{font-size:14px; color:green; line-height: 26px;}
gzip 이후의 크기는 464B
이를 보면 html뿐만 아니라 CSS도 비슷한 효과가 있다는 결론을 내릴 수 있습니다.
어떤 사람들은 행 사이에 다른 클래스가 있으면 어떻게 될까요?라고 묻습니다.
@charset "utf-8"; .f1{font-size:10px; color:red; line-height: 22px;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}
size:482B
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;}.f9{background: red;}.f2{font-size:14px; color:green; line-height: 26px;}
size:480B
이 결과와 위의 결론 그것은 다르다.
행 간의 연속성도 압축률에 영향을 미칠 수 있음을 알 수 있습니다.
즉, 코드 유사율이 높을수록 압축률이 높아집니다.
압축률 측면에서든 코드의 깔끔함과 아름다움 측면에서든 팀과 압축이 용이하도록 코드를 순서대로 작성해야 합니다.
크롬 개발자 도구 네트워크의 크기/콘텐츠 값 차이:
이 측면을 조사한 것 외에도 크롬 개발자 도구에서 네트워크/크기 열을 발견했습니다. 다소 이해하기 어렵습니다.
저는 그의 크기와 내용 때문에 오랫동안 고민해 왔습니다. 그게 무슨 뜻인지 모르겠어요. 크기가 콘텐츠 값보다 클 때도 있고, 콘텐츠 값보다 작을 때도 있습니다.
CJ의 지도와 직접 실험을 거쳐 얻은 결과는 다음과 같습니다.
크기 값은 네트워크 전송 콘텐츠의 크기를 의미하며, 요청/응답 헤더의 gzip 크기와 파일 콘텐츠의 gzip 크기를 포함합니다.
Content 값은 주요 콘텐츠 본문의 gzip 압축 해제 크기, 즉 페이지 파일 크기를 의미합니다.
Size가 Content 값보다 크다면 헤더가 본문의 gzip 압축 해제보다 훨씬 크다는 뜻이며, 그 반대의 경우도 마찬가지입니다.
페이지에 처음 접속했을 때 얻은 크기 값이 새로 고친 후의 크기 값보다 훨씬 작은 것을 확인할 수 있습니다. 페이지에 캐시가 켜져 있기 때문에 네트워크에서 다시 로드할 필요가 없습니다.
개인적으로는 FireBug 값이 Chrome 값보다 더 직관적이라고 생각합니다. FireBug의 크기는 gzip 값입니다. 크롬에서는 gzip의 크기를 찾을 수 없는 것 같습니다.
서버측 반환 헤더 정보에 Content-Length 필드가 없으면 이 필드에서도 gzip 크기를 확인할 수 있습니다. 그러나 이 필드는 일반적으로 출력되지 않습니다.
위 내용은 HTML 작성이 gzip 압축률에 미치는 영향의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!