Mình gặp tình huống này khá thường xuyên trong các chiến dịch. Trang mở trên máy tính rất nhanh, nhưng khách đến từ quảng cáo trên điện thoại lại phải chờ khá lâu. Lần đầu nhìn số liệu, đội chạy quảng cáo thường đổ lỗi cho chiến dịch. Thế nhưng nguyên nhân hay nằm ở chính trang đích. Bài này đi thẳng vào những lý do khiến tốc độ tải trang landing page chậm trên di động, kèm thứ tự kiểm tra để bạn không sửa nhầm chỗ.
Vì sao máy tính nhanh mà điện thoại lại chậm?
Phần lớn lượt truy cập từ quảng cáo hiện nay đến từ điện thoại. Mạng di động thì lúc mạnh lúc yếu, nhất là khi người dùng đang di chuyển hoặc ở xa trung tâm thành phố. Cùng một trang, đường truyền khác nhau sẽ cho ra trải nghiệm khác hẳn.
Máy tính văn phòng thì khác. Băng thông lớn, CPU mạnh, nên mọi lỗi tối ưu đều bị che đi. Một trang nặng 8 MB vẫn mở gần như tức thì trên màn hình lớn. Cùng trang đó trên chiếc điện thoại tầm trung có thể đứng hình vài giây trước khi nội dung xuất hiện. Vì vậy mình luôn kiểm tra trên thiết bị thật, không chỉ nhìn bằng máy văn phòng.
Hậu quả khá rõ ràng. Khách thiếu kiên nhẫn sẽ thoát trang, tỷ lệ thoát tăng lên. Bạn vẫn trả tiền cho từng lượt click, nên chi phí trên mỗi lead bị đẩy lên mà không biết nguyên nhân nằm ở đâu.
Đo tốc độ đúng cách trước khi sửa
Trước khi chỉnh sửa, cần biết trang đang chậm ở đâu. Đừng sửa theo cảm tính. Mình thường dùng PageSpeed Insights và Chrome DevTools ở chế độ mô phỏng điện thoại. Hai công cụ này giả lập thiết bị di động cùng đường truyền yếu, nên kết quả sát trải nghiệm thật hơn nhiều so với việc mở trang trên máy văn phòng.
Đừng chỉ nhìn điểm tổng. Đó là con số gộp, nhìn vào khó biết nên sửa phần nào. Hãy ưu tiên ba chỉ số. LCP cho biết nội dung lớn nhất hiện ra nhanh hay chậm. CLS cho biết trang có bị nhảy bố cục khi đang tải hay không. TBT cho biết trang bị khóa để xử lý mã trong bao lâu. Nói đơn giản, LCP trả lời câu hỏi khách có thấy trang đã hiện chưa, còn TBT trả lời khách có bấm được hay không.
Mình thường đo ba lần, vào khung giờ cao điểm buổi tối. Một lần đo đơn lẻ rất dễ sai, vì lúc đó mạng có thể đang nghẽn hoặc đang rảnh. Ba lần cho một bộ số đáng tin hơn để so sánh trước và sau khi sửa.
Thủ phạm số một: ảnh nặng và sai kích thước
Trong gần như mọi dự án chậm mà mình từng xử lý, ảnh luôn là lỗi đầu tiên. Một ảnh hero nặng từ 3 đến 5 MB là chuyện rất phổ biến. Ảnh thường được xuất theo độ phân giải màn hình máy tính, rồi bị đẩy nguyên xi lên điện thoại. Khách trên di động không cần một tấm ảnh 4000 pixel chỉ để xem sản phẩm.
Cách xử lý gồm ba việc. Thứ nhất, chuyển sang WebP hoặc AVIF, dung lượng thường giảm rõ rệt so với JPG mà mắt thường khó nhận ra khác biệt. Thứ hai, chọn kích thước vừa với khung hiển thị trên điện thoại. Không có lý do gì để tải ảnh 4000 pixel cho một khung chỉ 400 pixel. Thứ ba, bật lazy-load cho các ảnh nằm dưới màn hình đầu tiên, để chúng chỉ tải khi khách cuộn tới.
Thủ phạm số hai: script bên thứ ba chặn việc hiển thị
Đây là lỗi mà người làm chiến dịch hay vô tình tạo ra nhất. Mỗi mã theo dõi, chatbot, bộ đếm hay widget đều thêm một yêu cầu mạng. Mỗi yêu cầu phải chờ, và nhiều script còn chặn việc vẽ trang cho tới khi chúng chạy xong.
Mở tab Network trong DevTools để xem script nào chiếm nhiều thời gian chờ nhất. Thường bạn sẽ thấy vài thẻ quảng cáo cũ, một công cụ thử nghiệm đã tắt từ lâu, hoặc một widget chat không còn ai dùng. Những thứ đó nên gỡ hẳn. Phần còn lại, đặc biệt là các script không thiết yếu, nên được tải sau khi trang đã hiện ra.
Có một lưu ý quan trọng: đừng gỡ mã theo dõi chuyển đổi của quảng cáo. Hãy tải nó muộn hơn, rồi kiểm tra lại xem sự kiện vẫn được ghi nhận đầy đủ hay không. Mất dữ liệu chuyển đổi còn tốn kém hơn nhiều so với vài trăm mili-giây chờ tải.
Thủ phạm số ba: hosting phản hồi chậm
Trước khi trình duyệt tải được ảnh hay script, máy chủ phải phản hồi trước. Chỉ số đo điều này gọi là TTFB, tức thời gian từ lúc yêu cầu được gửi đi cho tới khi nhận được byte đầu tiên. Nếu TTFB vượt 600 ms, đó là tín hiệu bạn nên xem lại hosting.
Hosting chia sẻ giá rẻ thường có rất nhiều website dùng chung một máy chủ. Vào giờ cao điểm, tài nguyên bị chia nhỏ, và trang của bạn phản hồi chậm dù bản thân nó không nặng. Khách ở các tỉnh xa, cách máy chủ hàng nghìn cây số, chịu thiệt nhiều hơn cả. Trong trường hợp này, bạn có thể tham khảo thêm landing page là gì và khi nào cần làm để hiểu rõ hơn vì sao một trang đơn giản vẫn cần hạ tầng ổn định.
Hai việc giúp ích rõ rệt. Một là bật CDN, tức mạng phân phối nội dung, để một bản sao của trang nằm gần khách hơn. Hai là bật nén GZIP hoặc Brotli để file truyền đi nhỏ hơn. Mình đã thấy nhiều trường hợp thời gian tải ở các tỉnh giảm mạnh chỉ nhờ hai thay đổi này.
Làm theo thứ tự nào để không tốn tiền oan?
Mình luôn kiểm tra theo thứ tự từ rẻ đến tốn kém. Phần lớn ca chậm được cứu bằng những bước đầu, nên không cần đốt tiền vào hosting nếu chưa thật sự cần. Bạn có thể bắt đầu với việc nén ảnh và rà lại danh sách script, thường chỉ mất vài giờ và gần như không tốn chi phí.
Nếu hai việc đó chưa đủ, bước tiếp theo là bật cache và CDN, thường hoàn tất trong dưới một ngày. Chỉ khi đã làm xong cả hai mà chỉ số vẫn kém mới nên cân nhắc nâng cấp hosting hoặc tối ưu lại theme và mã nguồn. Sau mỗi bước, hãy đo lại bằng đúng bộ công cụ ban đầu. Nếu chỉ số đã đạt thì dừng lại là được, không cần làm thêm chỉ vì thói quen.
Ước lượng thời gian và chi phí cho từng lỗi
Các con số dưới đây là mức tham khảo từ những ca mình đã làm. Chúng giúp bạn hình dung công sức trước khi quyết định, nhưng thực tế còn phụ thuộc vào độ phức tạp của trang và năng lực của người thực hiện.
Nén ảnh và bật lazy-load thường mất khoảng 1 đến 3 giờ, gần như miễn phí nếu dùng công cụ có sẵn. Gỡ script thừa mất khoảng 2 đến 4 giờ, tùy số lượng thẻ cần rà soát. Hosting VPS phổ thông tại Việt Nam dao động khoảng 150.000 đến 400.000 đồng mỗi tháng. Còn việc tối ưu lại mã nguồn hoặc theme có thể từ vài triệu đến vài chục triệu đồng, tùy mức độ can thiệp.
Điều đáng để ý là hai bước đầu gần như không tốn chi phí nhưng hiệu quả lại thường lớn nhất. Vì vậy đừng nhảy thẳng sang đổi hosting khi chưa thử những việc đơn giản trước.
Khi nào nên nghi ngờ quảng cáo thay vì trang đích?
Có lúc trang đã nhanh, chỉ số đều đạt, nhưng tỷ lệ thoát vẫn cao. Khi đó vấn đề thường nằm ở nội dung hoặc ưu đãi, không còn là tốc độ. Khách vào đúng trang nhưng thấy thông điệp không khớp với mẫu quảng cáo vừa bấm, và họ rời đi ngay. Lúc này, đọc thêm về cách viết call to action thu hút cho landing page sẽ giúp bạn kiểm tra xem lời kêu gọi hành động có đang bị lạc hướng hay không.
Cách kiểm tra là đối chiếu dữ liệu. Xem thời điểm bạn tăng ngân sách quảng cáo và thời điểm trang bắt đầu chậm lại có trùng nhau không. Nếu chi phí tăng mà tốc độ trang không đổi, nguyên nhân có thể nằm ở đối tượng nhắm mục tiêu hơn là ở trang.
Một bài kiểm tra A/B đơn giản sẽ tách hai nguyên nhân rõ hơn. Giữ nguyên trang, thay đổi quảng cáo rồi so sánh. Hoặc giữ nguyên quảng cáo và thử hai phiên bản trang có tốc độ khác nhau. Kết quả sẽ cho bạn biết nên sửa phần nào trước.
Khi nào nên làm lại trang thay vì vá lỗi?
Vá lỗi chỉ hợp lý khi khung cơ bản của trang vẫn ổn. Nếu trang có quá nhiều phần tử trùng lặp, nhiều đoạn mã chồng chéo qua nhiều lần chỉnh sửa, thì mỗi lần vá lại thêm một lớp phức tạp. Lúc đó làm lại thường rẻ và nhanh hơn về lâu dài.
Nếu muốn xây một trang nhẹ ngay từ đầu, bạn có thể tham khảo cẩm nang landing page để nắm quy trình dựng bố cục hợp lý. Làm đúng từ bước đầu sẽ giúp tránh phần lớn các lỗi nặng về sau.
Những câu hỏi khách hay hỏi nhất
Landing page tải dưới bao nhiêu giây thì được coi là ổn?
Mục tiêu thực tế là phần nội dung chính hiện ra trong khoảng dưới 2,5 giây trên điện thoại. Dưới 2 giây thì càng tốt. Nếu đo trên mạng di động mà vẫn trên 4 giây, bạn nên ưu tiên xử lý ngay. Con số này chỉ là hướng dẫn chung. Điều quan trọng hơn là khách có bấm được và đọc được nội dung nhanh hay không.
Có cần thuê người tối ưu tốc độ hay tự làm được?
Hai bước đầu, tức nén ảnh và gỡ script, bạn hoàn toàn tự làm được nếu cẩn thận. Các việc liên quan đến hosting và mã nguồn thì nên nhờ người có kinh nghiệm, vì chỉ một thiết lập sai cũng có thể làm trang lỗi hoặc mất dữ liệu.
Đổi hosting có làm mất dữ liệu và lượt index không?
Nếu chuyển đúng cách thì không mất dữ liệu. Bạn cần sao lưu đầy đủ, giữ nguyên đường dẫn và chuyển hướng các địa chỉ cũ sang địa chỉ mới. Sau khi chuyển xong, nên kiểm tra lại trong công cụ quản trị tìm kiếm để chắc chắn các trang vẫn được lập chỉ mục.
Vì sao máy tôi thấy nhanh nhưng khách vẫn phàn nàn chậm?
Máy của bạn có đường truyền và cấu hình mạnh hơn khách rất nhiều. Hãy thử mở trang bằng điện thoại đang dùng mạng di động thường ngày, hoặc dùng chế độ mô phỏng trong DevTools với đường truyền chậm. Lúc đó bạn sẽ thấy đúng trải nghiệm mà khách đang gặp phải.