Dlaczego Twoja aplikacja zbudowana z AI wydaje się wolna (i co z tym zrobić)

Twoja aplikacja zbudowana z AI działa. Przyciski są tam, gdzie powinny, ekrany się zgadzają, dane się zapisują. Ale coś jest nie tak. Strony ładują się o chwilę za długo. Lista pięćdziesięciu pozycji zawiesza się na sekundę. Kliknięcie „zapisz” każe Ci czekać, potem czekać jeszcze trochę, a potem zastanawiać się, czy nie kliknąć ponownie. Nic nie jest zepsute — po prostu wydaje się wolne.

Jeśli jesteś nietechnicznym founderem wdrażającym aplikację w kreatorze aplikacji z AI, to jeden z najczęstszych momentów „nie wiem, co jest nie tak”. Dobra wiadomość jest taka, że 80% wolnych aplikacji zbudowanych z AI jest wolnych z tych samych kilku powodów. Żaden z nich nie wymaga, żebyś nauczył się, jak działają bazy danych. Wszystkie mają rozwiązania, o które możesz poprosić swój kreator AI prostym językiem.

Ten wpis to ściągawka.

Dlaczego „wolne” to zwykle cztery rzeczy

Kiedy użytkownicy mówią, że aplikacja wydaje się wolna, niemal nigdy nie mają na myśli „serwer jest za słaby”. Mają na myśli jedną z czterech rzeczy:

1. Pierwsze wyświetlenie jest wolne — klikają odnośnik i gapią się na pusty ekran przez dwie sekundy, zanim cokolwiek się pojawi.
2. Długa lista jest ociężała — przewijanie, filtrowanie albo ładowanie „wszystkich moich projektów” trwa dłużej niż przewijanie Instagrama.
3. Akcja trwa za długo, nie mówiąc im, co się dzieje — klikają „zapisz” albo „wyślij” i nic widocznie nie reaguje.
4. Baza danych dostaje za dużo pytań — strony pokazujące dane z wielu miejsc pobierają każdy element osobno i sumują czasy oczekiwania.

I tyle. Niemal każda wolna aplikacja zbudowana z AI, którą widziałem, jest wolna z jednego z tych czterech powodów. Oto jak rozpoznać każdy z nich i o co poprosić kreator, żeby coś z tym zrobił.

Powód wolności nr 1: pierwsze wyświetlenie

Jak to wygląda: klikasz odnośnik do swojej aplikacji, pasek adresu kończy ładowanie, ale strona przez sekundę lub dwie jest biała, zanim cokolwiek się pojawi.

Co zwykle to powoduje: aplikacja ładuje każdy fragment JavaScriptu, który może być jej potrzebny, zanim cokolwiek Ci pokaże. Kreatory aplikacji z AI mają tendencję do hojnego pakowania — lepiej coś dołączyć, niż pominąć — a ten pakiet rośnie tym bardziej, im więcej funkcji dodajesz.

O co poprosić kreator AI: „Pierwsze ładowanie strony wydaje się wolne. Czy możesz podzielić pakiety JavaScriptu według tras, żeby strona główna nie musiała pobierać całej sekcji administracyjnej?” Albo prościej: „Dodaj leniwe ładowanie dla tras innych niż strona główna”. Większość nowoczesnych frameworków obsługuje to w jednej lub dwóch linijkach konfiguracji. AI wie jak — musisz tylko poprosić.

Przy okazji: „Czy na stronie startowej są jakieś duże obrazy, które moglibyśmy zoptymalizować?” Zdjęcie hero o wadze 4 MB obniży odczuwaną szybkość bardziej niż jakikolwiek problem z kodem.

Powód wolności nr 2: długa lista

Jak to wygląda: masz listę — projektów, kontaktów, postów, czegokolwiek — i gdy przekroczy czterdzieści czy pięćdziesiąt pozycji, przewijanie zacina się, a filtrowanie trwa zauważalną chwilę.

Co zwykle to powoduje: aplikacja renderuje na stronie każdą pojedynczą pozycję naraz, nawet te, których nie widzisz. Przy dziesięciu pozycjach to w porządku. Przy pięciuset przeglądarka się dławi.

O co poprosić kreator AI: „Lista projektów jest wolna, gdy jest dużo pozycji. Czy możemy dodać paginację albo zwirtualizować listę, żeby renderowane były tylko widoczne wiersze?” Paginacja („pokaż 20 na stronę, z przyciskami dalej/wstecz”) to najłatwiejsze rozwiązanie. Wirtualizacja („renderuj tylko to, co jest na ekranie, gdy użytkownik przewija”) wydaje się płynniejsza, ale to trochę więcej pracy. Jedno i drugie jest w porządku.

Jeśli lista ma też wyszukiwanie lub filtrowanie: „Czy filtrowanie wyszukiwania może odbywać się na serwerze, a nie w przeglądarce?” Filtrowanie po stronie serwera oznacza, że przeglądarka trzyma tylko pasujące wiersze, a nie cały zbiór danych.

Powód wolności nr 3: ciche czekanie

Jak to wygląda: klikasz „zapisz”, „wyślij” albo „generuj”. Nic widocznie się nie dzieje. Dwie sekundy później ekran się aktualizuje i orientujesz się, że przez cały czas to pracowało.

Co zwykle to powoduje: aplikacja wykonuje prawdziwą pracę — zapis do bazy danych, wywołanie API — ale kreator AI nie dodał stanu ładowania. Więc z Twojego punktu widzenia kliknięcie nic nie zrobiło.

To tak naprawdę nie jest problem z wydajnością. To problem z odczuwaną wydajnością, a te bywają bardziej dotkliwe niż prawdziwe. Akcja trwająca 200 milisekund bez informacji zwrotnej wydaje się wolniejsza niż akcja trwająca 2 sekundy ze spinnerem, bo mózg użytkownika jest w ciemności.

O co poprosić kreator AI: „Dodaj stan ładowania do każdego przycisku, który wyzwala akcję. Pokaż spinner albo tekst »Zapisywanie…«, gdy trwa praca, i zablokuj przycisk, żeby użytkownicy nie mogli kliknąć dwa razy”. To pojedyncze rozwiązanie wydajnościowe o najwyższym zwrocie w każdej aplikacji i kosztuje niemal nic.

Przy okazji: „W przypadku akcji, których wynik znamy z góry, czy możemy aktualizować interfejs optymistycznie — pokazać zmianę natychmiast i cofnąć ją, jeśli serwer ją odrzuci?” Aktualizacje optymistyczne to powód, dla którego przycisk „lubię to” w aplikacjach społecznościowych wydaje się natychmiastowy, nawet gdy Twój telefon ma fatalny zasięg.

Powód wolności nr 4: gadatliwa baza danych

Jak to wygląda: strona pokazująca listę pozycji, z których każda ma dodatkowe informacje — jak lista projektów z liczbą zadań w każdym — ładuje się znacznie dłużej niż zwykła lista.

Co zwykle to powoduje: strona ładuje projekty w jednym zapytaniu, a następnie ładuje liczbę zadań dla każdego projektu w osobnym zapytaniu. Dziesięć projektów? Jedenaście zapytań. Sto projektów? Sto jeden. Nazywa się to „zapytaniem N+1” i jest to najczęstszy błąd wydajności bazy danych w aplikacjach zbudowanych z AI, bo AI optymalizuje pod kod, który czyta się jasno, a nie kod, który działa wydajnie.

O co poprosić kreator AI: „Ta strona robi jedno zapytanie na pozycję. Czy możemy pobrać wszystkie powiązane dane w jednym zapytaniu — przez join albo agregat?” Nie musisz wiedzieć, co znaczy którekolwiek z tych słów. AI wie. Pokazanie mu wolnej strony i powiedzenie „myślę, że to ma problem N+1” zwykle wystarcza.

Problemy N+1 możesz wykryć bez żadnych narzędzi: otwórz stronę, policz, ile zajmuje, a potem dodaj dziesięć razy więcej pozycji do listy źródłowej. Jeśli strona jest teraz dziesięć razy wolniejsza, masz N+1. Jeśli jest tylko odrobinę wolniejsza, nie masz.

Słowo o przedwczesnej optymalizacji

Pułapka, w którą wpadają nowi twórcy: próbowanie, żeby każda strona była szybka, zanim ktokolwiek korzysta z aplikacji. Nie rób tego.

Praca nad wydajnością ma realny koszt. Dodawanie paginacji do listy, która kiedykolwiek będzie mieć dwadzieścia wierszy, to zmarnowany wysiłek. Optymalizowanie strony, która ładuje się dwa razy dziennie, to zmarnowany wysiłek. Dzielenie pakietów dla wewnętrznego narzędzia z trzema użytkownikami to zmarnowany wysiłek. Właściwy moment na naprawę wolnej strony to ten, gdy potrafisz wskazać stronę, akcję i osobę, której to przeszkadzało.

Więc najpierw zbuduj normalnie. Wdróż. Obserwuj, jak jest używana. Gdy coś wyda się wolne prawdziwej osobie — w tym Tobie — dopasuj objaw do jednej z czterech kategorii powyżej i poproś o to konkretne rozwiązanie. Dostaniesz szybszą aplikację bez spędzania tygodnia na infrastrukturze, której Twoi użytkownicy nigdy nie zauważą.

Jak rozmawiać z kreatorem AI o szybkości

Wzorzec, który działa: opisuj objaw, a nie rozwiązanie. AI jest znacznie lepsze w doborze właściwego rozwiązania, niż byś przypuszczał, o ile wie, co tak naprawdę jest nie tak.

Dobre prompty do skopiowania:

• „Kiedy otwieram stronę ustawień, jest sekundowe opóźnienie, zanim cokolwiek się pojawi. Czy możemy ustalić, co blokuje pierwsze renderowanie?”
• „Panel ładuje się dłużej niż strona główna, mimo że pokazuje mniej danych. Czy możemy przyjrzeć się, jak pobiera swoje dane?”
• „Kiedy klikam »zapisz zmiany« na stronie profilu, nic się nie dzieje przez dwie sekundy. Dodaj stan ładowania i upewnij się, że przycisku nie da się kliknąć dwa razy”.
• „Przetestuj tę listę z 500 fałszywymi pozycjami i powiedz mi, gdzie są spowolnienia”.

To ostatnie jest niedoceniane. Poproszenie AI, żeby wygenerowało dane testowe i samo wypróbowało stronę, to jedna z najprzydatniejszych rzeczy, jakie możesz zrobić. Często znajdzie wolne miejsca, zanim zrobią to Twoi użytkownicy — i zaproponuje rozwiązanie w tej samej odpowiedzi.

Szybkość w aplikacjach zbudowanych z AI nie polega na magii. Polega na wiedzy, do którego z czterech koszyków wpada Twój problem, i poproszeniu o właściwe rozwiązanie jasnymi słowami. Zrób to, a „wydaje się wolne” zmieni się w „wydaje się w porządku” po garstce małych, celnych zmian — bez przepisywania od nowa.