Rút gọn HTML? [đóng cửa]


99

Có công cụ trực tuyến nào mà chúng ta có thể nhập nguồn HTML của một trang vào và sẽ rút gọn mã không?

Tôi sẽ làm điều đó cho các tệp aspx vì nó không phải là một ý kiến ​​hay khi làm cho máy chủ web gzip chúng ...


19
Khi nào có máy chủ gzip là một ý tưởng tồi?
Chuck

5
Tôi đọc điều đó vì các trang aspx không phải là tệp tĩnh, nó sẽ không được lưu vào bộ nhớ cache của IIS và vì vậy nó sẽ gzip trang theo mọi yêu cầu ...
Paulo

23
... và đó có phải là một vấn đề? Trừ khi máy chủ của bạn đã ở mức 99,9% CPU, có lẽ là không. gzipping là công việc thường làm và hiệu quả hơn nhiều so với bất kỳ sự 'thu nhỏ' nào.
bobince


2
Các câu trả lời ở đây đã lỗi thời, chưa kể một số chúng sai. Vui lòng kiểm tra giải thích của tôi về vấn đề và công cụ thích hợp .
Salvador Dali

Câu trả lời:


63

Có lẽ hãy thử HTML Compressor , đây là bảng trước và sau hiển thị những gì nó có thể làm (bao gồm cả đối với chính Stack Overflow):

Xin lỗi, markdown không có khái niệm về bảng

Nó có nhiều lựa chọn để tối ưu hóa các trang của bạn lên đến và bao gồm giảm thiểu tập lệnh (ompressor, Google Closure Compiler, máy nén của riêng bạn) ở nơi an toàn. Bộ tùy chọn mặc định khá thận trọng, vì vậy bạn có thể bắt đầu với bộ đó và thử nghiệm với việc bật các tùy chọn linh hoạt hơn.

Dự án được ghi chép và hỗ trợ rất tốt.


58

Đừng làm điều này . Hoặc đúng hơn, nếu bạn nhấn mạnh vào nó, hãy làm điều đó sau khi hoàn tất bất kỳ tối ưu hóa trang web quan trọng nào. Rất có thể chi phí / lợi ích cho nỗ lực này là không đáng kể, đặc biệt nếu bạn định sử dụng thủ công các công cụ trực tuyến để xử lý từng trang.

Sử dụng YSlow hoặc Tốc độ trang để xác định những gì bạn thực sự cần làm để tối ưu hóa các trang của mình. Tôi đoán rằng việc giảm byte HTML sẽ không phải là vấn đề lớn nhất của trang web của bạn. Có nhiều khả năng nén, quản lý bộ nhớ cache, tối ưu hóa hình ảnh, v.v. sẽ tạo ra sự khác biệt lớn hơn cho hiệu suất tổng thể của trang web của bạn. Những công cụ đó sẽ cho bạn thấy những vấn đề lớn nhất - nếu bạn đã giải quyết tất cả chúng và vẫn thấy rằng việc rút gọn HTML tạo ra sự khác biệt đáng kể, hãy tiếp tục.

(Nếu bạn chắc chắn muốn tiếp tục và sử dụng Apache httpd, bạn có thể cân nhắc sử dụng mod_pagespeed và bật một số tùy chọn để giảm khoảng trắng, v.v., nhưng hãy lưu ý các rủi ro .)


25
Có gì sai với việc tối ưu hóa nếu mã được rút gọn dễ đọc bằng cách sử dụng tính năng làm đẹp tự động?

12
Nó có lẽ không phải là vấn đề lớn nhất - nhưng nếu đó là một quá trình nhỏ để chạy đánh dấu thông qua một bộ thu nhỏ của regex khi biên dịch từ dev sang qa hoặc prod, thì tại sao bạn không muốn gửi các tài liệu đánh dấu nhỏ hơn?
Will Peavy

26
Không thực sự là một câu trả lời cho câu hỏi ban đầu :(
Chuck Lê Butt

7
@Will, gần như chắc chắn không phải là một quá trình tầm thường để chạy HTML thông qua việc thu nhỏ các regex, và thậm chí sử dụng một trình phân tích cú pháp thích hợp thì nó có lẽ không hề nhỏ hoặc nhanh. Hơn nữa, không giống như rút gọn JS / CSS, rút ​​gọn HTML sẽ không mất mát: bất kỳ thẻ nào cũng có thể được tạo kiểu white-space: prevà quá trình thu nhỏ sẽ phá hủy văn bản được định dạng trước.
mí mắt

3
@eyelidless - Tôi hiện có hàng nghìn trang trong số đó được thu nhỏ bởi regexes trước khi chúng được phân phát. Chức năng này không phải là một phần phức tạp hoặc đắt tiền của hệ thống. ... Mặt khác, nếu bạn muốn phân tích cú pháp theo kiểu tính toán để tránh thu nhỏ các phần tử được tạo kiểu white-space:pre, thì vâng, việc rút gọn HTML sẽ phức tạp hơn. Tuy nhiên, tôi không rõ tại sao ai đó muốn sử dụng khoảng trắng: pre hơn là sử dụng một prehoặc codephần tử.
Will Peavy

34

Đây là câu trả lời ngắn gọn cho câu hỏi của bạn: bạn nên giảm thiểu HTML, CSS, JS . Có một công cụ dễ sử dụng được gọi là grunt . Nó cho phép bạn tự động hóa rất nhiều tác vụ. Trong số đó có JS , CSS , rút gọn HTML , nối tệpnhiều thứ khác .

Các câu trả lời được viết ở đây là cực kỳ lỗi thời hoặc thậm chí đôi khi không có ý nghĩa. Có rất nhiều thứ đã thay đổi so với năm 2009 cũ, vì vậy tôi sẽ cố gắng trả lời điều này một cách hợp lý.

Câu trả lời ngắn gọn - bạn chắc chắn nên rút gọn HTML . Hôm nay nó không bình thường và tăng tốc khoảng 5% . Để có câu trả lời dài hơn, hãy đọc toàn bộ câu trả lời

Ngày xưa, mọi người đang thu nhỏ css / js theo cách thủ công (bằng cách chạy nó thông qua một số công cụ cụ thể để thu nhỏ nó). Thật khó để tự động hóa quy trình và chắc chắn đòi hỏi một số kỹ năng. Biết rằng rất nhiều trang web cấp cao thậm chí ngay bây giờ không sử dụng gzip (điều này thật tầm thường), nên có thể hiểu được rằng mọi người đã miễn cưỡng trong việc giảm thiểu html.

Vậy tại sao mọi người lại rút gọn js mà không phải html ? Khi bạn rút gọn JS, bạn thực hiện những việc sau:

  • xóa bình luận
  • xóa khoảng trống (tab, dấu cách, dòng mới)
  • đổi tên dài thành ngắn ( var isUserLoggedInthành var a)

Điều này đã cải thiện rất nhiều ngay cả ở những ngày cũ. Nhưng trong html, bạn không thể đổi tên dài thành ngắn, và hầu như không có gì để bình luận trong thời gian đó. Vì vậy, điều duy nhất còn lại là xóa dấu cách và dòng mới. Điều này chỉ mang lại một số cải tiến nhỏ.

Một lập luận sai lầm được viết ở đây là bởi vì nội dung được cung cấp bằng gzip, nên việc thu nhỏ không có ý nghĩa. Điều này là hoàn toàn sai lầm. Đúng vậy, việc gzip làm giảm sự cải thiện của việc thu nhỏ cũng có lý, nhưng tại sao bạn nên gzip nhận xét, khoảng trắng nếu bạn có thể cắt chúng đúng cách và gzip chỉ là phần quan trọng. Nó cũng giống như việc bạn có một thư mục để lưu trữ trong đó có một số thứ tào lao mà bạn sẽ không bao giờ sử dụng và bạn quyết định chỉ nén nó thay vì dọn dẹp và nén nó.

Một lập luận khác tại sao việc thu nhỏ lại vô nghĩa là nó tẻ nhạt. Có thể điều này đúng vào năm 2009, nhưng các công cụ mới đã xuất hiện sau thời điểm này. Ngay bây giờ bạn không cần phải thu nhỏ đánh dấu của mình theo cách thủ công. Với những thứ như Grunt , việc cài đặt grunt-Contrib-htmlmin (dựa trên HTMLMinifier của @kangax) và cấu hình nó để giảm thiểu html của bạn là điều rất dễ dàng. Tất cả những gì bạn cần là 2 giờ để học grunt và cấu hình mọi thứ và sau đó mọi thứ được thực hiện tự động trong vòng chưa đầy một giây. Âm thanh rằng 1 giây (thậm chí bạn có thể tự động hóa để không làm gì với grunt-Contrib-watch ) thực sự không quá tệ đối với khoảng 5% cải thiện (ngay cả với gzip).

Một lập luận nữa là CSS và JS là tĩnh và HTML được tạo bởi máy chủ nên bạn không thể thu nhỏ trước nó. Đây cũng là sự thật trong năm 2009, nhưng hiện tại nhiều hơnnhiều trang web đang tìm kiếm giống như một ứng dụng trang duy nhất, nơi mà các máy chủ là mỏng và khách hàng đang thực hiện tất cả các định tuyến, templating và logic khác. Vì vậy, máy chủ chỉ cung cấp cho bạn JSON và máy khách kết xuất nó. Ở đây bạn có rất nhiều html cho trang và các mẫu khác nhau.

Vì vậy, để kết thúc suy nghĩ của tôi:

  • google đang thu nhỏ html.
  • pageSpeed đang yêu cầu bạn rút gọn html
  • nó là tầm thường để làm
  • nó mang lại ~ 5% cải thiện
  • nó không giống như gzip

3
Việc loại bỏ HTML hoàn toàn không phải là chuyện nhỏ, vì khoảng trắng rất quan trọng trong HTML và việc loại bỏ bất kỳ khoảng trắng nhất định nào có thể được xóa tùy thuộc vào CSS. Ngoài ra, các ứng dụng khách mỏng rất tệ và theo tôi, không thể được coi là một lý lẽ tốt để chống lại những rắc rối của việc giảm thiểu HTML động. (Một cách tốt để làm điều đó là chọn một công cụ mẫu [Haml, Jade, v.v.] không bao gồm khoảng trắng không cần thiết trong kết xuất hiển thị của nó ngay từ đầu.)
Ry-

@minitech rút gọn HTML là điều không bình thường, cũng có một số vấn đề có thể xảy ra với khoảng trắng (như <span>). Trước hết, bạn luôn có thể tìm ra cách để viết html hợp lệ làm cho nó trở nên bất khả tri về khoảng trắng. Ngoài ra, bạn có thể ngạc nhiên khi nghe nói, nhưng trình thu nhỏ JS / CSS cũng có thể tạo ra một lỗi - điều đó không có nghĩa là bạn không nên sử dụng nó. Vì vậy, hai cách để giải quyết vấn đề của bạn: học cách viết đánh dấu bất khả tri khoảng trắng, kiểm tra sản phẩm của bạn trước / sau khi thu nhỏ (CSS / HTML / JS). Ngoài ra trong Minifier, bạn có thể chỉ định những khoảng trắng nào bạn muốn giữ lại.
Salvador Dali

Các trình thu nhỏ JavaScript đúng trên mã không điên (tức là mã không tự đọc hoặc gian lận theo thời gian) không thể tạo ra lỗi. Và không, không phải lúc nào cũng có cách viết HTML bất khả tri về khoảng trắng, cụ thể là vì HTML, một lần nữa, không phải là HTML bất khả tri về khoảng trắng. Ở tất cả. Đảm bảo kiểm tra việc sao chép và dán trên này nếu bạn nghĩ rằng lề sẽ cắt nó. Việc chỉ định khoảng trắng nào tôi muốn giữ lại nghe có vẻ lãng phí thời gian (ngoại trừ Google)…
Ry-

@minitech bạn có thể chỉ cho tôi CSS không thể viết theo cách bất khả tri của khoảng trắng được không? Tôi đang thu nhỏ html trong một thời gian dài, và không thấy vấn đề gì cho đến nay.
Salvador Dali

* { white-space: pre; }là một điều hiển nhiên, nhưng nếu bạn đang xóa tất cả khoảng trắng và không chỉ thu gọn nó (thay vào đó là lề), văn bản có thể sao chép không chính xác và tàn phá trình duyệt văn bản và trình đọc màn hình.
Ry-

23

Tôi đã viết một công cụ web để rút gọn HTML. http://prettydiff.com/?m=minify&html

Công cụ này hoạt động theo các quy tắc sau:

  • Tất cả các nhận xét HTML đều bị xóa
  • Các ký tự khoảng trắng chạy được chuyển đổi thành các ký tự khoảng trắng đơn
  • Các ký tự khoảng trắng không cần thiết bên trong thẻ bị xóa
  • Các ký tự khoảng trắng giữa hai thẻ trong đó một trong hai thẻ này không phải là một thẻ đơn sẽ bị xóa
  • Tất cả nội dung bên trong stylethẻ được cho là CSS và được rút gọn như vậy
  • Tất cả nội dung bên trong scriptthẻ được cho là JavaScript, trừ khi được cung cấp một loại phương tiện khác và sau đó được rút gọn như vậy
    • Việc rút gọn CSS và JavaScript sử dụng một dạng JSMin được chia nhỏ. Fork này được mở rộng để hỗ trợ CSS nguyên bản và cũng hỗ trợ cú pháp SCSS. Tính năng chèn dấu chấm phẩy tự động được hỗ trợ để rút gọn JavaScript, tuy nhiên tính năng chèn dấu ngoặc nhọn tự động chưa được hỗ trợ.

    7
    Xin chào, nó xóa dòng này! <!--[if IE 8.0]><link rel="stylesheet" href="css/ie8.css" type="text/css" /><![endif]-->
    UnLoCo

    1
    yeah, đây sẽ là một thảm họa nếu bạn đang sử dụng ko!
    Ray Suelzer

    8

    Điều này đã làm việc cho tôi:

    http://minify.googlecode.com/git/min/lib/Minify/HTML.php

    Nó không phải là một công cụ trực tuyến đã có sẵn, nhưng là một PHP đơn giản bao gồm nó đủ dễ dàng để bạn có thể tự chạy nó.

    Mặc dù vậy, tôi sẽ không lưu các tệp nén, hãy thực hiện việc này một cách linh hoạt nếu bạn thực sự phải làm vậy và luôn là ý tưởng tốt hơn để bật tính năng nén máy chủ Gzip. Tôi không biết nó liên quan như thế nào trong IIS / .Net, nhưng trong PHP, việc thêm một dòng vào tệp bao gồm toàn cầu cũng đơn giản như vậy


    6

    CodeProject có một dự án mẫu đã xuất bản ( http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx?fid=1528916&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2794900 ) để xử lý một số tình huống sau .. .

    • Kết hợp các lệnh gọi ScriptResource.axd thành một lệnh gọi
    • Nén tất cả các tập lệnh phía máy khách dựa trên khả năng của trình duyệt bao gồm gzip / deflate
    • ScriptMinifier để xóa nhận xét, thụt lề và ngắt dòng.
    • Một máy nén HTML để nén tất cả đánh dấu html dựa trên khả năng của trình duyệt bao gồm gzip / deflate.
    • Và - quan trọng nhất - một HTML Minifier để viết html hoàn chỉnh thành một dòng duy nhất và thu nhỏ nó ở mức có thể (đang được xây dựng).

    3

    Đối với nền tảng Microsoft .NET, có một thư viện được gọi là WebMarkupMin , nó tạo ra sự thu nhỏ của mã HTML.

    Ngoài ra, có một mô-đun để tích hợp thư viện này vào ASP.NET MVC - WebMarkupMin.Mvc .


    1

    hãy thử http://code.mini-tips.com/html-minifier.html , đây là .NET Libary cho Html Minifier

    HtmlCompressor là một thư viện .NET nhỏ, nhanh và rất dễ sử dụng, thu nhỏ nguồn HTML hoặc XML đã cho bằng cách loại bỏ các khoảng trắng thừa, nhận xét và các ký tự không cần thiết khác mà không phá vỡ cấu trúc nội dung. Kết quả là các trang có kích thước nhỏ hơn và tải nhanh hơn. Một phiên bản dòng lệnh của máy nén cũng có sẵn.

    Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
    Licensed under cc by-sa 3.0 with attribution required.