Od vytvoření internetu se průměrná velikost souborů stále zvyšuje. To, co začalo jako kilobajty, postupovalo na megabajty (ano, množné číslo) a naše soubory stále rostou.

Zatímco tento fenomén není na první pohled znepokojivý, dopad na výkon a udržovatelnost je strašný. Přidejte do starých zařízení, omezení šířky pásma nebo pomalé rychlosti obecně ... a máme mnohem větší problém.

Naštěstí máme kontrolu nejen o velikosti souborů, ale také o tom, jak jsou naše stránky vykresleny v prohlížeči. Tento druh kontroly dává vývojářům webu, jako tomu u nás, šanci pomoci zmírnit tento problém a optimalizovat náš kód pro lepší výkon v tomto procesu.

Proč se obtěžovat?

Úplně chápu nedostatek zájmu, když většina internetových připojení v USA je v dnešní době poměrně rychlá. Myslím tím, jestli všechno funguje dobře, proč se trápit?

Výkonnost a optimalizace jsou o tom víc, než jak rychle můžeme stáhnout obsah. Existuje také poměrně málo SEO a UX přínosů, které mají být tím, že si čas podívat se na náš kód. Nemluvě o tom, že snížení velikosti souborů optimalizací našeho kódu pro lepší výkon má přidanou výhodu snížení našich nákladů na šířku pásma jako hostitelů a snižuje využití šířky pásma (myslet ISP / cellular data caps) také na uživatelské úrovni.

Modulární myšlení je prvním krokem

Modulární kód obvykle přidává nadměrný stav ve formě více možností. Zde chceme přemýšlet o modulárním způsobu, jak kombinovat co nejvíce obyčejných částí našeho kódu. Pokud můžeme kombinovat dvě třídy CSS do jednoho a použít méně kódu pro dosažení stejného výsledku, měli bychom.

Modularita není tak důležitá, pokud jde o základní HTML a CSS, ale když se dostanete do složitějšího světa JavaScriptu, může mít příliš velké nadhazování možnost ublížit vám - zejména na mobilních zařízeních.

Minimalizujte požadavky na protokol HTTP a závislost

Požadavky na závislost jsou zdaleka největším faktorem při zpomalení většiny rychlostí načítání stránky. Každá další žádost přidává do procesu parsování a stahování další vrstvu složitosti. Je často snadné zapomenout, že volání obrázků z vašeho stylu se také počítá stejně, takže je určitě omezte a použijte alternativní metody optimalizace, jako jsou například sprites nebo SVG, pokud je to možné.

Zatímco jsme na téma externích závislostí, pokud jsou vaše webové stránky dostatečně velké, aby vyžadovaly minimálně desítky žádostí ... Může to být čas, abyste zvážili použití CDN. Použití CDN k distribuci obsahu nebude snižovat velikost souborů a / nebo načítat časy stejně jako odstranění dalších požadavků HTTP dohromady, ale pravděpodobně odstraní jakékoli pomalé připojení serveru z rovnice přinejmenším.

Výrobní a vývojové prostředí

Při srovnávání vašich vývojových a výrobních úrovní kódů by měl být velmi zřejmý rozdíl. Pokud učiníte tento krok sám, může někdy zaznamenat největší pokles velikosti souborů po celé ploše.

Dnes je typické vidět, že vývojáři odkazují na jejich "produkční" nebo "vývojové" prostředí, a to zejména na rozsáhlé projekty. Ale je také užitečné i na menším konci věcí. Největší rozdíl mezi těmito dvěma prostředími lze vidět pomocí komprese obrazu a minimalizace / komprese kódu. Nakonec chceme, aby naše výrobní prostředí bylo co nejrychlejší a co nejrychlejší, zatímco naše vývojové prostředí by mělo být stejné, pouze s výjimkou optimalizace komprese obrazu a kódu.

Použití vestavěných nástrojů, jako je například komprese "Uložit pro web" aplikace Photoshop, může být dobrým výchozím bodem pro obrázky. Existuje spousta vědomostí prozkoumány jinde stejně jako rozhovory o obrázkových formátech, kompresních algoritmech, kontrole kvality a osvědčených postupech.

Pro kód nejlepší využití komprese obvykle závisí na jazyce, se kterým pracujete. Je také velmi diskutabilní, zda komprese kódu pomáhá nebo ubližuje ostatním lidem, kteří se snaží pochopit váš kód, ale je to další rozhovor. Pokud jde o prostý HTML a CSS, používám služby jako Htmlcompressor společnosti Google a Kompresor YUI pro CSS.

Napište inteligentnější a čitelnější kód

Někdy kód, který píšeme, je nejpomalejším článkem řetězce. Neaktivní CSS nebo nafouknutý JavaScript může ublížit načítacím časům více, než si myslíte. Tento Mozilla příspěvek jde do velké podrobnosti o významu psaní štíhlé CSS selektory a vysvětluje, jak prohlížeče vykreslují. Stručně řečeno, psaní přesné cesty dolů řetězce selektorů je mnohem méně efektivní než jednoduše pomocí nejmenšího jedinečně identifikovatelného selektoru. Oba směrují styl na stejný prvek, ten druhý jednoduše dostává práci hodně, mnohem rychleji.

JavaScript může být ještě horší než špatně napsaný CSS a v mnoha případech je snadno přehlížen. Kolikrát jste do vašeho projektu zkopírovali a vložili do knihovny externí JS knihovnu, aniž byste se skutečně dívali do hloubky na samotném zdroji? Typekit je skvělým příkladem toho, protože když se jejich servery zastaví, mohou přenést webovou stránku pomocí svých písem na kolena a způsobit dodatečné 30 sekund nebo dokonce i několik minut dalšího načítání.

Naštěstí se takové události vyskytují zřídka, ale je stále dobré, pokud je to možné, volat JavaScript, pokud je to možné, jako v případě služby Google Analytics. Tímto způsobem umožňuje prohlížeč analyzovat soubory hlav (CSS, HTTP požadavky atd.) A zobrazit značku, než začne JavaScript spouštět věci dole.

Udržujte HTML velmi jednoduché

V souladu s naším cílem psát štíhlejší CSS selektory a udržet nabobtnalost na minimum, psaní efektivního HTML by také mělo být prioritou.

Resetování CSS se často zaměřuje na všechny běžné prvky a na nich vynucuje stylování "resetování". Takže i když nejste zaměřeni na tuto extra div, je pravděpodobné, že stále zpomaluje věci tím, že musí mít své padding a okraj resetovat na minimum. Typicky, další div nebo dva nic neublíží. Teprve když začnete končit desítkami z nich, dělají věci bláznivé. Se zavedením dalších prvků do specifikace HTML5 máme také v této oblasti mnohem větší flexibilitu.

Google se mu líbí, když píšeme čistší kód

Společnost Google dává přednost tomu, aby se internet shromažďoval do tvaru. Kvůli obsazení významných pozic ve výsledcích vyhledávání musí stránky nyní věnovat kritickou pozornost mnoha různým atributům o tom, jak jsou vykresleny. Volání příliš mnoha externích zdrojů, s absurdně velkými obrazy nebo dokonce s špatně napsaným javascriptem může vést k vyřazení stránky.

Naštěstí je to vše s dobrým úmyslem, protože jejich požadavky na kvalitní vyhledávací hodnocení jsou postaveny na dobrých vývojových postupech. Google také nabízí velmi hluboký průvodce k optimalizaci různých aspektů vašeho webu pro lepší SEO - což zároveň podporuje fantastické vývojové praktiky současně.

Závěr

Při optimalizaci našeho kódu musíme nejen uvažovat o velikosti souborů, ale také zvážit, jak to bude číst; buď prohlížeči, nebo dokonce jinými lidmi. Mobilní použití by mělo být také vzato v úvahu, přičemž mnoho poskytovatelů služeb vynucuje v dnešní době velmi omezující omezení dat.

Ačkoli to může trvat dodatečný čas k provedení této optimalizace, to je určitě užitečné úsilí, protože to nejenže nabízí lepší výkon v prohlížeči a na mobilní, ale také má šanci podporovat lepší rozvojové postupy a dokonce získat váš obsah vyšší hodnost na vyhledávačích, jako je Google.

Příště se připravujete na spuštění, hodíte své snímky na kompresní motor ... Možná vás překvapí, kolik megabytů se může oholit!

Doporučený obrázek, modulární obraz rychlosti přes Shutterstock.