Hiệu suất 101: xây dựng trang web tốt hơn

  • Post category:lập trình


Hôm nay chúng ta đang xem xét hiệu suất web. Tôi sẽ chia sẻ một số liên kết hữu ích tới các bài viết và hướng dẫn được viết bởi những người có nhiều kinh nghiệm chuyên môn về chủ đề này. Tôi đang viết dưới góc nhìn của một nhà phát triển, người đã áp dụng những kiến ​​thức này vào thực tế. Tôi đã học được một số bài học trong quá trình này và bạn cũng có thể học hỏi từ đó.

Nếu bạn muốn liên hệ, trao đổi về hiệu suất hoặc những nội dung bổ sung cho bài đăng này, bạn luôn có thể liên hệ với tôi qua email.

Không dài dòng nữa, hãy đi sâu vào chủ đề bí ẩn về hiệu suất web. Chúng ta sẽ bắt đầu thảo luận về tư duy mà bạn nên có khi xây dựng các trang web hoạt động hiệu quả. Sau đó, chúng ta sẽ chuyển sang nhiều ví dụ thực tế và liên kết đến các tài nguyên học tập khác.

#Tư duy hiệu suất

Nếu có một điều bạn nên rút ra từ bài đăng này thì đó là tư duy mà mọi nhà phát triển web nên có. Ngành xây dựng các công cụ, khuôn khổ và hệ thống để giúp cuộc sống của các nhà phát triển trở nên dễ dàng hơn. Trong khi đó, bạn quên mất việc phát triển web thực sự là gì. Chúng tôi không còn tạo ra các tác phẩm nghệ thuật thủ công nữa (có lẽ chúng tôi chưa bao giờ làm vậy?). Nhìn chung, chúng tôi hướng tới sự phát triển nhanh chóng và kết quả nhanh chóng. Cuối cùng, chúng ta quên mất điều quan trọng nhất: trang web và khách truy cập.

Bài đăng này dành cho những người có suy nghĩ đó; những người muốn trở thành nhà phát triển giỏi nhất có thể. Luôn đẩy bản thân lên một tầm cao mới để đạt được kết quả cuối cùng tốt hơn. Nếu bạn là nhà phát triển web có liên quan đến vấn đề này thì việc hiểu rõ hiệu suất là một trong những trụ cột quan trọng nhất cần xây dựng.

Đó là phần triết học của bài viết này. Tất nhiên là tôi hoàn toàn phớt lờ khía cạnh kinh doanh của thế giới CNTT. Tôi không nói về tiền bạc, thời gian hay phạm vi ở đây. Tôi đang nói về việc cải thiện kỹ năng phát triển của riêng bạn để bạn có thể sử dụng kiến ​​thức và kinh nghiệm đó trong các dự án thời gian rảnh rỗi hoặc cho khách hàng và công việc thực sự.

# Kiến thức cơ bản về web: HTML

Một trong những thành phần quan trọng để hiểu và cải thiện hiệu suất web là biết trình duyệt hiển thị HTML như thế nào. Có nhiều điều hơn bạn nghĩ và việc hiểu các bước này khiến bạn có lý do hoàn toàn khác về mã của riêng mình. Google có khóa học cấp tốc hay nhất về chủ đề này: https://developers.google.com/web/fundamentals/performance/, đặc biệt là phần “đường dẫn hiển thị quan trọng” đã mở rộng tầm mắt của tôi.

Một khái niệm quan trọng khác cần hiểu là các trang HTML tĩnh. Cuối cùng, chúng là những gì được phục vụ cho người dùng. Không cần phải tạo trang nhanh chóng trong khi người dùng đang chờ xem kết quả. Các trang web động lạm dụng thời gian của người dùng để dễ dàng phát triển. Bây giờ tôi không nói rằng các trang web động là xấu. Điều tôi muốn nói là mọi hệ thống động phải có sẵn công nghệ để loại trừ giai đoạn động khỏi chu trình yêu cầu/phản hồi. Thêm về chủ đề đó sau. Nếu bạn đang truy cập các trang web tĩnh thực sự, https://staticgen.com là nơi tốt để tìm công cụ phù hợp với nhu cầu của bạn.

Chuyển sang hình ảnh phản hồi: có thể là cách tối ưu hóa số một khi nói đến việc sử dụng băng thông. Thông số hình ảnh phản hồi được thiết kế để giải quyết vấn đề về hình ảnh lớn hoặc hiển thị các giải pháp chặn JavaScript. Nó hoàn toàn tương thích ngược (tôi đang nói với bạn Edge) và có cơ hội tốt để cải thiện thời gian tải trang web của bạn: https://Responseimages.org.

#Phát triển phụ trợ

Tôi đã đề cập đến các trang web động ở phần trước. Tất nhiên, chúng là thứ bắt buộc phải có trong web hiện đại; nhưng bạn nên suy nghĩ xem trang nào cần hiển thị mọi thứ một cách nhanh chóng và trang nào có thể được lưu vào bộ nhớ đệm. Có nhiều lớp bộ nhớ đệm có thể có ở phía máy chủ. Chúng ta sẽ thảo luận ví dụ. Bộ đệm Varnish sau trong bài viết này. Việc lưu mã phụ trợ vào bộ nhớ đệm sẽ phụ thuộc nhiều vào loại ngôn ngữ và khung công tác bạn đang sử dụng. Điều quan trọng nhất cần đề cập về bộ nhớ đệm là bạn không nên xem bộ nhớ đệm của mình như một lớp “trên cùng” của ứng dụng. Nó phải là một phần không thể thiếu trong tất cả mã bạn viết.

Là một nhà phát triển PHP, tôi đã quen với vòng đời yêu cầu/phản hồi nghiêm ngặt mà mọi ứng dụng web PHP đều trải qua. Ngoài ra còn có rất nhiều ngôn ngữ khác cung cấp logic tương tự cho các ứng dụng web. Cách tiếp cận này rất dễ hiểu, nhưng nó có nghĩa là ứng dụng phải được khởi động lại từ đầu cho mỗi yêu cầu. Các thư viện như ReactPHP hoặc AMP giải quyết vấn đề này bằng cách cho phép nhà phát triển xử lý nhiều yêu cầu từ một ứng dụng được khởi động duy nhất. Lúc đầu, các ứng dụng không đồng bộ và song song gây ra rất nhiều sự phức tạp và có thể khiến bạn rất khó hiểu. Nhưng nó rất có thể có nghĩa là thời gian phản hồi sẽ giảm rất nhiều.

# Phía máy chủ

Quay lại chủ đề về bộ nhớ đệm, có rất nhiều việc có thể được thực hiện ở phía máy chủ. Trước hết, có các tiêu đề bộ nhớ đệm mà bạn chắc chắn nên triển khai: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control.

Thứ hai, bạn nên phân phát nội dung đã sẵn sàng. Sử dụng CDN và Varnish trước máy chủ thực của bạn. Bằng cách này, bạn có thể phân phối hình ảnh, trang nội dung, v.v. ngay lập tức, đã được tạo trước đó. Một trong những mối nguy hiểm của việc sử dụng cái gọi là “proxy” như Varnish là nhiều nhà phát triển có thể coi đó là “lớp trên ứng dụng của riêng bạn”. Trên thực tế, bạn sẽ cần giao tiếp rất nhiều với Varnish từ trong ứng dụng của riêng bạn. Bạn có thể đọc thêm về Varnish tại đây: https://varnish-cache.org.

Lợi ích của máy chủ của riêng bạn? Của nó máy chủ của bạn. Bạn có quyền kiểm soát các tài nguyên được sử dụng và có sẵn. Đừng đặt thêm tải cho máy khách khi bạn có thể để máy chủ của mình xử lý việc đó. Tất nhiên đây là một cách suy nghĩ rất đơn giản về tài nguyên. Tuy nhiên, bạn luôn có thể nâng cấp phần cứng máy chủ của mình khi bạn không có quyền kiểm soát phần cứng mà máy khách đang sử dụng.

Và cuối cùng, nếu bạn chưa triển khai HTTP/2: hãy triển khai HTTP/2! Không chắc chắn lý do tại sao? Điều này có thể cho bạn ý tưởng: https://sitepoint.com/what-is-http2.

#Phát triển giao diện người dùng

Tuyên bố từ chối trách nhiệm: Tôi là một nhà phát triển web phụ trợ. Tôi đã viết và vẫn viết rất nhiều mã CSS và JavaScript, nhưng tôi không phải là người chuyên nghiệp khi nói đến phát triển web giao diện người dùng. Vì vậy, tôi sẽ chỉ sử dụng lẽ thường và lý luận để chia sẻ một số khái niệm về cải thiện hiệu suất.

Bạn nên nghĩ xem trang thực sự cần những tài nguyên nào. Nếu trang cụ thể đó chỉ cần 5 kilobyte trong số 100 kilobyte CSS thì đừng tải 95 kilobyte còn lại! Điều tương tự cũng xảy ra với JavaScript.

Ngoài ra, hãy nghĩ đến việc nội tuyến các tài nguyên quan trọng trong các trang HTML của bạn, ít nhất là khi việc đẩy máy chủ HTTP/2 chưa trở nên phổ biến.

Một nơi tốt để bắt đầu từ đây là blog của Tim Kadlec: https://timkadlec.com.

# Tóm tắt

  • Hãy nghĩ đến hiệu suất đầu tiên.
  • Hiểu cách HTML được tải và hiển thị.
  • Phục vụ nội dung đã sẵn sàng để được phục vụ.
  • Đừng lạm dụng thời gian của người dùng bằng cách hiển thị động khi không cần thiết.
  • Cải thiện chu trình yêu cầu/phản hồi phía máy chủ.
  • Đặt tải lên máy chủ của bạn chứ không phải máy khách.
  • Đừng xem bộ nhớ đệm như một lớp trên cùng mà là một phần tích hợp trong ứng dụng của bạn.
  • Đặt tiêu đề bộ đệm của trình duyệt, sử dụng CDN và xem Varnish.
  • Đừng tải tất cả CSS hoặc JS đã được rút gọn khi bạn chỉ cần 10% trong số đó trên trang đó.

Rất nhiều điều phải suy nghĩ. Đây là danh sách kiểm tra cá nhân của tôi mà tôi cố gắng ghi nhớ khi phát triển trang web, cả về mặt chuyên môn lẫn trong thời gian rảnh rỗi. Như tôi đã nói ở đầu bài viết này, bạn không nên luôn làm mọi thứ chỉ vì một lý do. Nhưng bạn nên hiểu những khái niệm này và biết khi nào nên sử dụng chúng. Bằng cách đó, bạn đang đóng góp cho trang web tốt hơn.



Trả lời