Miért generátorok statikus oldalak lesznek népszerűek
StaticGen. katalógus statikus weboldalak generátorok, több mint száz generátorok, amelyek megjelentek az elmúlt években, és azt látjuk, hogy a részvény és népszerűsége növekszik GitHub. Kezdetben a projekt során ötven generátorok, most már több mint kétszer nagyobb és összesen több mint 100.000 csillagok GitHub.
Statikus weboldalak nem új - ez az, ahol kezdeni interneten. Akkor miért ez a robbanásszerű érdeklődés vele? Miért történt most?
Times statikus oldalak
Az evolúció a böngészők és HTML statikus weboldalak hiányosságok erősödött.
Kezdetben a weboldalak tartalmazhatnak egyszerű dokumentumokat anélkül, hogy a stílus, de idővel a tervezés került a helyére a helyszínek voltak grafikus fejléc és nehéz navigációt. Ettől a pillanattól kezdve kezelése egyéni oldalt az oldal, mint a különböző dokumentumokat, megszűnt van értelme, és a színpadon sablonozó.
És ugyanolyan gyorsan nyilvánvalóvá vált, hogy a használatát csak a HTML struktúra és CSS stílus nem elég, hogy mentse a tartalmát az oldal (cikkek, termékek, galéria elem) külön a design.
Ekkorra az SQL adatbázis vált a mainstream többféle adatbázisok online cégek váltak szent letéteményesei minden tartalom védett, hosszú szakállú, piros szemű rendszergazdák.
És még ha Dreamweaver bizonyos mértékig integrálható adatbázisok, hiányzott belőle tartalmi modellt, és nem volt szétválasztása tartalom kialakítása, annak ellenére, hogy a független szerkesztő mindkettő.
Problémák a dinamika
Amikor hoztam létre az első dinamikus helyén 15 évvel ezelőtt, követtem az utasításokat a LAMP a MySQL dokumentációt. Amikor rájöttem, hogy az egész interakciók sorrendjét LAMP fut minden alkalommal, amikor valaki felkeresi a webhelyet, ez megdöbbentett.
A webszerver kell betölteni a kódomat a PHP motor menet közben, majd csatlakozik az adatbázishoz, küldhet és fogadhat kéréseket, majd sablonok, majd ezeket a sorokat a HTML-dokumentum készült, különösen az aktuális felhasználó számára. Finom!
De csodálat csökkent, amikor meglátogattam a helyén egy-két év múlva, és látta, hogy egy oldalt üzenetet egy hacker, aki megtalálta a biztonsági réseket konfigurációs elegendő olvashatatlanná a honlapon (és ez jobb, mint a hacker az oldalon, és aztán elterjedt rosszindulatú szoftver).
Mi nagy árat fizetnek a beépített összetettsége dinamikus weboldalak, feldolgozás minden kérés a szerveren - és ez az ár nem feltétlenül fizet, ha ez a bonyolultság nincs szükség.
Dinamikus oldalak és a cache-
Bizonyos mértékig ez a probléma megoldódott a gyorsítótár. Egyik népszerű WordPress honlap nélkül nem plugin WP Super Cache lehetőséget. Nagy oldalak használata proxy gyorsítótár, például lakkok, nginx és Apache Traffic Server.
Gyorsítótárral elég nehéz megfelelően beállítva, de még a leginkább optimalizált dinamikus helyén normál körülmények között sokkal lassabb lesz, mint a statikus.
Smashing Magazine létrehozott egy csapat összpontosított termelékenység és általában komolyan optimalizált erre a célra. Töltöttem rajta egy kis kísérletet ezt a cikket. Használata HTTrack. Én pumpált az oldalon, és aztán egy statikus változatát Netlify - a platform hosting statikus alapján CDN. Nem csináltam semmit, hogy javítsa a teljesítményt a statikus verzió - egyszerűen tedd a tárhely, mélyen integrálódott a CDN.
Smashing Magazine gyorsabb, mint a legtöbb helyen, de kezeli az összes lévő azonos adatközpontban. (Nagyobb változat)
Aztán futott néhány vizsgálatot, hogy kiderüljön, miként befolyásolja az első bájt a beáramlási sebessége és abban az időben a teljes terhelés index.html oldalt. És ez az, amit azt mutatta a műszer, hogy ellenőrizze a teljesítményt a Sucuri.
Még magasan optimalizált dinamikus hely veszít átlagosan 6-szor a statikus változatát. Figyelembe vesszük, persze, hogy nem mindenki fog adni egy statikus tárhely ilyen különbség, de még egy dinamikus weboldal CDN egyszerűen nem összehasonlítható a teljesítmény nélküli kézi beállítás általában járó különböző furcsaságokat származó cache-t.
Statikus oldalak alapvetően különbözik ebben a tekintetben. caching elv egyszerű: az egyes URL adja ugyanazt a HTML minden felhasználó előtt a fájlt, amíg a megfelelő URL-t frissíteni fogják kifejezetten.
Munka egy ilyen elv caching szab bizonyos korlátozások a tervezés, de a létrehozása után az oldal az összes fizeti ki a termelékenység és a tárhely ára.
Modern generátorok statikus honlapok
Nemrég egy alternatívája a hagyományos dinamikus oldalak szerzett valódi alakját. Az ötlet egy statikus oldal generátor nincs semmi új. Még hosszú ideig versenytárs WordPress, egy tartalomkezelő rendszer Mozgatható típusa lehetősége van létrehozni egy statikus oldal.
Google Trends kérésre „statikus honlap generátor”. (Nagyobb változat)
Azóta sok megszorítások statikus oldalak, irrelevánssá válik, és a modern generátorok versenyképes motorral, középpontjában elsősorban a frontend fejlesztők.
Minden héten statikus weboldalak generátorok egyre nehezebb lépést tartani egyre őket. Általában az összes népszerű generátorok, statikus oldalak a következő tulajdonságokkal rendelkeznek.
Az a képesség, hogy osztja a területet külön réteget és fragmentumok, az ismétlések elkerülése végett az egyik az alapokat egy statikus oldal generátort. Van egy választás a különböző sablonok motorok, mindegyiknek megvan a saját jellemzői - némelyik nincs logika a sablon van keverve más kódra, de elkerülhető a párhuzamos fejléc, lábléc, navigáció és mások.
Támogatás Markdown
A legtöbb statikus generátor támogatja Markdown. Néhány használ hasonló reStructuredText típusú formátumokat. Általánosságban elmondható, hogy lehetővé teszi, hogy írjon egy egyszerű szöveges strukturált módon.
metaadatok
Jekyll megalapozta a generátor statikus site: sablonok és Markdown mi minden.
Amikor GitHub alapító Tom Preston Werner írt Jekyll a magatartás blogján, talált egy nagyon érdekes megoldás bemutatása metaadatok dokumentumok és sablonok Markdown: kalap.
A bevezető részben kis mennyiségű metaadatok, általában a YAML formátumban található a legelején a dokumentumot:
Bevezető egyszerűsített létrehozására kommentárok az egyszeres iratait, és ad egy egyszerű szöveges formátumban olvasható az összes adat, általában szétszórva különböző adatbázis táblákat.
Fayloprovod (Eszköz Pipeline)
Frontend ma lehetetlen anélkül szerelési rendszerek és fordítóprogramok. Azt akarjuk, hogy összekapcsolják és tömöríti a fájlokat. CSS előfeldolgozó már nem egy játék Geeks, részeként a szokásos munkafolyamat. Ugyanez vonatkozik a CoffeeScript és ECMAScript 6, amelyből a szükséges fordítóprogramok.
A legtöbb generátorok statikus oldalakat már benne fayloprovod, azaz az összeállítási rendszert, minimalizációs, összeszerelés és egyéb feldolgozási erőforrásokat. Némelyikük típusa alapján a gyülekezési rendszerek Grunt, Culp vagy brokkoli és így közvetlen hozzáférést biztosít az összes jellemzőit az ökoszisztéma. Egyéb optimalizálása egyes munkafolyamatokhoz bocsátása „out of the box” nem konfigurációt. Sok generátorok szabvánnyá vált a böngésző automatikusan frissíti, ha a fájlok mentését.
Összefoglalva
Generátor statikus oldal általában egy parancssori felületet a szerelés helyén vagy futtatni a helyi szerver fejlesztése.
A Jekyll Jekyll építmények csapat. fog készíteni a helyszínen a meglévő projekt fájlt, és tegyük egy alkönyvtárba.
Itt vannak a közelítő szerkezet a helyén forrás:
A mappa _site ezen források is készülj a helyszínen, hogy lehet letölteni a statikus vagy hagyományos tárhely.
Miért fontos most?
OK, egyetértenek abban, hogy a termelők a statikus oldalak nagy. De miért ez a hullám történt most, és miért korai generátorok nem tudták, hogy engedélyezi semmit mellett WordPress? Mi változott meg? És milyen messzire megy?
Modern generátorok statikus munka az ökoszisztéma teljesen különbözik attól, amit korábban volt. Sok korlátozások, amelyek dinamikus weboldalak nélkül maradt, minden sokkal bonyolultabb, mint egy online kiadvány, eltűntek, bár néhány maradt.
böngészők megváltoztak
Ma mi vagyunk jelen az ünnepélyes temetés utolsó a régi iskola böngészők (RIP, IE8). A modern böngésző gyakorlatilag az operációs rendszer, nem csak mutatja az internetről letöltött dokumentumok, és képes futtatni teljes értékű web alkalmazások, amelyek a kimenő hívások bármely összeegyeztethető CORS API, az adatok tárolására helyben, nyisson meg egy webillesztőpontok és még kezelni a peer-to-peer kapcsolat más böngészők keresztül WebRTC.
És még sorolhatnánk - egy egész ökoszisztéma tisztán böngésző kiterjesztés már létrejött. Ezen kívül, a modern webes alkalmazások alapján Ember.js, AngularJS vagy reagálnak gyakran helyezik a statikus weboldalak közvetlenül a CDN tisztítható az API kötőhely interfész a mobil kliens.
CDN vált mainstream
Míg Akamai ára még mindig magas ma bárki megengedheti magának, hogy az Amazon AWS CloudFront illetve honlapján. Emellett vannak olyan cégek, mint a fastly, MaxCDN CloudFlare és biztosítja CDN szolgáltatás elérhető áron a kisvállalkozások számára.
Használhatja a CDN egy dinamikus oldal, de te a problémával küzd, a cache érvénytelenítés. Közötti egyensúly megtalálása az egyes csomópontok cache és dinamikus háttér van szükség, mert egy meglehetősen bonyolult számításokat, hogy mondjuk a legkevésbé.
Statikus oldal viszont kész elhelyezése közvetlenül a CDN, és így az átadása cache csomópontok a lehető legközelebb a végfelhasználók számára. Configuration természetesen némi időt vesz igénybe, és a cache érvénytelenítés nehéz - de ezek a célok megvalósíthatók és teljesen automatizált Netlify típusú szolgáltatásokat.
Teljesítmény az első helyen
A mobil eszközök változtak az interneten különböző módon. Egyre több felhasználó az internet a mobil, néha egy 3G kapcsolat. És soha nem a teljesítménye nem volt itt olyan fontos.
Nem számít, hogy mennyit optimalizálja a dinamikus weboldalt, és hány ezer dollárt költ rá - akkor soha nem éri el ugyanazt a teljesítményt, mint egy megfelelően konfigurált statikus oldalakat házigazdája CDN pár dollárt egy hónapban. Tekintettel a folyamatos javítása a teljesítmény nem meglepő, hogy a fejlesztők keresik a módját, hogy előre generálni HTML, és nem vesztegeti az időt és forrásokat a szerveren, hogy létrehoz a oldal minden egyes HTTP-kérés.
Generációs statikus site is megoldja a sok probléma a folyamatban fejlődő teljesítményét.
Ha létrehoz egy dinamikus webhely adatbázis alapján, az Ön számára nagyon fontos hatékonyságát adatbázis lekérdezés, akkor gyorsnak kell lennie ahhoz, hogy egyszer kell elvégezni, minden egyes HTTP-kérés. Még ha a webhely megfelelő szintű gyorsítótárat mindig van kockázata, hogy az egyes kérések terheljék feleslegesen a cache, és fokozatosan lassul az egész rendszert.
Folytatódott az olyan eszközök szerelési
Legutóbb, fordító és építmények rendszer csak az érdekli, C és Java programozók, és nem érinti a folyamat a weboldalak létrehozása. De minden megváltozott most, akár tetszik, akár nem.
Ma frontend fejlesztők az igényeikhez igazított építeni rendszer csomag vezetők, fordítóprogramok, és a fordítók. Az egész kezdődött Grunt, most ezeket a dolgokat lett az alapja a legtöbb új projektek.
A dominancia szerelő rendszerek, generátorok, statikus oldalak váltak több természetes része a front-end design és a hagyományos PHP-rendszer dinamikus webhely furcsán egy modern munkafolyamat frontend.
Mi hiányzik
Mindezek a tényezők létre kiváló feltételeket a növekvő népszerűsége statikus oldal generátorok és ez nem meglepő, hogy egyre több és több telek is lesz állandó.
De nem minden ilyen egyszerű. Hogy végre beköltözik a mainstream, generátorok statikus szükséges az áttörés több területen.
Kiválasztása egy statikus oldal generátort és a kezdete a projekt továbbra is meglehetősen problematikus az első alkalommal. Ott sokat javult, hiszen a befejező eszközök és a dokumentáció és a rendelkezésre álló erőforrásokat.
Annak ellenére, hogy a gyors növekedés az infrastruktúra körüli generátorok statikus oldalak, még mindig jelentősen elmarad a nagy üzlet, és a támogató szolgáltatásokról hagyományos dinamikus platformokon.
Ezért sok helyen gyűjtik generátorok statikus végül vándorolnak dinamikus CMS. Szüksége van egy híd köti össze a tartalmát a vezetők és a sztatikus helyszíni rendszer. Amíg ez megtörténik, akkor a létrehozott statikus oldalakat fogja elfoglalni egy kis rést.
Vannak más érdekes megoldások nélkül CMS. Verge használ Google-táblázatok a tartalom réteg Middleman; StaticGen használ lényegi és GitHub API adatbázisként csere, és sárgarépa használ tartalmas statikus CMS - mindez lehetővé teszi a felhasználóknak, hogy a munka egy egyszerű statikus oldal keletkezik.
Tartalmas típusú rendszer. Prismic.io. GatherContent eltávolítjuk a CMS web fejlesztési folyamat. És ez teszi őket érdekessé eszközök többcsatornás tartalom menedzsment, amikor írsz tartalom, nem csak egy bizonyos oldalon, hanem a mobil alkalmazások, social network oldalak, vagy egyéb célra. A kiadvány az új tartalmat indít szerelési rendszer; majd egy statikus oldal generátor adatokat olvas be az API és a gyülekezési hely; A kész eredmény küldött közvetlenül a CDN.
Egy másik módszer a tartalom szerkesztését dolgozik közvetlenül a fő tároló.
A Netlify fejlesztett nyílt forráskódú CMS. hozzákapcsolva különösebb generátor statikus oldalakat vagy hosting. A cél az, hogy működjön együtt a legtöbb statikus generátorok, és úgy gondoljuk, ez egy nagyszerű módja annak, hogy túllépnek a korlátokat, a modern statikus weboldalak szerelési technológiák.
Nyilvánvaló, hogy mindig lesznek helyek, hogy sztatikus motor nem alkalmas elvileg - különösen azokat, amelyek tartalmát folyamatosan frissítjük sugárzott, vagy azok, amelyek tartalma nagymértékben függ a keresési és a szűrés.
Mint említettük, a generátorok statikus oldalak továbbra is épít a kapacitás és a népszerűsége. Az infrastruktúra és az ökoszisztéma alakul ki. És a javulás a szerszámok, kiderül, hogy a fejlesztők határainak kitolása mi valósítható generátorok statikus oldalakat.
A Netlify látjuk, hogy milyen nagy weboldalak tartalom, keresés, valós idejű többnyelvű és saját szakaszok alkalmazásával gyűjtjük statikus API és generátorok. Megvalósításával a termelékenység növelése fontos a biztonság, azt várjuk, hogy mi lesz, hogy sokkal több.