Wydajność aplikacji. Czy semantyczny HTML ma na to wpływ?

Czy wiesz czym jest semantyczny HTML? Pewnie tak bo dla Web Developera to chleb powszedni (chyba, że nim nie jesteś to wtedy ten artykuł Ci to wytłumaczy). Ale czy zastanawiałeś/aś się czy ma on jakikolwiek wpływ na wydajność aplikacji? Jeśli tak, to jaki? Zapraszam do lektury.

Czego się dzisiaj dowiesz?

Na początku wytłumaczę czym jest semantyczny (semantic) HTML i po co został wymyślony. Nawiążę przy tym do pojęć takich jak accessibility i SEO. Następnie przeprowadzę test przy użyciu narzędzia do określania szybkości stron mający na celu sprawdzić, czy strona napisana semantycznym HTMLem jest szybsza. Na końcu krótka analiza tego, jakie czynniki mają wpływ na wydajność aplikacji. Dużo ciekawych rzeczy 🙂

Dlaczego o tym piszę?

Od dawna mnie to pytanie nurtowało: Czy semantyczny HTML jest szybszy? Pozornie mało istotna kwestia ale sukcesywnie drążyła moją świadomość. W końcu nadszedł ten czas… Rozstrzygnę to raz na zawsze. Przeprowadzę test…

Oczywiście dzisiejszy test nie jest ostateczną odpowiedzią na poruszane zagadnienie jednak zawsze to mały krok w kierunku budowy swojej bazy wiedzy.

Czym jest semantyczny HTML?

Koncepcja semantycznego HTML’a dojrzewała aby ujrzeć swoją współczesną odsłonę w HTML 5. O co chodzi?

Jak wiemy kod HTML ma za zadanie zbudować strukturę aplikacji, drzewo DOM. Ową strukturę tworzy się za pomocą tagów HTML które najczęściej mają postać <exampletag> </exampletag>.

Do głównych tagów tworzących trzon aplikacji należą odpowiednio:

<html >
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <meta http-equiv="X-UA-Compatible" content="ie=edge">
        <title>Document</title>
    </head>
    <body>

    </body>
</html>

Powyżej widać, że wewnątrz tagu <head> znajdują się tzw. metatagi określające rozmaite właściwości aplikacji. Cała sztuka zaczyna się przy tworzeniu wnętrza tagu <body> bo właśnie tam buduje się właściwy program. Do akcji może wtedy wkroczyć semantyczny HTML

Semantyczny HTML

Semantyczny HTML to kod napisany za pomocą tagów które mają określone znaczenie i mogą być odpowiednio interpretowane przez przeglądarkę i developera. Dla odróżnienia tagi które nie są semantyczne są obojętne tzn. nie mówią wprost nic na temat swojej zawartości.

No to jakie tagi są semantyczne a jakie nie?

Tagi nie-semantyczne

Do tej grupy należy np. bardzo popularny <div> </div> lub <span> </span>

<div>
    <span>A</span>
    <span>B</span>
    <span>C</span>
</div>

Tagi semantyczne

Tu mamy zdecydowanie większy wybór np:

<header>
    <figure></figure>
    <details></details>
</header>
<nav></nav>
<article>
    <aside></aside>
</article>
<section>
    <summary></summary>
</section>
<footer>
    <mark></mark>
</footer>

W zasadzie używanie tagów jest dość intuicyjne bo np. większą zawartość tekstową możesz umieścić w tagu <article>, grafiki, obrazy np. w <figure> itp…

Chcę więcej tagów!

Jeśli chcesz sprawdzić wszystkie tagi dostępne w HTML 5 to sprawdź np. TUTAJ

Accessibility i SEO

Dwoma kluczowymi zagadnieniami które wymienia się jako beneficjentów semantycznego HTML’a są accessibility i SEO. Czym one są?

SEO czyli Search Engine Optimization jest zbiorem dobrych praktyk które mają na celu polepszenie wyników osiąganych w wyszukiwarkach internetowych. Po prostu jak być jak najwyżej w wyszukiwaniu w Google. Napisałem o tym osobny artykuł

Accessibility (pl. dostępność) to tworzenie aplikacji w sposób który jest łatwy do interpretacji dla przeglądarki i/lub specjalnych urządzeń przystosowanych przez osoby niepełnosprawne. Po prostu przeglądarka wie kiedy ma do czynienia z obrazkiem, nawigacją czy artykułem. Więcej informacji na ten temat można znaleść np. TUTAJ

Czy semantyczny HTML wpływa na szybkość aplikacji?

Jak widać to enigmatyczne hasło w istocie kryje pod sobą prosty kod. Więc skoro wiemy już z czym mamy do czynienia to zmierzmy się z sednem dzisiejszego wpisu. Czy semantyczne tagi przyśpieszają działanie aplikacji?

Prosty eksperyment

Przeprowadzę prosty test tzn. porównam dwie wersje tej samej strony. Pierwsza nie będzie napisana semantycznie, druga już tak.

Na tapetę wezmę proste PSD które zakodziłem dawno temu. Stronka wygląda tak:

MAKER 

Teraz czas na kod.

Nie-semantyczny kod

W tym wypadku użyłem niemal samych tagów <div>, jest też trochę nagłówków i linków. Ciekawostką jest to, że zastąpiłem wektory o tagach <svg> divami i grafiki wciąż działają…

TUTAJ możesz zobaczyć tą wersję na Githubie

Semantyczny kod

Tym razem starałem się zastąpić wszystkie divy odpowiednimi tagami. Można dyskutować na temat dobrych praktyk przy wyborze konkretnych tagów jednak nie o to tu chodzi.

Wersja kodu TUTAJ

Porównanie szybkości strony

Do analizy szybkości strony służy wiele narzędzi. Dość szybkim narzędziem jest np. Google Speed Test  jednak jego statystyki wyników są dość ogólne. Dlatego bardzo spodobał mi się…

GTmetrix

Ich serwery są zazwyczaj przeładowane więc na analizę należy poczekać kilka minut jednak… warto bo aplikacja pięknie wypisuje co należy poprawić aby przyśpieszyć naszą stronę. Mi się podoba.

Wyniki analizy

Poniżej zrzuty z ekranu:

Nie-semantyczny kod

Semantyczny kod

Komentarz

Obydwa rezultaty są TAKIE SAME! Czyżby semantyczny HTML nie miał żadnego wpływu na wydajność?

Plik HTML

Idąc dalej tym tropem czas sprawdzić o co chodzi… Test pokazał mi też taki komunikat:

Czyli aby nieco przyśpieszyć tą stronę mogę zminifikować plik .html i wtedy oszczędzę 35B. Jednak dostałem też informację, że ten manewr ma niski priorytet czyli nie ugram w ten sposób zbyt wiele…

No ale jednak rozmiar pliku ma znaczenie…

Rozmiar pliku .html

Porównując dwa przypadki semantyczny plik ma 21 889 B a nie-semantyczny 21 830 B więc różnica jest minimalna. W tym wypadku można uznać tą różnicę za marginalną i nie wpływa ona znacząco na wydajność aplikacji.

Wnioski z analizy

Semantyczne tagi są mimo wszystko dłuższe niż <divy> i ich odwzorowanie zajmuje więcej bitów/bajtów. Przy rozbudowanych aplikacjach różnica może się zwiększać jednak można ogólnie stwierdzić, że semantyczny HTML ma teoretycznie negatywny wpływ na szybkość aplikacji lecz w praktyce ten wpływ jest marginalny i można go pominąć.

Więc co ma realny wpływ na szybkość aplikacji?

No właśnie… Podzieliłbym to na 3 kategorie:

Czynniki ilościowe

Czyli wszystko co związane z ostatecznym rozmiarem aplikacji np.

  1. Minifikacja/konkatenacja plików .html, .css, .js etc.
  2. Dostosowywyanie rozmiaru grafik rasterowych (.jpg, .png itp.) i  ich optymalizacja
  3. Użycie grafik wektorowych

Czynniki jakościowe

Czyli dbanie o jakość naszego kodu np.

  1. Nie powtarzanie zbędnego kodu przez co pliki są mniejsze
  2. Tree shaking i usuwanie zbędnych części kodu
  3. Tworzenie buildów produkcyjnych redukujących rozmiar aplikacji
  4. Dbanie o zmiejszenie złożoności obliczeniowej poprzez stosowanie optymalnych algorytmów.

Czynniki sieciowe

Zakładając, że sieć/internet działa prawidłowo i dane mogą być swobodnie przesyłane:

  1. Ograniczenie ilości potrzebnych żądań (np. GET/POST) przy ładowaniu strony.
  2. Użycie pamięci podręcznej cache 
  3. Stosowanie różnych asynchronicznych technik ładowania danych np. lazy loading
  4. Kompresja gzip

To by były tylko te najbardziej oczywiste punkty. Wydajność aplikacji jako taka może być traktowana jako osobna dziedzina wiedzy ale mam nadzieję, że ten wpis choć trochę zainteresował Cię tematem 🙂

Podsumowanie

Semantyczny HTML w praktyce nie ma wielkiego wpływu na wydajność aplikacji internetowych jednak odpowiednio skonstruowany kod pozwala na dotarcie do większej liczby użytkowników. Co najważniejsze używając tej techniki możesz dotrzeć do tych, którzy często inspirują wolą walki i siłą swojego charakteru.

Jeśli ten wpis zawiera jakieś błędy logiczne lub techniczne napisz to proszę w komentarzu 🙂


Bartek Cis

Piszę dla was tego bloga bo lubię aplikacje internetowe. Mogę je projektować, kodować a potem o nich pisać czując dreszczyk ekscytacji za każdym razem gdy trafię na coś nowego. Bo uczymy się całe życie. Prawda?
  • W kwestii cache ja bym dodał jeszcze Service Worker co dzisiaj chyba powoli będzie się stawać już standardem, a daje fajne możliwości konfiguracji cachowania danych statycznych i tych pochodzących z API.

  • Tagi HTML jako czynnik przyspieszający stronę? Tylko pobieżnie przeskanowałem tekst, ale jak zobaczyłem test wydajności porównujący szybkość działania z tagami „semantycznymi” i bez nich to złapałem się za głowę. Sens tych tagów jest zupełnie inny. Nie ma nic wspólnego z wydajnością strony. Tu chodzi o przekazanie znaczenia tekstu, wydzielenie logicznych części strony. Generalnie, ten tekst jest w stylu: „Czy jak zjem czekoladę to, będę miał nutellę na śniadanie?”

    • Bartłoś Ce

      Masz rację, semantyczne tagi nie przyśpieszają strony. Taki jest wniosek z powyższego tekstu 🙂

    • Dokładnie. To pomieszanie pojęć z totalnie dwóch różnych zakresów. Semantyka nie ma nic wspólnego z wydajnością i używa się jej po to, by dokumenty HTML _cokolwiek znaczyły_. Takie testy miały sens w latach 90., gdy porównywało się tabelkowe potwory do „semantycznych” divów. W obecnej chwili, przy istnieniu HTTP/2.0, takie porównania są po prostu bez sensu – zwłaszcza, że 95% ciężaru strony to i tak multimedia i JS.

    • Co nie zmienia faktu, że dla kogoś kto jest bardzo początkujący i może zastanawiać się nad tego typu zagadnieniami, test, a tym samym potwierdzenie, że w kwestii wydajności nie ma to absolutnie żadnego znaczenia, może być informacją przydatną. I tyle. Nie ma co bić piany 🙂

      • Tak po prawdzie mocno początkujący raczej nie zastanawia się nad optymalizacją kodu i wydajnością, a semantykę dopiero poznaje. A później takich rzeczy nie rozważa, bo wydają się oczywiste, na gruncie wiedzy, którą już zdobył.

  • W obecnych stronach internetowych HTML stanowi ich najmniejszą część. O wiele więcej przeciwko wydajności robi JS, którego pakujemy coraz więcej i do co raz większej liczby rzeczy, a który kosztuje nie tylko na transferze, ale i na czasie wykonania.

    Zamiast zastanawiać się, czy zamienienie `article` na `div` pozwoli nam zaoszczędzić 0,5 ms, skupmy się na realnych problemach, takich jak choćby niemożliwość cache’owania stron za HTTPS → https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/

    • PS

      > Ciekawostką jest to, że zastąpiłem wektory o tagach divami i grafiki wciąż działają…

      W teorii powinno to działać, bo liczą się nie nazwy tagów, a przestrzenie nazw. Niemniej to powinno działać wyłącznie w trybie XML. Mimo to nie jestem w stanie tego odtworzyć ani w Firefoksie, ani w Chrome.

    • Wiedziałem, że tu zajrzysz 🙂
      Zgadzam się z tym co pisze Comandeer, ale nie do końca zgadzam się z:
      O wiele więcej przeciwko wydajności robi JS, którego pakujemy coraz więcej i do co raz większej liczby rzeczy
      Sam html i css nie wystarczą aby robić rozbudowane aplikacje, a tym właśnie wg mnie zajmuje się dzisiaj front-end… JS musi więc być i tak na prawdę będzie go coraz więcej w „internetach”, no chyba, że świat podbiją zwolennicy C++ i WebAssembly (hmm, będzie wtedy można mówić, że i C++ służy do animowania śniegu w tle strony :p)
      Problemu należy więc szukać nie w tym, że jest dużo JS, ale w tym, jak to wszystko cachować, np. poprzez odpowiednią konfigurację SW, ale i tutaj nierzadko można spotkać wprost kopiowanie ustawień z innych stron bez w ogóle rozumienia co robi SW…

      • Samo cache’owanie nie rozwiązuje problemu z JS-em, który jest kosztowny także w czasie parsowania i następnie wykonywania. Tutaj żaden cache nie pomoże, a sytuacja będzie gorsza proporcjonalnie do tego, jak słabe jest urządzenie użytkownika.

        Owszem, JS-a jest coraz więcej – tylko czy nie jest go coraz więcej głównie po to, żeby było wygodniej nam, developerom? Czy użytkownik musi ponosić koszt całego Reacta tylko dlatego, że nie chcemy musieć myśleć o optymalizacji DOM i zrzucamy to na karb vDOM – mechanizmu, który potrzebuje pamięci, by wykonać swoje zadanie? Nie na darmo Tom Dale już rok temu stwierdził, że przyszłością frameworków jest ich stopniowa przemiana w kompilatory, które wyplują minimalny kod końcowy. I w taką stronę to już idzie, ze Stencilem czy Svelte na czele.

      • No z tą wygodą dla developerów to bym dyskutował… Wszystko fajnie, można pisać kod w vanillaJS i w pełni samodzielnie o wszystkim myśleć co na pewno zmniejszy kod, ale wytłumacz to niejednemu Product Ownerowi, który przyjdzie i powie „to ma być na wczoraj, a najlepiej na przedwczoraj”. Tutaj wkracza wlaśnie React czy Angular, pozwalając zrobić wiele rzeczy na prawdę szybko i druga kwestia… łatwiej wdrożyć w większe projekty osoby bez dużego doświadczenia w JS, choć i tu bywa różnie, zdarzają się juniorzy, który chwalą się w CV dobrą znajomością np. Angular 5, a potem się okazuje, że nawet serwisu nie umieją zrobić czy obsłużyć HttpClient z rxjs.. ale mimo wszystko wydaje mi się, że łatwiej je wprowadzić w aplikację z frameworkiem niż całkowicie w vanilla i na jakiś własnych rozwiązaniach.

        A co do tej optymalizacji przy frameworkach to też trzeba by spojrzeć na ile winny jest faktycznie framework, a na ile ludzie, którzy w nim pracują. Na przykład choćby z podwórka Angular (tak wiem co o nim myślisz, ale nie bij 🙂 ) mamy do dyspozycji trochę opcji aby nieco popracować nad wydajnością jak DetectionStategy, ngZone itp. ale też nie zawsze jest to wykorzystywane, szczególnie np. wyjście z ngZone przy obsłudze częstych eventów myszki itp.

        A z tymi kopilatorami to ciekawa opcja… zobaczymy jak to się rozwinie.

        • Jasne, łatwiej pisać w React czy Angularze – niemniej problem jest z outputem. Użytkownika nie obchodzi, że nasz kod ma 40 warstw abstrakcji i zdobył nagrodę w konkursie na najładniejszą implementację DDD. Jak jest wolny, to zasługuje co najwyżej na niecenzuralną panią lekkich obyczajów.

          Czemu React albo Angular nie wypluwają domyślnie właśnie mocno zoptymalizowanego Vanilla JS lub Web Components? Wręcz idealny compilation target dla wszystkich frameworków. IMO to jest właśnie brakujące ogniwo, które łączyłoby DX z UX.