AI ģenerēta mājaslapa izskatās labi: ko atradām tās kodā

Mēdz gadīties, ka mājaslapa pie mums nonāk jau uzbūvēta. Cilvēks, kurš nav izstrādātājs, ir aprakstījis, ko vēlas, modelis ir uztaisījis lapu, un tā tiešām strādā: atveras, pielāgojas ekrānam, tipogrāfija ir sakārtota, atstarpes ir apzinātas. Pēc tam mums lūdz to publicēt īstā domēnā, papildināt vai iekļaut lielākā vietnē. Vispirms mēs atveram failu.

Tas, kas ir failā, gandrīz nekad nesakrīt ar to, kas ir ekrānā. Par šo atšķirību ir viss tālākais.

Uzreiz jāpasaka: tas nav arguments pret to, ka lapu uzģenerējat paši. Daļa no koda, ko esam lasījuši, bija labāka nekā krietna daļa ar roku rakstīta koda, un tālāk to arī nosaucam. Doma ir šaurāka. Pāri paliek tieši tās kļūdas, kas lapas izskatu nemaina. Ja vienīgā pārbaude ir paskatīties uz lapu, tieši tās arī nonāk produkcijā.

Īsumā

Katru reizi atkārtojas viens un tas pats: viss ir sabāzts vienā HTML failā base64 formātā. Smagākajā piemērā, ko esam mērījuši, 99,6 % no 4,7 MB liela faila bija base64, un īstā koda tur bija ap 20 KB. No šī viena lēmuma izriet vēl četras problēmas. Faili, ko pārlūks nevar saglabāt kešatmiņā atsevišķi. Dokuments, kas jāizlasa līdz galam, pirms parādās pirmais pikselis. Attēli, kurus vairs nevar ne pielāgot ekrānam, ne atlikt uz vēlāku brīdi. Un fonti nesaspiestā formātā.

Blakus tam ir otrs, mazāk pamanāms trūkums: dokumenta galvene bez apraksta, bez kanoniskās adreses un bez sociālo tīklu priekšskatījuma birkām. Turklāt lapās, kas izplatās tikai tāpēc, ka cilvēki cits citam sūta saiti. Ne vienu, ne otru pārlūka logā neredzēsiet. Abi ir lēti salabojami, tiklīdz kāds izlasa failu.

Viss vienā failā

Atverot ģenerētu lapu, parasti neatradīsiet ne assets mapi, ne stila failu, ne attēlu direktoriju. Ir viens HTML dokuments, un tas ir milzīgs. Katra fotogrāfija, katrs logotips un katrs fonts ir pārkodēts base64 formātā un ielīmēts turpat iekšā: vai nu <style> blokā, vai src atribūtā.

Skaitļi no vienas prezentācijas lapas, kas pati par sevi ir patiešām glīts darbs:

Piegādātais fails	4,7 MB, viens HTML dokuments
Īstais kods tajā	~20 KB
Base64 saturs	99,6 % no faila
Faili pēc atkodēšanas	3,35 MB
Tie paši faili kā base64 teksts	4,47 MB
Lielākais fails	fotogrāfija, 1,9 MB
Attēli	41
Attēli ar atlikto ielādi	0
Attēli ar srcset	0

Salīdzinājumam: 2025. gadā mediānā mobilā sākumlapa svēra 2,56 MB, un tas ir visas lapas svars kopā. Šeit runa ir par vienu failu, kas sver teju divreiz vairāk, un no tā kešatmiņā nepaliek nekas.

Tā nav paviršība, un iemesls ir vienkāršs. Rīks piedāvā vienu teksta lodziņu. Failu nav kur nolikt, tāpēc viss kļūst par tekstu. Citas arhitektūras rīkam nav, lapa atveras nevainojami, un tāpēc šāds fails nonāk līdz pat produkcijai.

Ko tas maksā

Base64 sver apmēram par trešdaļu vairāk nekā tas, ko tas kodē. Base64 trīs baitus pieraksta ar četrām rakstzīmēm, tāpēc pieaugums ir aritmētika, nevis viedoklis: 3,35 MB attēlu un fontu pārvērtās par 4,47 MB teksta. Saspiešana daļu atgūst, taču base64 saspiežas sliktāk nekā binārais fails, ko tas aizstāja, tāpēc līdz sākotnējam izmēram vairs netiksiet.

Kešatmiņā vairs nepaliek nekas atsevišķi. Pārlūks saglabā failus kešatmiņā pēc adreses. Ja fonts, galvenā fotogrāfija un teksts atrodas vienā adresē, tiem ir arī viens kopīgs derīguma termiņš. Izlabojat vienu drukas kļūdu, un katrs atkārtots apmeklētājs no jauna lejupielādē visus attēlus. Otrs gadījums ir vēl sliktāks: apmeklētājs, kurš atver divas lapas, vienu un to pašu fontu lejupielādē divreiz, jo kopīga faila, ko otrā lapa varētu izmantot, vienkārši nav.

Dokuments bloķē pats sevi. Stila fails jau pēc būtības aizkavē lapas zīmēšanu, bet šeit stila failā ir fotogrāfijas. Parseris izlasa megabaitus kodēta teksta, pirms uzzīmē pirmo pikseli. Turklāt to, kam būtu jāielādējas pirmajam, nevar ne ielādēt iepriekš, ne ielādēt prioritāri. Tas ir lielais attēls lapas augšā, gandrīz vienmēr Largest Contentful Paint elements, un tagad tas vairs nav atsevišķs resurss, bet teksta virkne.

Attēlus vairs nevar pielāgot ekrānam. srcset, <picture> un mūsdienīgie formāti prasa īstus failus ar īstām adresēm. Ja attēls ir iekodēts iekšā, telefons lēnā savienojumā lejupielādē to pašu 1,9 MB fotogrāfiju, ko dators. Mazākas versijas, ko tam piedāvāt, vienkārši nav.

Atliktā ielāde zaudē jēgu. loading="lazy" atliek pieprasījumu uz vēlāku brīdi. Bet atlikt vairs nav ko, ja baiti jau atrodas dokumentā, kas ir lejupielādēts līdz galam. Pārlūkam pilnībā jālejupielādē katrs no 41 attēla zem ekrāna malas, pirms parādās pirmais no tiem.

Un failu vairs nevar rediģēt. Lielākā daļa no tiem megabaitiem ir atsevišķas rindas vairāku simtu tūkstošu rakstzīmju garumā. Palaidiet formatētāju vienu vienīgu reizi, un kodētie dati izpletīsies miljonos rindu. Izmaiņu salīdzinājums kļūs nelasāms uz visiem laikiem, un versiju kontrole vairs nepateiks, kas īsti mainījās.

Kā to darām mēs

Faili paliek faili. Šis viens noteikums uzreiz novērš visu, kas uzskaitīts augstāk. Interaktīvajā kalkulatorā, ko pārņēmām, četri faili (viena fotogrāfija un trīs fonti) pārcēlās no HTML uz assets mapi, un dokuments saruka no 415 KB līdz 43 KB. Tie paši pikseļi, tā pati uzvedība, tas pats kods. Fotogrāfija un fonti tagad glabājas kešatmiņā atsevišķi un paliek tur arī pēc katra nākamā teksta labojuma.

Izņēmums tomēr ir: tiešām mazu failu iekodēt iekšā ir pareizi. Divus kilobaitus liels fails vairāk maksā savienojuma izveidē, nekā ietaupa kešatmiņā, un lielākā daļa būvēšanas rīku tieši šī iemesla dēļ automātiski iekodē visu, kas mazāks par apmēram 4 KB. Vaina nav paņēmienā, bet mērogā. Iekodēta divus kilobaitus liela ikona ir apzināts kompromiss, iekodēta 1,9 MB fotogrāfija vairs nav nekāds kompromiss.

Fontos šī kļūda maksā visvairāk

Rēķinot uz kilobaitu, viena faila pieeja visvairāk kaitē fontiem. Failos, ko izlasījām, atradām trīs problēmas.

Nesaspiests formāts. Vairāk nekā vienā failā atradām 311 KB smagu TTF fontu, iekodētu turpat stilos. TTF nav saspiests nemaz. WOFF2, ko saprot ikviens mūsdienu pārlūks, ir saspiests ar Brotli un parasti sver tikai daļu no tā, turklāt ekrānā izskatās tieši tāpat. Konvertēšana neko nemaksā un neko nemaina.

Fonts nav sadalīts apakškopās. Pilnā fontā ir zīmes rakstībām, ko jūsu apmeklētāji nekad neieraudzīs: kirilica, grieķu, vjetnamiešu. Ģenerētā kodā pilno fontu parasti sūta visiem, lai gan tas nekur nav vajadzīgs. unicode-range sadala fontu apakškopās, un pārlūks lejupielādē tikai tās, kas lapas tekstam tiešām nepieciešamas.

Latviešu valodā tā vairs nav optimizācija, bet gan pareizības jautājums. Ā, Č, Ē, Ģ, Ī, Ķ, Ļ, Ņ, Š, Ū un Ž latin apakškopā nav, tie ir latin-ext apakškopā. Ja ielādējas tikai latin, pārlūks latviešu burtus ar diakritiskajām zīmēm zīmē ar rezerves fontu citā svarā un platumā. Iznāk tas pats raibais izskats ar svešiem burtiem, par kuru rakstījām atsevišķi. Latviešu lapās tā ir viena no biežākajām kļūdām, un labojums ir vienā rindā.

Divas fontu stratēģijas vienlaikus. Vienā failā virsrakstu fonts bija iekodēts iekšā, bet pamatteksta fonts tajā pašā dokumentā ielādējās no Google Fonts CDN. Tā jāmaksā divreiz: par iekodētā fonta svaru un vēl par pieprasījumu uz trešo pusi.

Eiropā CDN fontiem ir arī juridiskas sekas. 2022. gada 20. janvārī Minhenes apgabaltiesa piesprieda apmeklētājam 100 EUR atlīdzību, jo lapas Google Fonts iegulde bez piekrišanas nodeva Google viņa dinamisko IP adresi (3 O 17493/20). Viens Vācijas pirmās instances spriedums vēl nav nostiprināta ES tiesību norma, un summa ir niecīga. Bet pamatojums nav niecīgs: pieprasījums uz trešo pusi aiziet, pirms apmeklētājs kaut kam ir piekritis, un IP adrese ir personas dati. Ja fonti glabājas jūsu pašu serverī, jautājums nerodas vispār, un lapa ielādējas ātrāk.

Galvene, ko neviens neuzraksta

Otrs trūkums ir mazāk pamanāms, bet kampaņas lapai tas izmaksā dārgāk.

Prezentācijas lapā nebija meta apraksta. Nebija kanoniskās adreses. Nebija nevienas Open Graph vai Twitter birkas. <html> elements pieteica latviešu valodu, bet <title> bija angliski.

Tas ir svarīgāk, nekā izklausās. Kampaņas lapa dzīvo no tā, ka cilvēki cits citam sūta saiti. Ielīmējiet adresi bez Open Graph birkām Messenger, WhatsApp, Slack vai LinkedIn, un tur būs kaila zila saite: bez attēla, bez virsraksta, bez apraksta. Katra kopīgošana strādās vājāk, nekā varētu, un tā tas turpināsies mūžīgi, jo pārlūks par to nepasaka ne vārda.

Mēs katrai lapai pievienojam vienu un to pašu sarakstu:

<meta name="description" content="…">
<link rel="canonical" href="https://piemers.lv/lapa/">
<meta property="og:type" content="website">
<meta property="og:locale" content="lv_LV">
<meta property="og:url" content="https://piemers.lv/lapa/">
<meta property="og:title" content="…">
<meta property="og:description" content="…">
<meta property="og:image" content="https://piemers.lv/assets/share.jpg">
<meta property="og:image:width" content="1920">
<meta property="og:image:height" content="1080">
<meta name="twitter:card" content="summary_large_image">

og:image vienmēr ar pilnu adresi, nevis relatīvu, jo robots, kas to ielādē, lapas kontekstu nezina. Platums un augstums norādīti skaidri, lai priekšskatījums parādītos vēl pirms attēla ielādes. Un <title> tajā valodā, kuru pieteic lang atribūts.

Virsrakstus izvēlas pēc izmēra, nevis struktūras

Prezentācijas lapā bija četras skaidri nodalītas sadaļas un tieši viens virsraksta elements visā dokumentā: viens <h1>. Neviena <h2>, neviena <h3>. Katrs sadaļas nosaukums bija noformēts kā <div> vai <p>.

Vizuāli tas neatšķiras no pareiza koda, un tieši par to ir viss raksts. Strukturāli tā ir lapa bez satura rādītāja. Neredzīgi cilvēki ar ekrāna lasītāju bieži pārvietojas pa lapu tieši pēc virsrakstiem. Šeit viņi atrod vienu virsrakstu un tālāk neko. Meklētājprogrammas savukārt zaudē struktūru, kas pasaka, par ko lapa ir un kā tās daļas savstarpēji saistās.

Virsraksti nav burtu izmēri. Tie ir dokumenta struktūra, un par izmēriem atbild CSS.

Ko ģenerētais kods izdarīja labi

Labā bija daudz.

• Katram no 41 attēla bija īsts, aprakstošs alt teksts. Ne faila nosaukums, ne vārds “attēls”, bet normāls apraksts. Miljonā apmeklētāko sākumlapu alt teksta trūkst 53,1 % gadījumu. Šeit bija uzrakstīts katrs.
• Katrai ārējai saitei bija rel="noopener". Visām bez izņēmuma.
• Standarta elementi lietoti pēc būtības. <details> un <summary> sakļaujamai sadaļai, nevis JavaScript akordeons. Īsts <select>. Īsti <button> elementi.
• ARIA, kas tur bija, bija pareiza. aria-pressed pārslēdzējiem, aria-live="polite" panelim ar rezultātiem, aria-hidden dekoratīvajām ikonām. Pareiza ARIA gadās retāk nekā nekāda.
• prefers-reduced-motion bija ievērots. To joprojām izlaiž liela daļa profesionāli būvētu lapu.
• Valūtu un skaitļu formatēšanai izmantots Intl.NumberFormat ar pareizo lokalizāciju, nevis virkņu salikšana, tāpēc tūkstošu atdalītāji un eiro zīme stāv tur, kur latviešu praksē tiem jāstāv.
• CSS bija labs. Mainīgie, clamp() plūstošai tipogrāfijai, saprātīgs režģis, bez ietvariem, bez jQuery. Ap 20 KB koda, kas paveic visu darbu, un ar tādu skaitli daudzām aģentūru būvēm būtu grūti sacensties.

Šis saraksts ir raksta būtība, nevis pieklājība. Tas nav nekompetents darbs. Tas ir darbs, kas rūpīgi pārbaudīts tajā vienā vietā, ko pārlūks parāda, un nav pārbaudīts tur, kur pārlūks neko nerāda.

Lietotņu būvētāji kļūdās citur

Viss iepriekšējais attiecas uz vienu ceļu: jūs palūdzāt vispārīgam asistentam mājaslapu, un tas iedeva lapu. Šajā ceļā viena faila rezultāts ir likumsakarīgs, jo čata logam nav failu sistēmas. Failu nav kur nolikt, tāpēc nekas par failu arī nekļūst.

Lietotņu būvētājiem, kas veidoti tieši šim darbam, šāda ierobežojuma nav, un šo kļūdu tie netaisa. Palūdziet Lovable, v0, Bolt.new vai Replit, un saņemsiet īstu projektu: komponenšu koku, package.json, būvēšanas soli un failus mapēs. Lovable pamatā ir React ar Tailwind un shadcn/ui, pēc noklusējuma TypeScript, un paša dokumentācija norāda, ka lietotnes, kas veidotas no 2026. gada 13. maija, izmanto TanStack Start ar servera puses renderēšanu, savukārt vecākos React un Vite projektus publiskajās adresēs Lovable renderē iepriekš, lai meklētāju un sociālo tīklu roboti redzētu gatavu saturu. Lielākā daļa šī raksta strukturālās kritikas uz šādu rezultātu neattiecas, un plaši atkārtotais apgalvojums, ka šie rīki meklētājiem rāda tukšu lapu, ir novecojis. Tomēr pārbaudiet, uz kā balstās konkrētais projekts, jo vecāku projektu joprojām ir daudz.

To kļūdas ir citur, un tās ir nopietnākas, jo šie rīki neuzraksta tikai lapu. Tie izveido arī datubāzi.

Lielākais risks ir aizmugurē. CVE-2025-48757, publicēts 2025. gada 29. maijā ar novērtējumu 9,3 jeb kritisks, skan šādi: nepietiekama datubāzes rindu līmeņa drošības politika Lovable līdz 2025. gada 15. aprīlim ļauj attāliem neautentificētiem uzbrucējiem lasīt un rakstīt patvaļīgās ģenerēto lapu datubāzes tabulās. Kļūdu rada vairāki noklusējuma iestatījumi, un katrs atsevišķi šķiet saprātīgs. Jauna Postgres tabula Supabase vidē rindu līmeņa drošību nepiemēro, kamēr kāds to neieslēdz. Ģenerētajās shēmās to neieslēdza. Un Supabase anon atslēga jau pēc dizaina nonāk pārlūkā, jo klients ir paredzēts tieši tā strādāt. Katrs posms atsevišķi ir aizstāvams, bet kopā tie nozīmē, ka datubāze atbild ikvienam, kurš atver izstrādātāja rīkus. Pētnieks, kurš to atklāja, Mets Palmers, saskaitīja 303 galapunktus 170 projektos, kas ir apmēram desmitā daļa no skenētajiem, un tabulas tur bija nolasāmas bez autentifikācijas.

Ievērības vērta ir NVD ieraksta pēdējā rinda: piegādātājs CVE apstrīd, un tā nostāja ir, ka par savu lietotņu datu aizsardzību atbild paši klienti. Lai ko par to domātu kā par komerciālu pozīciju, tas ir šī raksta doma, izteikta ar paša ražotāja muti. Rīks uzbūvē, bet kādam tāpat jāzina, kas jāpārbauda.

Un ekspluatācijas risks. 2025. gada jūlijā Replit aģents izsludināta koda iesaldējuma laikā izdzēsa produkcijas datubāzi, paņemot līdzi datus par vairāk nekā 1200 uzņēmumiem, un pēc tam vēl ziņoja, ka atgriezt tos neesot iespējams, lai gan bija. Replit dažu dienu laikā ieviesa automātisku izstrādes un produkcijas nodalīšanu un atsevišķu plānošanas režīmu, un tā bija pareizā reakcija. No tā neizriet, ka rīks ir slikts. Izriet cits: dot aģentam rakstīšanas tiesības produkcijā ir ekspluatācijas lēmums, un to pieņēma cilvēks, kurš nezināja, ka to pieņem.

Tātad pareizais jautājums ir atkarīgs no ceļa:

• Čata logā ģenerēts HTML. Cik lapa sver, kas paliek kešatmiņā un vai dokumenta galvenē vispār kaut kas ir?
• Lietotņu būvētājs. Kas var nolasīt datubāzi, vai robots redz saturu un vai kaut kam nav rakstīšanas tiesību produkcijā?

Neviens no ceļiem nav bīstams, un neviens nav iemesls tā nebūvēt. Abiem vajag cilvēku, kurš zina, kuri no šiem jautājumiem jāuzdod.

Ko rāda plašākie skaitļi

Mūsu pašu izlase ir maza, bet nozares mērījumi rāda to pašu tendenci.

WebAIM Million 2026. gada pārskatā WCAG 2 neatbilstības konstatētas 95,9 % no miljona apmeklētāko sākumlapu, salīdzinot ar 94,8 % gadu iepriekš, un uz vienu lapu vidēji sanāk 56,1 kļūda, kas ir par 10,1 % vairāk. Sešus gadus pēc kārtas situācija lēnām uzlabojās, bet tagad tendence ir apgriezusies. Paši autori to skaidro ar lielāku paļaušanos uz trešo pušu ietvariem un bibliotēkām, kā arī ar automatizētu jeb AI atbalstītu kodēšanu.

Sešas biežākās kļūdas veido 96 % no visa atrastā: zems teksta kontrasts (83,9 %), trūkstošs alt teksts (53,1 %), formu laukiem nav nosaukumu (51 %), tukšas saites (46,3 %), tukšas pogas (30,6 %) un nenorādīta dokumenta valoda (13,5 %). Neviena no tām nav pamanāma tam, kurš pārbauda, paskatoties uz lapu.

Pēc HTTP Archive 2025. gada datiem mediānā mobilā lapa sver 2,56 MB, kas ir par 8,4 % vairāk nekā gadu iepriekš, un vislielāko daļu no tā veido attēli. Desmit gados lapu svars ir aptuveni trīskāršojies.

Kopš 2025. gada 28. jūnija piemēro arī Direktīvu (ES) 2019/882 jeb Eiropas Pieejamības aktu. Tā attiecas uz e-komerciju, banku pakalpojumiem, transporta biļetēm, telekomunikācijām un audiovizuālajiem pakalpojumiem ES tirgū, un praksē atbilstību vērtē pēc WCAG 2.1 AA, ko ietver standarts EN 301 549. Mikrouzņēmumi (līdz 10 darbiniekiem un līdz diviem miljoniem eiro), kas sniedz pakalpojumus, no pakalpojumu prasībām ir atbrīvoti. Lielākā daļa uzņēmumu, kas lūdz mums publicēt savu ģenerēto lapu, atbrīvoti nav, un lapa ar vienu <h1> un neko tālāk WCAG 2.1 AA neatbilst.

Pārbaude piecās minūtēs bez izstrādātāja

Vispirms pārbaudiet savu lapu, tikai pēc tam kādu citu.

1. Apskatiet pirmkodu. Ar labo peles pogu uz lapas izvēlieties Skatīt lapas pirmkodu un meklējiet base64. Īss atradums ir kārtībā, tas nozīmē, ka būvēšanas rīks iekodējis kaut ko sīku. Atradums, kas stiepjas simtiem rindu, ir fotogrāfija, kurai vajadzēja būt failam.
2. Nolasiet tīkla kopsummu. Atveriet izstrādātāja rīkus, ejiet uz Network un pārlādējiet lapu. Svarīgi ir divi skaitļi: kopējais pārsūtītais apjoms apakšā un pašas pirmās rindas izmērs, jo tā ir HTML dokuments. Tam jābūt desmitos kilobaitu. Ja tur ir megabaiti, viss ir sabāzts iekšā.
3. Nosūtiet saiti paši sev. Ielīmējiet adresi jebkurā čata lietotnē. Ja neparādās ne attēls, ne virsraksts, ne apraksts, Open Graph birku nav, un tieši tā ir izskatījusies katra kopīgošana līdz šim.
4. Paskatieties uz pārlūka cilni. Virsrakstam jābūt lapas valodā, tam jāapraksta lapa, un tā vietā nedrīkst stāvēt tukša frāze.
5. Pārlādējiet ar mākslīgi lēnu savienojumu. Network cilnē uzlieciet ierobežojumu Slow 4G un pārlādējiet lapu. Tā izskatās īsta apmeklētāja pieredze mobilajos datos, un tas ir vienīgais godīgais veids, kā sajust, ko maksā iekšā iekodēta 1,9 MB fotogrāfija.

To pašu sarakstu pārbaudījām šajā vietnē

Mērauklai, ko liekam citiem, jāatbilst arī mums pašiem. Īsumā par visām 164 lapām, ko būvē šī vietne.

Katrai lapai ir meta apraksts, kanoniskā adrese, Open Graph birkas, lang atribūts un tieši viens <h1>. Katram <img> elementam ir alt teksts. Fonti glabājas mūsu pašu serverī WOFF2 formātā, sadalīti ar unicode-range un ar latin-ext iekšā, tāpēc latviešu diakritiskās zīmes zīmē īstais fonts, nevis rezerves. Neviena publiskā lapa nesūta pieprasījumu ne uz Google Fonts, ne uz kādu citu trešās puses failu serveri. Attēli zem ekrāna malas ielādējas ar atlikšanu, un portfolio vāki sev vietu rezervē ar aspect-ratio, tāpēc ielādes brīdī nekas nepārlec.

Kompilētajā CSS ir tieši viens base64 fails, un tas tur ir apzināti: 2028 baitus liela WOFF2 apakškopa, ko būvēšanas rīks iekodē iekšā, jo tā ir zem 4 KB sliekšņa. Šādā izmērā atsevišķs pieprasījums maksā vairāk, nekā ietaupa kešatmiņa. Uz šo atšķirību balstās viss raksts: paņēmiens ir labs, par kļūdu to padara mērogs.

Ko no tā secinām

Uzģenerēt lapu ir pilnīgi saprātīgi. Rezultāts var būt labs, un tas, ko esam lasījuši, tāds arī bija, vismaz tajās vietās, kuras autors spēja redzēt.

Problēma ir tā, ka pārlūka logs ir ļoti slikts mērinstruments. Tas nepateiks, ka apmeklētājs lejupielādē 4,7 MB. Nepateiks, ka kešatmiņā nepaliek nekas, ka jūsu saites kopīgojot parādās kā kailas adreses, ka lapā ir viens vienīgs virsraksts vai ka fonta pieprasījums aizsūta IP adresi trešajai pusei. Cilvēkam, kurš atver failu, tas viss ir izlasāms trīsdesmit sekundēs. Cilvēkam, kurš neatver, tas paliek pilnīgi neredzams.

Tātad ģenerējiet lapu un pēc tam iedodiet to kādam izlasīt. Tās ir pāris stundas, nevis pārbūve, un tieši tur ir starpība starp lapu, kas izskatās pabeigta, un lapu, kas tāda ir.

Ja jums ir lapa, kas ir uzģenerēta un nekad nav pārskatīta, šī izlasīšana ir atsevišķs pakalpojums. Jūs saņemat rakstisku sarakstu, tādu pašu kā augstāk, neatkarīgi no tā, vai labosim mēs.