Úpravy dle poznámek doktora Procházky
This commit is contained in:
parent
c12f30be2f
commit
fb0f295835
@ -42,7 +42,7 @@ Jak popisuje \cite{carsten_dominik} ve svém krátkém technickém popisu, Org-m
|
||||
|
||||
\subsection{reStructuredText}
|
||||
|
||||
Tento jazyk, známý také jako ReST, je, stejně jako Markdown, zároveň syntaxí i parsovacím systémem syntaxe pro tvorbu dokumentů a webových stránek. Svou oblibu získal hlavně v~komunitě jazyka Python. Ve své dokumentaci\footnote{\url{https://docutils.sourceforge.io/rst.html}} je popisován jako syntaxe pro využití ke psaní \textit{Python docstrings}\quest{uvozovky, italic, nebo nic?} a dalších druhů dokumentace, která je spolehlivá a jednoduchá. ReST vznikl v~návaznosti na jazyk StructuredText, který trpěl mnoha nedostatky. Cílem jazyka reStructuredText je tyto nedostatky opravit a doplnit. \citep{problems_with_structuredtext}
|
||||
Tento jazyk, známý také jako ReST, je, stejně jako Markdown, zároveň syntaxí i parsovacím systémem syntaxe pro tvorbu dokumentů a webových stránek. Svou oblibu získal hlavně v~komunitě jazyka Python. Ve své dokumentaci\footnote{\url{https://docutils.sourceforge.io/rst.html}} je popisován jako syntaxe pro využití ke psaní \textit{Python docstrings} a dalších druhů dokumentace, která je spolehlivá a jednoduchá. ReST vznikl v~návaznosti na jazyk StructuredText, který trpěl mnoha nedostatky. Cílem jazyka reStructuredText je tyto nedostatky opravit a doplnit. \citep{problems_with_structuredtext}
|
||||
|
||||
Lze se s~jazykem setkat u~značné části existujících generátorů statických webových stránek, z~nichž některé jsou zmíněny v~kapitole \ref{kap:paradigmata}.
|
||||
|
||||
|
@ -311,7 +311,7 @@ Redukcí nepotřebných znaků v~HTML lze také ušetřit značnou část přeno
|
||||
\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. \quest{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 v~době psaní této práce vyvíjena\footnote{\url{https://github.com/getzola/zola/issues/542}}.
|
||||
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. Toto by se nabízelo jako jedna z~dalších možností pro implementaci rozšířeni. Generátor Zola provádí kompresi CSS, ovšem nemá zabudovanou funkcionalitu pro minifikaci výsledného HTML, která je 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í.
|
||||
|
||||
@ -319,16 +319,12 @@ Další obecné rady pro optimalizaci HTML jsou uvedeny na serveru \cite{yahoo_o
|
||||
|
||||
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 souvisí i velikost stránek, kdy soubory větší než je daná maximální velikost se do mezipaměti 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.
|
||||
|
||||
\subsection{Optimalizace videa}
|
||||
|
||||
Protože v~modelové implementaci jsou do stránky vkládána i videa, je nutné provádět jejich optimalizaci podobně jako je tomu u~obrázků. Důležité je používat kvalitní kompresi, pouze nutné rozlišení a renderovat videa ve správném poměru stran a bez zbytečných černých okrajů. Při zpracování videa je dobrou praktikou neprovádět jeho transkódování do jiného formátu z~původního, ovšem je nutné dbát na kompatibilitu s~prohlížeči, které ne vždy umí nativně různé formáty a kontejnery přehrát.
|
||||
|
||||
\quest[inline]{Napsat něco o~specifikaci kodeků? Ve specifikaci se o~tom už nepíše. Ptal jsem se na IRC, ale zatím bez odpovědi. Dříve se psalo, že není jeden daný kodek a kvůli tomu je to v~prohlížečích fragmentované.}
|
||||
|
||||
\section{Správa obsahu a verzování}
|
||||
|
||||
Statické stránky neumožňují správu uživatelů v~rámci webové aplikace, tedy, že se případný editor nebo administrátor přihlásí a upravuje obsah klikáním, či psaním ve WYSIWYG\footnote{What You See Is What You Get -- Princip editoru který během psaní formátuje text tak, jak bude ve výsledku vypadat, například LibreOffice Writer atd.} editoru. Správu uživatelů lze jednoduše řešit omezením přístupu na web server, kde jen oprávnění uživatelé mohou do obsahu zasahovat. To je ovšem velmi těžkopádné řešení, protože neumožňuje práci více uživatelům najednou a neudržuje předešlé verze obsahu a historii úprav. Lepší alternativou je využití některého verzovacího systému. Pro účely modelové implementace byl vybrán distribuovaný verzovací systém Git, jak je vysvětleno v~sekci \ref{kap:vyber-vhodneho-systemu-verzovani}.
|
||||
|
Reference in New Issue
Block a user