@ -279,15 +279,48 @@ Práce se věnuje pouze technickým optimalizacím spojených s tvorbou samotné
\subsection{Typy a kvalita obrázků}
\subsection{Typy a kvalita obrázků}
Fotografie a grafika využívají mnohem více dat pro přenos než běžný HTML text a je tedy nutné provést optimalizaci (kompresi) obrázků na co nejmenší možnou velikost souborů. Obrázky není třeba renderovat na více než 72 dpi a pro každý druh grafiky je třeba zvolit vhodný tofmát, tj. formát JPEG pro fotografie a formáty PNG či SVG pro jednoduchou grafiku. Rastrové obrázky mají pouze potřebné rozlišení, tedy maximálně hodnotu největšího rozlišení, které se ve stránce bude zobrazovat. Klíčové je také nevyužívat obrázky v případě, kde je lze nahradit čístým HTML a CSS.
Obrázky ve formátu JPEG mají velice efektivní ztrátovou kompresi, pomocí které lze zredukovat velikost obrázku o značnou část. Autor článku tvrdí, že většinu obrázků lze komprimovat až o 50\% bez viditelné ztráty na kvalitě. Své obrázky dokonce zkomprimoval ze 27 kilobajtů na pouhých 8 kilobajtů s JPEG kompresí 60\%.
\subsection{Ikona \textit{favicon.ico}}
\subsection{Ikona \textit{favicon.ico}}
Původně je \textit{favicon.ico} výtvorem firmy Microsoft, kdy její Internet Explorer automaticky odesílal požadavek na pevnou URL \textit{/favicon.ico} od kořene webového serveru. Jde o malou ikonku, která se dnes zobrazuje u každé záložky s webovou stránkou. Problémem je to, že se požadavkům o ní nelze vyhnout a vždy se počítá s tím, že ikona na web serveru existuje. Odesílá se vždy s každou stránkou a některé prohlížeče se po ní dotazují z neznámých důvodu dvakrát. Autor článku uvádí, že u některých serverů bylo až 30\% přenesených dat využito jen na servírování ikony.
Principem optimalizace je udržet ikonu ji co nejmenší, v nejlepším případě tak malou, že se vejde do jednoho TCP paketu, tedy do velikosti 1460 bajtů na většině systémů. Toho lze docílit tím, že ikona nebude větší než 16x16 pixelů s nízkou barevnou hloubkou, nejlépe s pouze čtyřmi barvami. Také je možné poslat pouze 1x1 pixelů veliký prázdný obrázek, nebo vracet stavový kód 204\footnote{204 No Content -- Server úspěšně zpracoval požadavek, ale nevrací žádný obsah.} a neodesílat ikonu žádnou.
Redukcí nepotřebných znaků v HTML lze také ušetřit značnou část přenosu dat. Dobrými praktikami mohou být:
\begin{itemize}
\item nepoužívání HTML komentářů,
\item využití CSS pro formátování stránek,
\item využití oddělovače nebo elementu \texttt{span} namísto tabulek,
\item odstranění přebytečných tagů a prázdných mezer a řádků,
\item vytvoření obrázkových náhledů namísto odesílání obrázků v plném rozlišení,
\item recyklování již použitých obrázků a tlačítek.
\end{itemize}
K odstranění přebytečných mezer, zalomení řádků, HTML komentářů a prázdných řádků lze použít automatický filtr, který provede kompresi výstupu. \todo{Přesunout do návrhu pro rozšíření?}Generátor Zola provádí kompresi CSS, ovšem nemá zabudovanou funkcionalitu pro minifikaci výsledného HTML, která je ovšem v době psaní této práce vyvíjena\footnote{\url{https://github.com/getzola/zola/issues/542}}.
Touto redukcí lze ušetřit 2\% přenosu dat oproti ručně psanému neoptimalizovanému kódu. Je-li průměrná velikost stránky sto kilobajtů, lze touto optimalizací ušetřit dva kilobajty při každém odeslání stránky. Při odeslání sta tisíce stránek za měsíc je ve výsledku ušetřeno dvě stě megabajtů dat, které jsou jinak zbytečně odesílány uživatelům, kteří je stejně nezobrazí.
Další obecné rady pro optimalizaci HTML jsou uvedeny na serveru \cite{yahoo_optimization}, kde se uvádí spousta dalších způsobů ke zrychlení načítání stránky a k nižšímu vytížení sítě.
Připojením externích CSS a JavaScript souborů je umožněno jejich ukládání do paměti cache, což snižuje HTTP požadavky vůči serveru. Je-li obsah těchto souborů přímo ve stránce, je odesílán pokaždé s novou stránkou a to vede ke zbytečnému vytěžování sítě. S tím souvísí i velikost stránek, kdy soubory větší než je daná maximální velikost se do paměti cache neukládají a je proto dobré tuto velikost nepřekračovat.
\quest[inline]{U starých zařízení jsou pevně dané velikosti, například v roce 2011 byly limity 25.6K u iOS nebo 5M u Firefoxu. Mám je zde uvádět, i když se to rychle mění, nebo to stačí takhle obecně?}
Připojením externího CSS přímo do hlavičky je umožněno progresivní vykreslování webové stránky, které urychluje \uv{Time To First Byte}, viz sekce \ref{kap:vyhody-statickych-webovych-stranek}. Naopak umístěním případných JavaScript souborů až na konec celé stránky se prioritizuje načítání viditelného obsahu před méně důležitými skripty.
Je také důležité udržovat validní HTML, kdy například chybějící atribut \texttt{src=""} způsobuje odesílání nevyžádaných požadavků na server.
\quest[inline]{HTML5 už specifikuje, aby prohlížeče kvůli prázdnému \textit{src} neposílaly další požadavaek. Je tedy nutné uvádět tento příklad?}
\subsection{Videa a jejich vložení do stránky}
\subsection{Videa a jejich vložení do stránky}
\todo[inline]{Váhody CDN a problematika sledování uživatelů.}
\todo[inline]{Výhody CDN a problematika sledování uživatelů.}
