Vì sao app bạn xây bằng AI có cảm giác chậm (và làm gì để khắc phục)

App bạn xây bằng AI chạy được. Các nút đi đến đúng chỗ, các màn hình thẳng hàng, dữ liệu được lưu. Nhưng có gì đó không ổn. Các trang mất hơi lâu một nhịp để tải. Một danh sách năm mươi mục khựng lại một giây. Nhấp “lưu” làm bạn phải chờ, rồi chờ thêm một chút, rồi tự hỏi liệu có nên nhấp lại không. Chẳng có gì hỏng cả — chỉ là nó có cảm giác chậm.

Nếu bạn là một nhà sáng lập không rành kỹ thuật đang cho ra mắt sản phẩm bằng một công cụ tạo app bằng AI, thì đây là một trong những khoảnh khắc “tôi không biết có gì sai” thường gặp nhất. Tin tốt là 80% app xây bằng AI bị chậm vì cùng một nhúm lý do. Không cái nào trong số đó đòi hỏi bạn phải học cách cơ sở dữ liệu hoạt động. Tất cả đều có cách sửa mà bạn có thể yêu cầu công cụ AI thực hiện bằng ngôn ngữ đời thường.

Bài viết này là bản tổng hợp nhanh.

Vì sao “chậm” thường là bốn thứ

Khi người dùng nói một app có cảm giác chậm, họ gần như không bao giờ có ý “máy chủ yếu”. Họ có ý một trong bốn thứ:

Lần vẽ đầu tiên chậm — họ nhấp một liên kết và nhìn chằm chằm vào một màn hình trắng hai giây trước khi có thứ gì đó hiện ra.
Một danh sách dài ì ạch — cuộn, lọc, hay tải “tất cả dự án của tôi” mất lâu hơn cả cuộn Instagram.
Một hành động mất quá lâu mà không cho họ biết chuyện gì đang xảy ra — họ nhấp “lưu” hoặc “gửi” và chẳng có gì phản hồi rõ ràng.
Cơ sở dữ liệu bị hỏi quá nhiều câu — những trang hiển thị dữ liệu từ nhiều nơi lại lấy từng phần một cách riêng lẻ và chồng các khoảng chờ lên nhau.

Chỉ vậy thôi. Gần như mọi app xây bằng AI mà tôi từng xem qua đều chậm vì một trong bốn lý do đó. Đây là cách nhận diện từng cái và cần yêu cầu công cụ làm gì để xử lý nó.

Lý do chậm số 1: lần vẽ đầu tiên

Nó trông thế nào: bạn nhấp một liên kết đến app của mình, thanh URL tải xong, nhưng trang trắng xóa một hai giây trước khi có gì đó hiện ra.

Thường do đâu: app đang tải mọi mẩu JavaScript mà nó có thể cần trước khi hiển thị bất cứ thứ gì cho bạn. Các công cụ tạo app bằng AI có xu hướng đóng gói hào phóng — thà có còn hơn thiếu — và cái gói đó càng lớn hơn khi bạn thêm tính năng.

Cần yêu cầu công cụ AI gì: “Lần tải trang đầu tiên có cảm giác chậm. Bạn chia nhỏ các gói JavaScript theo từng tuyến (route) được không, để trang chủ không phải tải về toàn bộ phần quản trị?” Hoặc, đơn giản hơn: “Thêm lazy loading cho các tuyến không phải trang chủ.” Hầu hết framework hiện đại đều hỗ trợ việc này chỉ với một hai dòng cấu hình. AI biết cách làm — bạn chỉ cần yêu cầu.

Nhân tiện: “Trên landing page có hình ảnh lớn nào mà chúng ta có thể tối ưu không?” Một bức ảnh hero 4 MB sẽ kéo tụt tốc độ cảm nhận hơn bất kỳ vấn đề code nào.

Lý do chậm số 2: danh sách dài

Nó trông thế nào: bạn có một danh sách — dự án, liên hệ, bài viết, bất cứ thứ gì — và một khi nó vượt quá bốn mươi hay năm mươi mục, việc cuộn bị giật hoặc việc lọc mất một nhịp thấy rõ.

Thường do đâu: app đang vẽ ra trang từng mục một cùng một lúc, kể cả những mục bạn không nhìn thấy. Với mười mục thì ổn. Với năm trăm, trình duyệt nghẹt thở.

Cần yêu cầu công cụ AI gì: “Danh sách dự án chậm khi có nhiều mục. Chúng ta có thể thêm phân trang (pagination), hoặc ảo hóa (virtualize) danh sách để chỉ vẽ những dòng đang hiển thị không?” Phân trang (“hiển thị 20 mục mỗi trang, kèm nút trước/sau”) là cách sửa dễ nhất. Ảo hóa (“chỉ vẽ những gì đang trên màn hình khi người dùng cuộn”) cho cảm giác mượt hơn nhưng tốn công hơn một chút. Cái nào cũng được.

Nếu danh sách còn có tìm kiếm hay lọc: “Có thể cho bộ lọc tìm kiếm chạy ở phía máy chủ thay vì trong trình duyệt không?” Lọc ở phía máy chủ nghĩa là trình duyệt chỉ giữ những dòng khớp, chứ không phải toàn bộ tập dữ liệu.

Lý do chậm số 3: sự chờ đợi câm lặng

Nó trông thế nào: bạn nhấp “lưu” hoặc “gửi” hoặc “tạo”. Chẳng có gì hiện ra rõ ràng. Hai giây sau, màn hình cập nhật và bạn nhận ra nó đã làm việc suốt từ đầu.

Thường do đâu: app đang thật sự làm việc — lưu vào cơ sở dữ liệu, gọi một API — nhưng công cụ AI không thêm một trạng thái đang tải. Vậy nên từ góc nhìn của bạn, cú nhấp chẳng làm gì cả.

Đây thật ra không phải vấn đề hiệu năng. Nó là vấn đề hiệu năng được cảm nhận, và những vấn đề kiểu này thường đau hơn cả những vấn đề thật. Một hành động 200 mili-giây không có phản hồi cho cảm giác chậm hơn một hành động 2 giây có biểu tượng xoay, vì não người dùng đang ở trong bóng tối.

Cần yêu cầu công cụ AI gì: “Thêm một trạng thái đang tải cho mọi nút kích hoạt một hành động. Hiển thị biểu tượng xoay hoặc dòng chữ ‘Đang lưu…’ trong lúc nó làm việc, và vô hiệu hóa nút để người dùng không nhấp đúp được.” Đây là cách sửa hiệu năng có lợi suất cao nhất trong bất kỳ app nào và nó gần như chẳng tốn gì.

Nhân tiện: “Với những hành động mà chúng ta biết trước kết quả sẽ ra sao, có thể cập nhật giao diện một cách lạc quan (optimistically) không — hiển thị thay đổi ngay lập tức và hoàn tác nếu máy chủ từ chối?” Cập nhật lạc quan là lý do vì sao nút “thích” trên các app mạng xã hội cho cảm giác tức thì kể cả khi điện thoại bạn đang sóng cực kém.

Lý do chậm số 4: cơ sở dữ liệu lắm lời

Nó trông thế nào: một trang hiển thị một danh sách các mục, mỗi mục kèm thêm thông tin — như một danh sách dự án kèm số lượng công việc trong mỗi dự án — mất lâu hơn nhiều để tải so với một danh sách đơn thuần.

Thường do đâu: trang đang tải các dự án trong một truy vấn, rồi tải số lượng công việc cho từng dự án trong một truy vấn riêng. Mười dự án ư? Mười một truy vấn. Một trăm dự án ư? Một trăm lẻ một. Cái này gọi là “truy vấn N+1”, và nó là lỗi hiệu năng cơ sở dữ liệu phổ biến nhất trong các app xây bằng AI, vì AI tối ưu cho code đọc rõ ràng, chứ không phải code chạy hiệu quả.

Cần yêu cầu công cụ AI gì: “Trang này đang tạo một truy vấn cho mỗi mục. Chúng ta có thể lấy tất cả dữ liệu liên quan trong một truy vấn duy nhất không — một phép join hay một phép tổng hợp (aggregate)?” Bạn không cần biết hai từ đó nghĩa là gì. AI thì biết. Cho nó xem trang chậm và nói “tôi nghĩ cái này bị vấn đề N+1” thường là đủ.

Bạn có thể phát hiện vấn đề N+1 mà không cần bất kỳ công cụ nào: mở trang, đếm xem nó mất bao lâu, rồi thêm gấp mười lần số mục vào danh sách bên dưới. Nếu trang giờ chậm hơn mười lần, bạn bị N+1. Nếu nó chỉ chậm hơn một chút xíu, thì không.

Một lời về việc tối ưu quá sớm

Một cái bẫy mà những người xây app mới hay sa vào: cố làm cho mọi trang đều nhanh trước khi có ai dùng app cả. Đừng.

Công việc tối ưu hiệu năng có cái giá thật. Thêm phân trang cho một danh sách mà mãi mãi chỉ có hai mươi dòng là phí công. Tối ưu một trang chỉ được tải hai lần mỗi ngày là phí công. Chia nhỏ các gói cho một công cụ nội bộ có ba người dùng là phí công. Thời điểm đúng để sửa một trang chậm là khi bạn có thể chỉ tên ra trang nào, hành động nào, và một con người cụ thể đã bực mình vì nó.

Vậy nên hãy xây nó một cách bình thường trước. Cho ra mắt. Quan sát cách nó được dùng. Khi có thứ gì đó cho một người thật cảm giác chậm — kể cả bạn — hãy khớp triệu chứng với một trong bốn loại ở trên và yêu cầu đúng cách sửa cụ thể đó. Bạn sẽ có một app nhanh hơn mà không phải tốn cả tuần vào hạ tầng mà người dùng sẽ chẳng bao giờ để ý.

Cách trao đổi với công cụ AI về tốc độ

Một mô-típ hiệu quả: mô tả triệu chứng, đừng mô tả giải pháp. AI giỏi chọn đúng cách sửa hơn bạn tưởng nhiều, miễn là nó biết thực sự đang sai chỗ nào.

Những câu lệnh hay để sao chép:

“Khi tôi mở trang cài đặt, có một độ trễ một giây trước khi bất cứ thứ gì hiện ra. Chúng ta có thể tìm xem cái gì đang chặn lần vẽ đầu tiên không?”
“Bảng điều khiển tải lâu hơn trang chủ dù nó hiển thị ít dữ liệu hơn. Chúng ta xem lại cách nó lấy dữ liệu được không?”
“Khi tôi nhấp ‘lưu thay đổi’ ở trang hồ sơ, chẳng có gì xảy ra trong hai giây. Thêm một trạng thái đang tải và đảm bảo nút không thể nhấp đúp.”
“Kiểm thử danh sách này với 500 mục giả và cho tôi biết chỗ nào bị chậm.”

Câu cuối bị đánh giá thấp. Yêu cầu AI tự tạo dữ liệu kiểm thử rồi tự thử trang là một trong những việc hữu ích nhất bạn có thể làm. Nó thường tìm ra những điểm chậm trước cả người dùng của bạn — và đề xuất cách sửa ngay trong cùng một câu trả lời.

Tốc độ trong các app xây bằng AI không phải chuyện phép màu. Đó là chuyện biết vấn đề của bạn rơi vào nhóm nào trong bốn nhóm, và yêu cầu đúng cách sửa bằng những lời rõ ràng. Làm được vậy, “cảm giác chậm” sẽ thành “cảm giác ổn” chỉ với một nhúm thay đổi nhỏ, đúng trọng tâm — chứ không phải làm lại từ đầu.