Optimization

Pagespeed 7: Tối ưu chuyên sâu – Các lưu ý khi cần Dev can thiệp mã nguồn

Ở tập trước mình có làm một bài dạng tổng kết lại các kiến thức cho dân không chuyên (non-tech) từ nhiều bài trước là "No-Code – Tối ưu website không cần can thiệp code". Tuần này mình sẽ chia sẻ thêm những mục mà các bạn cần phải nhờ Dev (người lập trình, phát triển website của bạn) hỗ trợ tối ưu thêm cho bạn.

Mục đích bài này là giúp bạn biết cách làm việc với Dev hiệu quả hơn, tiết kiệm thời gian hơn mà vẫn đáp ứng kì vọng so với điều kiện thực tế.

Khi nào thì cần nhờ Dev?

Trong điều kiện lý tưởng, mã nguồn website ổn, mình nhập liệu theo checklist ổn và tiêu chuẩn công nghệ không bao giờ thay đổi thì chắc chả bao giờ phải nhờ tới ai rồi ^^.

Mà thực tế thì không như vậy, Đời không như là mơ.. nên đời thường giết chết mông mơ... Nói chung sẽ có lúc bạn muốn tối ưu, nâng cấp và cũng sẽ có lúc bạn cần phải xây dựng cái mã nguồn hoàn toàn mới để website của mình.. bằng chị bằng em.

Mình tạm liệt kê ra vài ý để bạn tự nhận diện được thời điểm mình cần đi nhờ Dev:

  • Khi bạn đã tự làm hết các hạng mục tối ưu ở các tập trước rồi mà vẫn muốn tối ưu hơn nữa.
  • Khi bạn đọc tài liệu mà không thể hiểu nổi cả đám từ khóa quá thuần kĩ thuật.
  • Khi bạn không thể trực tiếp chỉnh sửa mã nguồn, hoặc đảm bảo chỉnh sửa xong mà không để lại hậu quả.
  • Khi Dev làm ra cái website cho bạn không thể tối ưu thêm và bạn.. cần tìm Dev khác.
  • Ban đầu mã nguồn chạy ngon lành, rồi bạn nhờ ai đó thêm tính năng mỗi chỗ một chút (thậm chí mỗi tính năng một Dev khác nhau nữa). Mã nguồn bạn bắt đầu có vấn đề và.. rất ít Dev dám đụng tới vì nó quá phức tạp.

Đại khái là bạn thấy bắt đầu ngoài tầm với và những gì bạn đang có rồi đó.

Bạn cần chuẩn bị những gì?

Như ở bài đầu tiên mình có nói, bạn phải biết mình thực sự muốn gì. Đi nhờ mà còn không xác định rõ mình nhờ gì thì hơi.. sai sai từ đầu rồi .

Mình thấy đa phần mọi người đều nói rất chung chung, dĩ nhiên khi đi hỏi thì mỗi Dev cũng sẽ trả lời chung chung như cách bạn hỏi.

Túm lại, bạn ít nhất nên cụ thể hóa bằng các gạch đầu dòng dạng như sau:

  • Đưa ra kì vọng bằng các con số cụ thể. Ví dụ: trang chủ load <3s, trang product <4s, thời gian hoàn thành N ngày, ngân sách XXX đồng..v.v…
  • Nêu ra được mục tiêu mình chính muốn đạt được sau khi tối ưu website. Ví dụ: để gia tăng trải nghiệm hoặc gia tăng tỉ lệ chốt đơn trên trang chi tiết sản phẩm.
  • Nếu có các mục tiêu phụ buộc phải có, bạn cũng nên nêu ra. Ý này thường bị bỏ qua vì quên hoặc.. không biết nè. Ví dụ: phải giữ các mã tracking, mã remarketing abc..v.v.. cho mục tiêu xyz nào đó.
  • Ngoài ra, bạn nên lưu ý các điều kiện ràng buộc khác như: giữ lại giao diện cũ, giữ lại tối thiểu N tính năng hiện có, đảm bảo các phần liên quan SEO đã có sau khi can thiệp..v.v..

Tùy vào nhu cầu, thời gian và ngân sách của bạn mà bạn có thể bổ sung vào yêu cầu ban đầu để mọi việc diễn ra thuận lợi và nhanh chóng hơn.

Với những yêu cầu càng cụ thể thì một Dev có kinh nghiệm sẽ dễ dàng đánh giá mức độ khả thi dựa trên các chỉ tiêu được đề ra ở trên.

Bạn sẽ nhận được phản hồi những gì từ Dev?

Mọi kì vọng, mục tiêu bạn đặt ra thường luôn có ràng buộc nhất định, vì vậy đa phần nó sẽ không bao giờ có thể đạt được 100% trong thực tế. Kinh nghiệm của mình là nếu Dev nào chưa hỏi hoặc hiểu rõ hết các mong muốn, ràng buộc của bạn mà gật đầu làm ngay thì thường là.. fail luôn.

Bình thường, họ sẽ phải dành kha khá thời gian (tùy độ phức tạp của mã nguồn website hiện tại) để đọc, phân tích sơ bộ rồi mới cho đánh giá mức độ khả thi được. Còn lại thì đi vào chi tiết triển khai vẫn phải mò mẫm, phân tích & đánh giá tiếp.

Tuy nhiên, đa phần đánh giá ban đầu thường sẽ như sau:

  • Trang T này xử lý 7 issues I xong sẽ nhanh lên được, nhưng chỉ được 80% vì vướng ràng buộc tính năng R.
  • Toàn trang có 5 mã nhúng M của bên thứ 3 (không can thiệp được) và có 2 mã chưa được tối ưu.
  • Ràng buộc tracking GA trên nền tảng này không thể tối ưu tải sau vì luôn buộc đặt trên đầu (thẻ head)
  • Giữ nguyên tính năng giao diện thì chỉ tối ưu được 70% kì vọng.
  • Đập đi làm lại mã nguồn thì có thể tối ưu được 95% tốc độ website, nhưng ngân sách đội lên x10 lần so với kì vọng.

Nói chung vẫn là câu "đời không như là mơ..".

Bản thân mình lúc đi thuê các bạn làm video cũng vậy, vừa muốn kịch bản hay, hiệu ứng bắt mắt, ứng dụng 3D model, chèn được thông điệp quảng cáo và phải sớm có sản phẩm trong 15 ngày tới mà.. giá cả phải chăng nữa (hehe.. mong muốn chính đáng mà).
Khi mình nhận được các option báo giá và thời gian từ họ xong, mình vẫn phải tự hỏi lại các kì vọng mình thực sự mong muốn ban đầu xem cái nào phù hợp nhất điều kiện hiện tại để chọn. Vậy nên mình mới rút kinh nghiệm và chia sẻ mục "chuẩn bị" ở trên cho bạn đó.

Nói đâu xa, vừa tháng rồi mình cực kì ngứa ngáy muốn tối ưu thêm tốc độ website trang chủ của mình lên 30% nữa.
Rồi nghĩ lại mục tiêu tháng này đang là tăng người dùng app hơn, kiếm thêm tí tiền nộp cho vợ.
Giờ mà dành thời gian cả tháng và mớ chi phí cho Dev tối ưu nữa thì chả được đồng nào, không khéo.. bị âm thì ra đường ở luôn.

Lan man hơi xa rồi, quay xe nàooo…

Những việc mình gợi ý ở trên chỉ giúp bạn giảm thiểu rủi ro và làm việc hiệu quả hơn với Dev dựa trên kinh nghiệm của mình thôi. Mình cũng chỉ là người trần mắt thịt nên không thể biết hết được.

Bài tới đây cũng hơi bị dài rồi, mọi người thấy mình có thiếu sót gì, hoặc có câu hỏi cứ gõ bên dưới, mình biết sẽ trả lời thêm và bổ sung vào bài viết nhé.

Chúc mọi người cuối tuần vui vẻ!

Thao Le

Share
Published by
Thao Le

Recent Posts

AWS #3 – Kinh nghiệm triển khai EC2

Trong phần trước, mình đã chia sẻ với mọi người những khó khăn khi team…

3 years ago

Microservices #4: Làm việc đa môi trường và sự chờ đợi của Frontend

Xin chào, tiếp tục loạt bài về trải nghiệm của mình trong việc xây dựng…

3 years ago

Frontend Du Ký S2E3 | Cross-platform Apps (phần 3): Có công mài sắt, có ngày release

Cắm đầu cắm cổ dọn dẹp deadline và dọn nhà trước Tết nên ngâm bài…

3 years ago

Front-end Engineer (Reactjs, Nextjs, TypeScript, Svelte, TailwindCSS..)

Nếu bạn yêu thích phát triển sản phẩm với nhiều thử thách và cơ hội…

3 years ago

AWS #2 – Vấn đề và giải pháp

Trong phần 1, mình đã giải thích lý do tại sao EGANY chọn AWS làm…

3 years ago

AWS #1 – Sự lựa chọn của EGANY

Trong giới công nghệ hiện nay, Amazon Web Service không còn là một cái gì…

3 years ago