16 key points – wydajność w budowaniu aplikacji internetowych

Jeden z naszych programistów był niedawno na konferencji 4 DEVELOPERS. Przywiózł nam cały worek ciekawej wiedzy oraz inspiracji, którymi chcemy się z Wami podzielić.

Jak zapewne wiecie, cała nomenklatura informatyczna czerpie swoje źródła w budownictwie, i stąd zapewne wzięło się częste porównanie systemów informatycznych do budowy domu,  gdzie budujemy wszystko po kolei – od fundamentów po dach – i po skończonych pracach efektem jest budynek. Jednak z czasem widać, że owe porównanie nie do końca oddaje  sposób budowania aplikacji. Warto pomyśleć o tym procesie jak  o ogrodzie, gdzie w jednym miejscu coś dosadzamy, w drugim wyrywamy, a jak mamy już gotowy ogród to go cały czas pielęgnujemy.

Wracając do tematu wydajności – jej budowy i rozwijania, mamy dla Was 16 punktów, które warto wziąć pod uwagę tworząc aplikacje internetowe.

Wydajność webowa – jak to ugryźć?

  1. Warto pamiętać, że wydajność to nie tylko kod, ale także user experience.
  2. Trochę badań na temat tego, jak reaguje nasz mózg:
  • ~0,1s to czas, który potrzebujemy aby zauważyć, że coś się zmieniło,
  • ~2 s – jest to próg ładowania strony, po tym czasie user robi się nerwowy,
  • > 3s  – po upływie tego czasu 30% userów opuszcza stronę,
  • > 10s –  zaczyna działać pamięć krótkotrwała (a raczej jej brak). Oznacza to, że po 10s oczekiwania na wczytanie się strony zazwyczaj nie pamiętamy czego szukaliśmy.
  1. 4% userów rzuca telefonami, gdy coś działa wolno.
  2. 85% ludzi oczekuje, że wersja mobilna będzie działać szybciej.
  3. Google opracowało własny model czasu wczytywania stron:

RAIL

Response: < 100ms – w tym czasie coś się musi dziać,

Animate: <15ms,

Idle: < 100ms działania w tle,

Load: < 1000ms strona w 1 sekundę powinna się załadować.

  1. SEO – strony, które ładują się szybciej są wyżej w wynikach.
  2. Jakiś czas temu, na życzenie userów, Google wprowadziło 30 wyników na jedną stronę (zamiast dotychczasowych 10). W związku z tym czas ładowania całej strony wydłużył się z 400 ms do 900ms. Po tym zabiegu 25% użytkowinków przestało korzystać z Google, dlatego też ostatecznie wrócono do opcji 10 wyników.
  3. Wydajność nie jest dodatkiem, który można sobie dodać w jakimś sprincie. Na to trzeba mieć czas od samego początku projektu.
  4. Złota zasada wydajności  Steva Soundersa: 80-90% czasu ładowania strony to front, a nie backend (w przypadku, gdy backend jest zoptymalizowany).
  5. Program do mierzenia wydajności: dynaTrace Ajax Editor.
  6. Bardzo ważną zasadą jest to, aby user po wejściu na stronę od razu miał odpowiedź. Może to być tylko html i tekst, ale żeby coś miał! Nie zapominajmy o alt’ach.
  7. WebPagetest.org to strona zachwalana przez prelegenta. Można na niej nagrywać filmy pokazujące wyniki optymalizacji (dobre rozwiązanie do pokazania Klientom).
  8. Dodatkowo prelegent polecał także 2 inne strony:
  1. Rozmiar strony nie może przekraczać 1,5M.
  2. RWD powinien różnić się wielkością stron na różnych urządzeniach.
  3. Prowadzący polecał, by wdrożyć w firmie Performance Budget, ustając go np. na 4s, tak by każdy członek zespołu wiedział o tym. Przykładowo jeżeli Klient chce, by wdrożyć jakąś bibliotekę to biznes musi wiedzieć, że wdrożenie jest możliwe, ale doda to 1 s. to budżetu. Warto brać to pod uwagę.

Myślę, że jest to bardzo ciekawe podejście do pojęcia ‘wydajności’ w budowaniu aplikacji. Także mam nadzieję, że zainspirujecie się nieco tym tekstem i sprawdzicie, jak jest oceniana wydajność w Waszych sklepach interentowych/ w Waszych CMSach.

Powodzenia!

Ilona

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *