De ce aplicația ta creată cu IA pare lentă (și ce să faci în privința asta)

Un ghid pe înțelesul tuturor despre cele patru motive pentru care aplicațiile create cu IA par greoaie — imaginile, listele, ecranele de așteptare și baza de date — și soluția pentru fiecare, pe care i-o poți cere creatorului tău cu IA.

Aplicația ta creată cu IA funcționează. Butoanele duc unde trebuie, ecranele se aliniază, datele se salvează. Dar ceva pare în neregulă. Paginile se încarcă cu o secundă prea mult. O listă de cincizeci de elemente se blochează o clipă. Faci clic pe „salvează” și aștepți, apoi mai aștepți puțin, apoi te întrebi dacă ar trebui să dai din nou clic. Nu e nimic stricat — pur și simplu pare lentă.

Dacă ești un fondator non-tehnic care lansează cu un creator de aplicații cu IA, ăsta e unul dintre cele mai des întâlnite momente „nu știu ce e în neregulă”. Vestea bună e că 80% dintre aplicațiile create cu IA care sunt lente sunt lente din aceleași câteva motive. Niciunul nu-ți cere să înveți cum funcționează bazele de date. Toate au soluții pe care i le poți cere creatorului tău cu IA, în limbaj simplu.

Articolul ăsta e foaia de trișat.

De ce „lent” înseamnă de obicei patru lucruri

Când utilizatorii spun că o aplicație pare lentă, aproape niciodată nu vor să spună „serverul e subdimensionat”. Vor să spună unul din patru lucruri:

  1. Prima afișare e lentă — dau clic pe un link și se holbează la un ecran gol două secunde înainte să apară ceva.
  2. O listă lungă e greoaie — derularea, filtrarea sau încărcarea „tuturor proiectelor mele” durează mai mult decât derularea pe Instagram.
  3. O acțiune durează prea mult fără să le spună ce se întâmplă — dau clic pe „salvează” sau „trimite” și nimic nu răspunde vizibil.
  4. Bazei de date i se pun prea multe întrebări — paginile care arată date din mai multe locuri preiau fiecare bucată separat și adună timpii de așteptare.

Atât. Aproape fiecare aplicație lentă creată cu IA pe care am examinat-o e lentă dintr-unul din acele patru motive. Iată cum recunoști fiecare și ce să-i ceri creatorului tău să facă în privința lui.

Motivul lentorii #1: prima afișare

Cum arată: dai clic pe un link către aplicația ta, bara de URL termină de încărcat, dar pagina e albă o secundă-două înainte să apară ceva.

Ce o cauzează de obicei: aplicația încarcă fiecare bucată de JavaScript de care ar putea avea nevoie înainte să-ți arate ceva. Creatoarele de aplicații cu IA tind să împacheteze generos — mai bine să incluzi ceva decât să-l ratezi — iar pachetul ăla devine tot mai mare cu cât adaugi mai multe funcții.

Ce să-i ceri creatorului tău cu IA: „Prima încărcare a paginii pare lentă. Poți să împarți pachetele JavaScript pe rută, ca pagina principală să nu trebuiască să descarce toată secțiunea de administrare?” Sau, mai simplu: „Adaugă încărcare leneșă (lazy loading) pentru rutele care nu sunt pagina principală.” Majoritatea framework-urilor moderne acceptă asta în una-două linii de configurare. IA știe cum — trebuie doar să ceri.

Cât te ocupi de asta: „Există imagini mari pe pagina de destinație pe care le-am putea optimiza?” O fotografie hero de 4 MB va prăbuși viteza percepută mai mult decât orice problemă de cod.

Motivul lentorii #2: lista lungă

Cum arată: ai o listă — proiecte, contacte, postări, orice — și odată ce trece de patruzeci-cincizeci de elemente, derularea se bâlbâie sau filtrarea durează o clipă vizibilă.

Ce o cauzează de obicei: aplicația randează fiecare element pe pagină dintr-odată, inclusiv pe cele pe care nu le poți vedea. Cu zece elemente e în regulă. Cu cinci sute, browserul se sufocă.

Ce să-i ceri creatorului tău cu IA: „Lista de proiecte e lentă când sunt multe elemente. Putem adăuga paginare, sau virtualiza lista ca să fie randate doar rândurile vizibile?” Paginarea („arată 20 pe pagină, cu butoane înainte/înapoi”) e cea mai ușoară soluție. Virtualizarea („randează doar ce e pe ecran pe măsură ce utilizatorul derulează”) pare mai fluidă, dar e ceva mai multă muncă. Oricare e bună.

Dacă lista are și căutare sau filtrare: „Poate filtrarea de la căutare să se întâmple pe server în loc de browser?” Filtrarea pe server înseamnă că browserul ține mereu doar rândurile care se potrivesc, nu tot setul de date.

Motivul lentorii #3: așteptarea tăcută

Cum arată: dai clic pe „salvează” sau „trimite” sau „generează”. Nu se întâmplă nimic vizibil. Două secunde mai târziu, ecranul se actualizează și îți dai seama că lucra tot timpul.

Ce o cauzează de obicei: aplicația face muncă reală — salvează într-o bază de date, apelează un API — dar creatorul cu IA n-a adăugat o stare de încărcare. Așa că, din punctul tău de vedere, clicul n-a făcut nimic.

Asta de fapt nu e o problemă de performanță. E o problemă de performanță percepută, iar acelea sunt deseori mai dureroase decât cele reale. O acțiune de 200 de milisecunde fără feedback pare mai lentă decât o acțiune de 2 secunde cu un indicator de încărcare, pentru că creierul utilizatorului e pe întuneric.

Ce să-i ceri creatorului tău cu IA: „Adaugă o stare de încărcare la fiecare buton care declanșează o acțiune. Arată un indicator de încărcare sau textul «Se salvează…» cât lucrează, și dezactivează butonul ca utilizatorii să nu poată da dublu-clic.” Asta e soluția de performanță cu cel mai mare randament din orice aplicație și nu costă aproape nimic.

Cât te ocupi de asta: „Pentru acțiunile la care știm care va fi rezultatul, putem actualiza interfața optimist — să arătăm schimbarea imediat și s-o anulăm dacă serverul o respinge?” Actualizările optimiste sunt motivul pentru care butonul de „like” din aplicațiile sociale pare instantaneu, chiar și când telefonul tău are semnal groaznic.

Motivul lentorii #4: baza de date guralivă

Cum arată: o pagină care arată o listă de elemente, fiecare cu informații suplimentare — ca o listă de proiecte cu numărul de sarcini din fiecare — durează mult mai mult să se încarce decât ar dura o listă simplă.

Ce o cauzează de obicei: pagina încarcă proiectele într-o interogare, apoi încarcă numărul de sarcini pentru fiecare proiect într-o interogare separată. Zece proiecte? Unsprezece interogări. O sută de proiecte? O sută una. Asta se numește „interogare N+1” și e cel mai des întâlnit bug de performanță a bazei de date în aplicațiile create cu IA, pentru că IA optimizează pentru cod care se citește clar, nu cod care rulează eficient.

Ce să-i ceri creatorului tău cu IA: „Pagina asta face o interogare per element. Putem prelua toate datele asociate într-o singură interogare — un join sau un agregat?” Nu trebuie să știi ce înseamnă vreunul dintre cuvinte. IA știe. Să-i arăți pagina lentă și să spui „cred că asta are o problemă N+1” e de obicei suficient.

Poți depista problemele N+1 fără niciun instrument: deschide pagina, numără cât durează, apoi adaugă de zece ori mai multe elemente în lista de bază. Dacă pagina e acum de zece ori mai lentă, ai un N+1. Dacă e doar puțin mai lentă, n-ai.

Câteva cuvinte despre optimizarea prematură

O capcană în care cad creatorii noi: să încerce să facă fiecare pagină rapidă înainte ca cineva să folosească aplicația. N-o face.

Munca de performanță are un cost real. A adăuga paginare la o listă care va avea vreodată doar douăzeci de rânduri e efort irosit. A optimiza o pagină care se încarcă de două ori pe zi e efort irosit. A împărți pachetele pentru un instrument intern cu trei utilizatori e efort irosit. Momentul potrivit să repari o pagină lentă e când poți numi pagina, acțiunea și o persoană pe care a deranjat-o.

Așa că mai întâi construiește-o normal. Lansează. Urmărește cum e folosită. Când ceva pare lent pentru o persoană reală — inclusiv tu — potrivește simptomul cu una dintre cele patru categorii de mai sus și cere acea soluție anume. Vei obține o aplicație mai rapidă fără să petreci o săptămână pe infrastructură pe care utilizatorii tăi n-o vor observa niciodată.

Cum îi vorbești creatorului tău cu IA despre viteză

Un tipar care funcționează: descrie simptomul, nu soluția. IA e mult mai bună la a alege soluția potrivită decât te-ai aștepta, atâta timp cât știe ce e de fapt în neregulă.

Prompt-uri bune de copiat:

  • „Când deschid pagina de setări, e o întârziere de o secundă înainte să apară ceva. Putem afla ce blochează prima randare?”
  • „Panoul de control durează mai mult să se încarce decât pagina principală, deși arată mai puține date. Putem să ne uităm la cum își preia datele?”
  • „Când dau clic pe «salvează modificările» pe pagina de profil, nu se întâmplă nimic timp de două secunde. Adaugă o stare de încărcare și asigură-te că butonul nu poate primi dublu-clic.”
  • „Testează lista asta cu 500 de elemente false și spune-mi unde sunt încetinirile.”

Ultimul e subevaluat. Să ceri IA să genereze date de test și să încerce ea însăși pagina e unul dintre cele mai utile lucruri pe care le poți face. Va găsi deseori locurile lente înainte să le găsească utilizatorii tăi — și va propune soluția în același răspuns.

Viteza în aplicațiile create cu IA nu ține de magie. Ține de a ști în care dintre cele patru categorii intră problema ta și de a cere soluția potrivită în cuvinte clare. Fă asta, și „pare lentă” devine „pare bine” cu o mână de schimbări mici și țintite — nu cu o rescriere.