Lapa izskatās labi. Mēs atvērām kodu.

Mājaslapas mums mēdz atnākt jau uzbūvētas. 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 uzlikt uz īsta domēna, papildināt vai iekļaut lielākā vietnē. Pirmais, ko darām, ir atveram failu.

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

Uzreiz jāpasaka: tas nav arguments pret to, ka lapu uzģenerē pats. Daļa no koda, ko esam lasījuši, bija labāka nekā krietns daudzums ar roku rakstīta koda, un zemāk mēs to nosaucam vārdā, jo nopelns pienākas. 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ī aizceļo līdz produkcijai.

Ī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. Šis viens lēmums velk sev līdzi vēl četrus. 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, klusāks 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, kuru viss izplatīšanas plāns ir cilvēki, kas 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.

Viens fails, un viss iekšā

Atverot ģenerētu lapu, tur parasti nav ne assets mapes, ne stila faila, ne attēlu direktorijas. 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, atkodēti	3,35 MB
Tie paši faili kā base64 teksts	4,47 MB
Lielākais viens 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 ir vērts saprast, kāpēc tā sanāk. Rīks piedāvā vienu teksta lodziņu. Failu nav kur nolikt, tāpēc viss kļūst par tekstu. Cita arhitektūra vienkārši nav pieejama, lapa atveras nevainojami, un tāpēc šāds fails aizceļo līdz pat produkcijai.

Ko tas maksā

Base64 sver apmēram par trešdaļu vairāk nekā tas, ko tas kodē. Trīs baiti tiek pierakstīti 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 sākuma punktu vairs nesasniegsiet.

Kešatmiņā vairs nepaliek nekas atsevišķi. Pārlūks kešo 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. Otrā virzienā ir vēl sliktāk: 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ē zīmēšanu, un šeit stila failā guļ fotogrāfijas. Parseris izlasa megabaitus kodēta teksta, pirms uzzīmē pirmo pikseli. Turklāt tieši to, kam būtu jāielādējas pirmajam - lielo attēlu lapas augšā, kas gandrīz vienmēr ir Largest Contentful Paint elements - nevar ne ielādēt uz priekšu, ne prioritizēt. Tas vairs nav resurss, tā ir 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. Četrdesmit viens attēls zem ekrāna malas ir jāsamaksā pilnā apmērā, 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 tam pāri formatētāju vienu vienīgu reizi, un kodētie dati izklāsies pāri miljoniem 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 noņem 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 pārdzīvo katru nākamo teksta labojumu.

Godīguma pēc jāpiebilst, ka izņēmums pastāv: 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šā paņēmienā. Vaina ir mērogā. Divus kilobaitus liela ikona iekšā ir apzināts kompromiss, 1,9 MB fotogrāfija iekšā ir kompromisa neesamība.

Fonti, kur tas pats lēmums sāp visvairāk

Uz katru kilobaitu fonti no viena faila pieejas cieš vissmagāk. Lasītajos failos bija trīs atsevišķas 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ā visa fonta izsniegšana visiem ir norma, un vajadzīga tā nav nekur. 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 dzīvo latin-ext. 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, aizgūto burtu izskats, 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ā tika ielādēts no Google Fonts CDN. Tā samaksā divreiz: par iekodētā fonta svaru un vēl par pieprasījumu uz trešo pusi.

CDN pusei Eiropā ir arī juridiska aste. 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 uz sava servera, jautājums nerodas vispār, un lapa ielādējas ātrāk.

Galvene, ko neviens neuzraksta

Otrs trūkums ir klusāks, un 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.

Ko pievienojam mēs. Tas ir fiksēts saraksts, nevis vērtējuma jautājums:

<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ās vēl pirms attēla ielādes. Un <title> tajā valodā, kuru pieteic lang atribūts.

Virsraksti kā izmēri, nevis kā struktūra

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 korekta koda, un par to jau ir viss šis raksts. Strukturāli tā ir lapa bez satura rādītāja. Ekrāna lasītāja lietotājs, kurš pārvietojas pa virsrakstiem, un neredzīgiem cilvēkiem tas ir viens no galvenajiem veidiem, kā pārvietoties pa lapu, 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.

Kas bija labi, un labi bija daudz kas

Audits, kurā uzskaitītas tikai kļūdas, ir slikts audits, un tas nepareizi atspoguļotu izlasīto.

• Katram no tiem 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.

Cits ceļš, citas kļūdas

Viss iepriekšējais attiecas uz vienu ceļu: jūs palūdzāt vispārīgam asistentam mājaslapu, un tas iedeva lapu. Šis ceļš viena faila artefaktu rada paredzami, un iemesls ir strukturāls - čata logam nav failu sistēmas. Failu nav kur nolikt, tāpēc nekas par failu arī nekļūst.

Speciāli veidotajiem lietotņu būvētājiem šā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ākie React un Vite projekti publiskajās adresēs tiek renderēti 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 ir vērts pārbaudīt, uz kura pamata konkrētais projekts stāv, jo vecākais joprojām ir apgrozībā lielā daudzumā.

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

Aizmugure ir tā, kas sāp. 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. Mehānisms ir ķēde no saprātīgi izskatošiem noklusējumiem. 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 tieši tā klients ir domāts 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: CVE ir apstrīdēts no piegādātāja puses, un viņu 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ē. Kādam tāpat jāzina, kas jāpārbauda.

Un operacionālais gals. 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. Mācība nav tāda, ka rīks ir slikts. Mācība ir tāda, ka aģents ar rakstīšanas tiesībām uz produkciju ir operacionāls 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 kas ar rakstīšanas tiesībām nav pavērsts pret produkciju?

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

Ko rāda plašākie skaitļi

Mūsu pašu izlase ir maza, un izlikties citādi nav vērts. Nozares mēroga mērījumi rāda to pašu virzienu.

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. Pēc sešiem gadiem pēc kārtas ar lēnu uzlabošanos tendence ir apgriezusies otrādi. 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 praktiskais standarts ir WCAG 2.1 AA caur EN 301 549. Mikrouzņēmumi, kas sniedz pakalpojumus, proti, līdz 10 darbiniekiem un līdz diviem miljoniem eiro, no pakalpojumu prasībām ir atbrīvoti. Lielākā daļa uzņēmumu, kas lūdz mums uzlikt savu ģenerēto lapu, atbrīvoti nav, un virsrakstu struktūra ar vienu <h1> un neko tālāk nav WCAG 2.1 AA lapa.

Piecas minūtes, un izstrādātājs nav vajadzīgs

Palaidiet šīs pārbaudes vispirms uz savas lapas, tikai pēc tam uz kāda cita.

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 pats 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.

Tas pats saraksts, palaists uz šīs vietnes

Būtu slikts raksts, kas uzstāda mērauklu, pēc kuras autors pats nedzīvo. Tāpēc, īsi par visām 164 lapām, ko šī vietne uzbūvē.

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 uz mūsu pašu servera 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 neveic 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 nepalec.

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. Tieši uz šīs atšķirības viss raksts arī balstās: paņēmiens ir labs, un par kļūdu to padara mērogs.

Īstā mācība

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 - 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īgojas 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 tad iedodiet kādam to 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 tika uzģenerēta un nekad nav pārskatīta, šī izlasīšana ir atsevišķs pakalpojums. Rezultāts ir rakstisks saraksts, tāds pats kā augstāk, neatkarīgi no tā, vai labojam mēs.