Thứ Bảy, ngày 25 tháng 4 năm 2015

HTTP/2 là gì?

Nói ngắn gọn, HTTP/2 là phiên bản tiếp theo của chuẩn HTTP. Chuẩn HTTP là chuẩn định nghĩa truyền nhận dữ liệu trên internet, là cái mà bạn luôn thấy ở các địa chỉ trang web.

Chuẩn HTTP/2 này đang gần hoàn thành, nếu không có gì thay đổi thì khoảng tháng 8 năm 2015 sẽ hoàn tất, và việc tiếp theo là triển khai và viết tài liệu hướng dẫn.

Kể từ khi phát hành HTTP/1.1 tới nay đã hơn 15 năm, nhưng chưa có một cải tiến nào đáng kể trong thế giới internet thay đổi không ngừng. Nay, IETF HTTP Working Group đề xuất phiên bản tiếp theo của HTTP với nhiều cải tiến lớn. Rất nhiều cải tiến được lấy cảm hứng từ SPDY của Google. Tôi sẽ điểm qua một số điểm nhấn chính đáng mong đợi.

1. HTTP API như cũ

Đây là điểm lợi đầu tiên: Developer sẽ không cần sửa đổi nhiều ứng dụng/server của họ để tương thích.

HTTP/2 không đưa ra các sự thay đổi API hay việc phải thêm một vài API để nó làm việc tốt. Việc này giúp việc triển khai HTTP/2 dễ dàng và nhanh chóng hơn.

Tất nhiên, nó sẽ có một vài API mới hoàn toàn, và dùng cho một vài mục đích chuyên biệt của HTTP/2 mà không ảnh hưởng đến API hiện có của HTTP/1.1

2. Ít tốn chi phí request hơn

Có một triết lý để tăng performance, đó là giảm số lượng request, và chúng ta đã biết rất nhiều kỹ thuật như concatenation (gộp nhiều file thành một), spriting (ghép nhiều icon nhỏ thành một hình), hay inlining (đưa JS nhỏ vào file HTML). Tất cả đều là kỹ thuật "hack", để giảm số lượng request khi truy cập một trang web.

Tại sao phải giảm số lượng request? Vì một request sẽ tốn chi phí DNS Lookup, rồi bắt tay, rồi truyền nhận header, mở connection và mở port, sau đó mới đến nội dung thật sự. Khi giảm số lượng request thì nội dung sẽ được gộp lại, nhưng các chi phí còn lại sẽ chỉ tốn 1 lần. Thêm một vấn đề nữa là các request sẽ đợi lẫn nhau, khi hoàn thành request thứ nhất thì mới bắt đầu request thứ 2, và nếu request thứ nhất quá lâu thì cũng sẽ ảnh hưởng đến request thứ 2. Chúng ta cũng có hướng đến cải thiện là thay đổi trình tự request, ưu tiên những cái quan trọng và nhỏ gọn hơn. Đó là cách làm hiện nay, tuy nhiên, phải sửa lại code khá nhiều.

HTTP/2 giới thiệu một cách tiếp cận tốt hơn. Đó là cho phép nhiều request khác nhau (đến từ một domain), có thể request đan xen nhau, và như thế có thể truyền nhận dữ liệu đồng thời.

Thậm chí, HTTP/2 còn có thể đưa thêm một số tuỳ chọn để nén header, giúp lượng dữ liệu truyền còn nhỏ gọn hơn.

3. Thân thiện với network và server

HTTP/2 được thiết kế để có thể mở ít connection hơn. Nói dễ hiểu, nếu trước đây một lượt truy cập vào một trang cần mở 12 connection thì nay chỉ còn lại 3 connection, như vậy server có thể phục vụ lượng truy cập gấp 4 lần mà không cần làm gì cả.

Thêm nữa, với việc hỗ trợ nén từ header đến content, băng thông sẽ giảm đáng kể. Việc này có lợi cho cả server lẫn người dùng, vốn có xu hướng sử dụng di động nhiều hơn.

4. Cache pushing

Trong tất cả các điểm mới, đây là điểm tôi bất ngờ và thú vị nhất.

Cache là gì? Cache là một bản sao của một file trên server, khi lần đầu truy cập nó sẽ được lưu vào máy người dùng, và ở lần truy cập tiếp theo, nó sẽ được sử dụng mà không cần request lên server để lấy lại.

Vậy còn Cache pushing? Nói một cách dễ hiểu: Các bản sao này được gửi về client (máy người dùng) trước cả khi client request.

Kỹ thuật này cho phép server bắt đầu chuẩn bị gửi các file CSS, JS, hình ảnh,... ngay khi client request file HTML đầu tiên, và gửi về client trong khi client đang parse HTML và xác định những file cần request tiếp theo.

Tất nhiên, nếu client không muốn push nội dung về thì có thể nói "không" bằng RST_STREAM (tôi sẽ đề cập ở đoạn tiếp theo).

5. Có thể dừng request lại

Với HTTP/1.x nếu muốn dừng request, client có thể đóng connection. Như thế sẽ không nhận response từ server nữa.

Nhưng, đóng connection không có nghĩa là server và network sẽ đóng, mà vẫn giữ đến khi gửi response về tới client thì thấy đã đóng rồi. Như vậy sẽ khiến lãng phí không nhỏ cho network và server. Thêm nữa, việc mở connection cần thực hiện bắt tay (handshake) mà việc này lại tốn tài nguyên để xử lý ở client và server.

Thực tế việc dừng request rất thường xuyên xảy ra. Khi bạn đang load trang web này và muốn reload, hay chuyển sang trang web khác, hay đơn giản là đóng tab lại,... Và mỗi lần như vậy lại tốn một lượng tài nguyên nhất định, sẽ khiến cho tổng cộng bị tốn khá nhiều tài nguyên.

HTTP/2 hỗ trợ RST_STREAM frame như là một cách để người dùng có thể làm điều này mà không tốn nhiều tài nguyên.

6. Mã hoá nhiều hơn

HTTP/2 không bắt buộc phải sử dụng TLS (một dạng chuẩn của SSL), nhưng performance đã được cải thiện rất nhiều khi sử dụng TLS, vì vậy chúng ta không còn lo ngại việc mã hoá TLS gây chậm trang web nữa.

Tuy là vậy, nhưng cả Chrome và Firefox đều tuyên bố chỉ hỗ trợ HTTP/2 chung với TLS (có nghĩa là nếu server muốn sử dụng HTTP/2 cho người dùng 2 trình duyệt này, thì họ phải hỗ trợ TLS). Phương án này không tốt tẹo nào nếu nhìn từ góc độ nhà cung cấp website, tuy nhiên lại bảo vệ tối đa cho người sử dụng. Và như vậy webmaster phải lựa chọn giữa HTTP/1.x chậm mà không cần TLS, với một HTTP/2 nhanh-tốt hơn mà phải chi tiền để mua chứng thực TLS.

Dù sao thì với việc triển khai HTTP/2, mọi người dùng trên thế giới sẽ tin tưởng rằng họ đang kết nối internet an toàn hơn rất nhiều.

Câu hỏi nhỏ là: Tại sao phải "force" như vậy? Đơn giản là vì mỗi lần triển khai HTTP phiên bản mới sẽ mất rất nhiều thời gian và công sức, cho nên nếu đã làm rồi thì làm cho "triệt để" luôn.

7. Nói không với text

HTTP/1 được thiết kế ra đầu tiên cho việc truyền tải dữ liệu HTML, và như vậy nó hỗ trợ text làm nền tảng. Sau đó thế giới cần gửi binary (ví dụ như hình ảnh, phim, zip file,...), và người ta phải xử lý binary. Tóm lại là HTTP/1.x đang sử dụng 2 phương cách để truyền tải là binary protocol và text protocol.

Với HTTP/2, tất cả đều phải là binary. Tại sao?

Ngoài những lý do như binary thì gần với mã máy, thân thiện với network,... thì có một lý do lớn là dễ xử lý hơn.

Với dạng text, nếu bạn muốn gửi ký hiệu "xuống hàng", bạn phải gửi "\n" hoặc "\r\n" tuỳ hệ điều hành. Còn nếu bạn muốn gửi ký hiệu "\n" (không phải xuống hàng mà là text), thì phải gửi "\\n". Câu chuyện này khá là phức tạp, với rất nhiều trường hợp khác nhau mà bạn phải xử lý. Tất nhiên, có rất nhiều thư viện xử lý giúp, nhưng nếu bạn làm một trình duyệt mới, hay một ngôn ngữ lập trình mới, thì phải xử lý từ đầu. Khá bất tiện...

Rồi còn chuyện kết thúc nữa, hiện không dưới 3 cách để báo cho server biết là đã kết thúc dữ liệu gửi đi. Như vậy độ phức tạp xử lý lại nhiều thêm nữa. Và còn dễ bị tấn công theo kiểu chèn thêm vào message gửi qua lại (response splitting attack).

Với dạng binary, tất cả đều quy về một chuẩn chung, giúp cho việc mã hoá, giải mã và gửi đi được thống nhất. Không cần phải lo lắng về các ký tự không có trên bàn phím hoặc kết thúc message nữa.

Thêm một lý do nữa để HTTP/2 phải sử dụng binary, đó là vì, như đã nói ở phần trên, HTTP/2 có thể xử lý song song nhiều request trên cùng một connection, nên việc sử dụng text sẽ không thể tách và ghép các message được.

8. Phải một thời gian sau mới đúng

HTTP/2 không phải là thứ muốn có là có liền được, mọi thứ không đơn giản như là chỉ cần gắn nó vào là xong.

Hướng tiếp cận của HTTP/2 là loại bỏ những thứ không cần thiết để tối ưu hiệu suất, việc này đồng nghĩa với việc cả server và client (các trình duyệt) đều phải thay đổi để hỗ trợ. Việc này cần thời gian, và mỗi trình duyệt lại có lộ trình riêng để hỗ trợ.

Điều khiến nhiều người bi quan nhất là rất nhiều trình duyệt và server có "hard code" theo chuẩn HTTP/1.x, và không hề có dự định sẽ hỗ trợ các chuẩn HTTP mới ở tương lai. Việc chuyển dịch sang chuẩn mới sẽ tốn một chi phí khổng lồ. Tuy là như thế, nhưng với xu hướng phát triển toàn cầu, tất cả các trình duyệt và server đều sẽ hỗ trợ để phục vụ người dùng tốt hơn.

Thậm chí, các nhà viết chuẩn của IETF còn "mơ mộng" hơn thế, khi bắt đầu đầu tư thời gian và công sức vào một chuẩn mới thay thế TCP hiện tại. Với kỳ vọng performance sẽ tốt hơn nữa. Tuy nhiên, còn quá sớm để đề cập tới TCP, vì hiện tại vẫn chưa ai nghĩ rằng để cải thiện chỉ cần một thay đổi nhỏ (tweak) giống như SPDY đã làm, hay đưa ra cải tiến về nền tảng cho một chuẩn mới như HTTP/2.

9. HTTP/3 và xa hơn nữa

HTTP/1.1 đã tồn tại hơn 15 năm, HTTP/2 thì sắp hoàn thành đặc tả, vậy tại sao chúng ta không bắt đầu suy nghĩ đến HTTP/3?

Lý do lớn nhất nằm ở chỗ việc triển khai HTTP/2 đã gặp rất nhiều khó khăn rồi. Rất nhiều phần mềm, ứng dụng chưa hỗ trợ chuyển đổi, thậm chí chúng còn nghĩ rằng HTTP/1 không bao giờ thay đổi.

Do đó, nếu việc chuyển đổi lên HTTP/2 mà không gặp vấn đề gì lớn, thì khi đó việc nâng lên version tiếp theo như HTTP/3 sẽ không gặp vấn đề gì. Còn nếu chỉ mới lên HTTP/2 mà đã nhiều vấn đề, thì còn quá sớm để nói về HTTP/3, vì chuyện đáng quan tâm nhất là nâng cấp lên HTTP/2 mà.

Và tất nhiên, không ai biết HTTP/3 sẽ có cái gì. HTTP/2 được lấy cảm hứng rất nhiều từ phương thức SPDY của Google, và SPDY lại dựa trên trải nghiệm thật trên HTTP/1 rồi cải tiến nó. Nếu thế thì sau khi HTTP/2 được triển khai rộng khắp sẽ có nhiều hướng để cải thiện nó lên, để rồi sẽ thống nhất về một mối lần nữa.

Trong khi chờ tới ngày đó, thì chúng ta sẽ tiếp tục hướng tới HTTP/2 và tận dụng triệt để sức mạnh của nó.

--------







Chủ Nhật, ngày 15 tháng 3 năm 2015

Để viết blog hiệu quả

Tôi viết bài này để chia sẻ kinh nghiệm của tôi về việc viết blog. Cách đây không lâu, có người nói rằng tôi thường hay viết blog, và viết cũng khá tốt, và người ta hỏi tôi về phương pháp làm sao viết hiệu quả, vì người ta cũng cố gắng viết nhưng hầu hết là không publish ra được. Người ta hỏi tôi chỉ bởi vì tôi đã viết khá nhiều blog và cũng đã viết khá nhiều bài.

Gần đây thì có một vài người đặt vấn đề này lại với tôi. Tôi nghĩ tôi có thể chia sẻ trên blog của mình để những người khác nữa có thể tìm hiểu và tham khảo cách tiếp cận của tôi. Đôi khi giúp ích cho một ai đó.

0. Trước khi bắt đầu

Khái niệm viết blog mà tôi đề cập xuyên suốt bài này là để chỉ những bài viết cá nhân dùng để chia sẻ kinh nghiệm hoặc trải nghiệm cá nhân, không phải các bài viết để quảng bá hoặc tin tức hoặc các nghiên khảo, nghiên cứu, luận văn này kia. Tất nhiên, mọi người có thể sử dụng những kinh nghiệm viết bài của tôi để cải thiện mọi loại bài viết, nhưng tôi không khẳng định nó có áp dụng được.

Và, những kinh nghiệm này là kinh nghiệm cá nhân của tôi, theo cách nhìn nhận của tôi và theo văn phong của tôi mà thôi.

1. Hãy biết bạn cần gì

Hoặc là bạn đã từng cần gì.

Khi bạn cần một thông tin gì đó, bạn sẽ lùng sục về nó trên internet. Câu chuyện là: Sẽ có rất nhiều người có nhu cầu giống như bạn, và họ cũng sẽ lùng sục giống như bạn đã làm.

Vậy, thay vì nhức óc tìm một đề tài hoặc một kinh nghiệm thú vị của bạn, bạn hãy bắt đầu bằng những kinh nghiệm mà bạn rút ra sau mỗi lần "lùng sục" ấy. Việc này sẽ giúp cho bạn hiểu thấu đáo vấn đề hơn, và giúp cho rất nhiều người khác nhanh chóng tìm lấy thông tin họ cần.

2. Đừng quá lo lắng về người đọc sẽ nghĩ gì

Thực tế là sẽ chẳng có nhiều người đọc đâu. Hoặc giả họ có đọc, họ cũng không nghĩ gì nhiều.

Đôi lúc, khi bạn viết, bạn nghĩ rằng đây là một đề tài nghiên cứu thú vị của mình, và người đọc sẽ lấy làm ngạc nhiên khi bạn trình bày thông tin như vậy. Nếu bạn có suy nghĩ và viết vì mục đích như vậy, tôi cho là khá tốt. Vì khi đó bạn thật sự nghiêm túc với bài viết và các suy nghĩ của mình, nhưng nếu điều đó khiến cho bạn phải trau chuốt câu chữ, ý và lời thì tôi nghĩ bạn đã đi quá xa.

Bây giờ, bạn đóng vai trò người đọc xem nào. Bạn cần gì nào? À, cái mà chúng ta cần mỗi lần đọc bài người khác là: lướt nhanh qua, nắm các ý chính, và hết. Người đọc của bạn cũng sẽ như vậy. Họ sẽ đọc một lượt, nắm các ý chính và họ sẽ không đọc lại lần nào nữa. Điều phũ phàng hơn là, 80% người đọc sẽ quên mất ý chính đó vào ngày hôm sau.

Bạn, nếu đã viết bài thì hãy quan tâm tới người đọc, cung cấp cho họ thông tin mà họ cần, nhưng đừng quá lo lắng về người đọc.

3. Hãy thoải mái viết theo cách nghĩ của mình

Không có một bài văn mẫu nào, không có cách viết blog chuẩn nào, cũng không có ai ràng buộc bạn phải viết về đề tài bạn không thích.

Đó là blog của bạn.

Khác với các bài văn thời đi học, chúng ta phải viết có các ý chính thế này thế kia, rồi phải bao gồm mở bài - thân bài - kết bài này nọ. Hãy dành cho blog của bạn một không gian riêng, độc lập, và là nơi bạn trải lòng mình ra, chia sẻ những hiểu biết của mình. Hết.

Đôi khi, blog chỉ gồm vài dòng, nhưng nó lại có ý nghĩa lưu lại một khoảng khắc trong cuộc đời của bạn, và nó đã trở thành một bài blog có ý nghĩa với bạn rồi.

Rất nhiều người nghĩ: Họ viết bài là để PR cho bản thân. Xin thưa rằng, sẽ chẳng ai quan tâm đến bạn là ai trên blog, người ta chỉ quan tâm đến blog của bạn vì ở đó có vài thông tin gì đó mà họ cần. Những người quan tâm đến bạn chỉ là những người bạn ngoài đời của bạn, họ quen biết bạn, và họ biết bạn có viết bài này bài nọ. Nhưng họ lại không thật sự quan tâm đến bạn đã viết cái gì. Vậy có lợi ích PR gì ở đây không? Hoàn toàn không. Người đã biết bạn thì họ không quan tâm bạn viết cái giống gì, còn người không biết bạn thì họ chả cần biết bạn là ai.

4. Viết liền, kẻo quên

Ý tưởng hoặc kinh nghiệm chỉ đến trong một thời gian ngắn, nếu bạn không viết liền, ắt sẽ quên.

Đôi khi, nó còn liên quan tới cảm xúc. Bạn có ý tưởng, nhưng ngày hôm sau nó sẽ nhạt dần, đến nỗi bạn sẽ không còn tâm trí đâu mà viết tiếp nữa.

Tuy nhiên, thường là bạn không có thời gian để ngay lúc có ý tưởng là có thể viết ngay. Vậy nên cứ note các ý chính lại, để khi nào có thời gian thì khai triển nó ra. Nhưng điều cốt yếu là phải bắt đầu ngay khi có thời gian, bạn để qua ngày hôm sau là mọi thứ nhạt dần ngay. Phải là một ý bạn rất tâm đắc bạn mới có thể viết vào ngày hôm sau, còn không thì bạn sẽ nản khi viết.

5. Đừng chú tâm tới SEO này nọ

Việc này thật ra cũng tốt thôi, nó sẽ giúp cho người khác có cơ hội tìm thấy bài viết của bạn dễ dàng hơn. Nhưng đừng quá chú tâm vào nó, mất nhiều thời gian, mà đôi khi lại phản tác dụng.

Điều bạn cần quan tâm nhiều nhất là: Duy trì lượng bài viết của mình thường xuyên, và nâng cao khả năng viết bài của mình.

Có 2 hướng để nâng cao: 1- Viết rõ ràng và dễ hiểu hơn, 2- Rút ngắn thời gian từ ý tưởng thành bài viết hoàn chỉnh.

Nếu bạn viết tốt, người ta sẽ tìm đến bạn, và nếu bạn luôn cung cấp cho người ta thông tin có ích, người ta sẽ để ý hơn trang web của bạn. Còn nếu bạn viết chưa tốt, thì dù cho bạn có cò kéo thế nào cũng không xong, đôi khi còn bị mấy cái search engine đánh giá thấp.

Hãy viết blog trên các công cụ nổi tiếng như Wordpress, Blogger, Drupal,... Và yên tâm rằng các công cụ này có sẵn các hình thức SEO mặc định rồi, nó quá đủ cho nhu cầu của bạn.

Một phút dành cho quảng cáo

Tôi đã từng viết nhiều blog như: http://tuoilapnghiep.kimkha.com/, http://tuoihaimuoi.kimkha.com/, http://think.kimkha.com/

Thứ Bảy, ngày 14 tháng 3 năm 2015

Note: Tài khoản Viettel ADSL/FTTH cho thanh toán online

Bài viết ngắn này chỉ dùng để note lại và là guide cho những người chưa biết.

Bạn nào đã từng thanh toán hoá đơn trên Internet Banking chắc chắn biết những gì chúng ta cần là thông tin tài khoản (còn được gọi là mã khách hàng, hoặc số thuê bao). Để thanh toán bằng Internet banking, trước hết bạn phải có tài khoản đăng nhập vào dịch vụ Internet Banking của ngân hàng của bạn. Với điều kiện ngân hàng của bạn hỗ trợ dịch vụ Thanh toán hoá đơn ADSL của Viettel mới được.

Mặc dù bạn đang dùng cáp quang (FTTH) nhưng khi thanh toán bạn vẫn phải chọn dịch vụ là Thanh toán ADSL, với đúng nhà cung cấp là Viettel (có nhiều tỉnh thành, và bạn phải chọn đúng).

Phần gian khó nhất là mã khách hàng. Tại sao? Bởi vì nhà mạng Viettel cung cấp cho bạn một lô các số và mã. Lần đầu tiên, tôi thật sự thấy khó khăn vì không biết nhập cái nào, phải nhập từng cái một. Và giờ tôi có thể khẳng định rằng, mã khách hàng có định dạng: ****_ftth_****

Hằng tháng, Viettel sẽ gửi tin nhắn đến nhắc bạn đóng tiền, và trong tin nhắn có mã này với tên số thuê bao, và vài thông tin khác, nhưng bạn chỉ cần chú tâm đến mã này thôi. Tất nhiên, trong Biên bản nghiệm thu cũng có thông tin này.

Một điểm cần lưu ý là: Vừa rồi tôi có thử thanh toán bằng Eximbank, tuy nhiên, khi nhập mã này vô thì nó bảo "Mã khách hàng không đúng". Tôi khẳng định rằng đó không phải là lỗi của bạn. Nếu bạn thanh toán bằng Vietcombank hoặc ngân hàng khác, bạn sẽ thấy ở màn hình xác nhận, thông tin người chủ hợp đồng và địa chỉ không có, nhưng số tiền thì đúng. Trường hợp này là do API bên Viettel không trả thông tin trên, nhưng bên Eximbank cần nó để xác nhận là đúng dữ liệu.

Anyway, tóm lại là khi bạn nhập đúng mã khách hàng mà không được thì hãy sử dụng ngân hàng khác để thanh toán, thay vì mất thời gian loay hoay với nó.

Danh sách các ngân hàng hỗ trợ thanh toán cho Viettel (chỉ là danh sách có hỗ trợ, còn thực sự thanh toán có được hay không thì mình không khẳng định):

  • Vietcombank
  • BIDV
  • Techcombank
  • VietinBank
  • HDBank
  • AgriBank
  • Sacombank
  • SaigonBank
  • NamABank
  • PGBank
  • GPBank
  • ACB
  • BacABank
  • Eximbank
  • MaritimeBank
  • SeABank
  • TienPhongBank
  • VIB
  • VietABank
  • VPBank
  • Navibank
  • OceanBank
  • MB
  • OCB

Tái bút: Nhiều người nói thanh toán online không đảm bảo, nhưng tới giờ tôi vẫn sử dụng tốt, và chưa một lần bị mất tiền vô ích. Tôi đã thanh toán điện thoại, ADSL, tiền điện và cả tiền nước nữa.

Thứ Hai, ngày 09 tháng 3 năm 2015

TLDR - Cải thiện tốc độ tải trang web?

Điều đầu tiên bạn cần nhớ: Hãy luôn kiểm tra các chỉ số.

Chúng ta có rất nhiều công cụ để đo lường về tốc độ tải trang, mà tôi thì khá thích sử dụng PageSpeed Insight của Google. Và tất nhiên là còn rất nhiều công cụ khác mà bạn có thể tìm kiếm trên internet.

Hãy thử test xem website của bạn được bao nhiêu điểm?

Action 1: Hãy sử dụng reverse proxy server

Tôi khuyên mọi người hãy sử dụng các reverse proxy server như nginx. Đôi khi chỉ cần cài đặt, cấu hình mặc định của nginx đã giúp bạn cải thiện một ít rồi.

Sau đó, hãy tiếp tục cài đặt những thứ sau:
  1. Cache-Control: Khai báo thêm header này sẽ giúp browser của người dùng lấy bản cache thay vì request lên server, đỡ thời gian chờ rất nhiều.
  2. GZip: Config này giúp response HTML, JS và CSS được nén lại đáng kể.
  3. Nginx cache: Các resource tĩnh (hình ảnh, JS, CSS) nên được cache trên RAM của nginx server.
  4. ...

Action 2: Sử dụng hình ảnh hiệu quả hơn

Có 2 lỗi mà mọi người hay mắc phải:
  1. Kích thước hình ảnh quá to so với cần thiết để hiển thị
  2. Chưa làm lossless optimize để giảm dung lượng mà không giảm chất lượng

Về kích thước hình ảnh, nếu trang web của bạn chỉ support máy tính (không support mobile), bạn chỉ cần hình ảnh đúng kích thước khi hiển thị. Tuy nhiên, ngày nay việc support mobile đang dần trở nên phổ biến hơn, do đó bạn cũng nên chuẩn bị ngay từ bây giờ.

Với mobile, kích thước hình ảnh chỉ nên gấp đôi kích thước hiển thị. Thấp hơn, bạn sẽ thấy răng cưa. Còn cao hơn, dung lượng sẽ phình lên mà không có sự khác biệt.

Sau khi xem xét kích thước hình ảnh, bạn hãy thực hiện optimize. Tool rất hiệu quả là TinyPNG có thể optimize hình PNG và JPG. Lưu ý rằng bạn chỉ nên optimize 1 lần mà thôi, thực hiện optimize 2 lần có thể khiến chất lượng bị giảm xuống. Bạn nào thích dùng command line để thực hiện hàng loạt thì tham khảo tool pngquant (đây là bộ core của TinyPNG).

Action 3: Sử dụng server hiệu quả hơn

Đây là vấn đề sau cùng khi response từ trang web của bạn quá chậm. Hãy xem xét nên chuyển server mới hay không, thuê dịch vụ mới chẳng hạn.

Nên biết rằng, nếu hosting của bạn nằm quá xa so với người dùng mục tiêu của bạn, họ sẽ vào trang web của bạn rất chậm. Do vậy, khi thuê hosting bạn phải thuê những hosting gần với thị trường mục tiêu của mình. Trang web cho người VN thì nên hosting ở VN hoặc xa lắm là Hong Kong hoặc Singapore.

Việc tối ưu tốc độ xử lý trên server cũng là một yếu tố rất quan trọng. Và hãy tìm cách định lượng con số này. Tốc độ tốt nên <100ms cho một request bất kỳ, và sẽ rất tuyệt nếu thời gian xử lý <30ms.

Note

Bạn sẽ gặp ở đâu đó, ai đó bảo bạn nên làm cái này cái kia. Ví dụ: đặt hình ảnh ở cookieless domain, sử dụng CDN,... Tôi thì khuyên bạn nên thực hiện 3 điều trên trước khi cân nhắc tới các phương án khác. Bởi vì 3 điều trên dễ làm và ít tốn chi phí hơn cả.

Tái bút: Hầu hết mọi trang web chuyên nghiệp đều thoả mãn cả. Tôi viết bài này chỉ dành cho những người mới tìm hiểu thôi. ^_^

Thứ Năm, ngày 23 tháng 10 năm 2014

Vài yếu tố liên quan đến doanh thu của game


Bạn có một ý tưởng tốt. Bạn đã viết ra một game hay. Và giờ bạn muốn có chút doanh thu từ nó. Không ai cấm bạn cả...

Ơ, nhưng mà thế nào là một game hay? Có rất nhiều tiêu chí để đánh giá, nhưng một tiêu chí đo lường phổ biến nhất là: Số người chơi (unique user) và thời gian người ta chơi (spent time). Tạm thời chúng ta chấp nhận điều này, để tôi đi vào điều chính.

Thứ Bảy, ngày 18 tháng 10 năm 2014

So sánh HTML5 Game Engines

 Xu hướng ngày nay, nhiều người đang tìm kiếm một game engine phù hợp với nhu cầu để thực hiện các dự bạn cho mình. Bài viết này đánh giá một cách sơ bộ các game engine viết thuần bằng JavaScript và HTML5, để có một hướng đi mới khác với nhưng game engine nổi tiếng hiện nay.
Bảng đánh giá này chỉ dựa trên documents của các engine, hoặc đọc sơ qua source code, không phải là bản đánh giá chi tiết.
Bảng đánh giá này được viết khá cũ, ngày 30 tháng 11 năm 2014, nên có thể có nhiều thay đổi. Tôi post lại nhằm mục đích tham khảo.

Thứ Hai, ngày 13 tháng 10 năm 2014

Bộ gõ Tiếng Việt trên Chrome

Hiện nay, trình duyệt Chrome đã trở nên phổ biến, hơn nữa một số nơi bắt đầu sử dụng Chrome OS nhiều hơn. Và trình duyệt này mạnh mẽ với các extension viết bằng JavaScript.

Nắm bắt nhu cầu của một số người Việt Nam, muốn sử dụng một bộ gõ tiếng Việt trên Chrome và Chrome OS, cách đây không lâu tôi có viết extension AVIM for Vietnamese, để đáp ứng nhu cầu này.


Biểu mẫu liên hệ

Tên

Email *

Thông báo *