Google Chrome twierdzi, że zaoszczędził użytkownikom ponad 10000 godzin, w tym w systemie Windows 11

Google Chrome twierdzi, że zaoszczędził użytkownikom ponad 10000 godzin, w tym w systemie Windows 11

Zespół programistów Chromium opublikował dzisiaj post na blogu, w którym opisał ulepszenia wydajności, jakie udało mu się osiągnąć w ciągu ostatnich kilku lat. Ocena opiera się na podstawowych wskaźnikach sieciowych, które pomagają ocenić wydajność strony internetowej, aby pomóc twórcom stron internetowych w optymalizacji i poprawie komfortu przeglądania użytkowników.

Ulepszenia obejmują także system Windows 11, ponieważ Chromium zauważa użycie EcoQOS (Quality of Service), zwanego także trybem wydajności w systemie Windows 11, który pomaga w ograniczaniu przepustowości kart . Warto tutaj zauważyć, że Firefox również to obsługuje, mimo że jest oparty na silniku Gecko, a nie na Chromium.

Inne znaczące ulepszenia omawiają korzyści osiągnięte dzięki wstępnemu renderowaniu , BFcache i nie tylko.

Osiągnięcia w zakresie podstawowych wskaźników internetowych przeglądarki Chrome

Z dumą podkreślamy wiele sposobów optymalizacji wydajności.

  • Pamięć podręczna wstecz/do przodu (bfcache) została zaprojektowana w celu poprawy komfortu przeglądania poprzez umożliwienie natychmiastowej nawigacji do tyłu i do przodu. Wskaźnik trafień BFCache poprawiał się z miesiąca na miesiąc zarówno na Androidzie (3,6%), jak i na komputerze stacjonarnym (1,8%).
  • Innym przykładem szczególnie skutecznej optymalizacji jest nasza funkcja PreconnectOnAnchorInteraction, która łączy się ze źródłami w przypadku wskaźnika w dół, a nie w górę. Ta w pełni uruchomiona funkcja doprowadziła do poprawy mediany LCP o 6/10 ms (0,4/1%) na Androidzie/komputerze stacjonarnym oraz poprawy LCP między źródłami o ~60 ms zarówno na Androidzie, jak i na komputerze stacjonarnym.
    Wprowadzenie na rynek zaowocowało również wzrostem przychodów z reklam treściowych o 0,08%, co podkreśla znaczący wpływ optymalizacji wydajności na zaangażowanie użytkowników i zdrowie ekosystemu.
  • Wprowadziliśmy także wstępne renderowanie , które sprawia, że ​​strony ładują się natychmiastowo, renderując je, zanim użytkownik faktycznie je odwiedzi. Strony wczytywane poprzez wpisanie adresów URL bezpośrednio w omniboksie uzyskują poprawę mediany LCP o 500–700 ms (14–25%) w przypadku wstępnego renderowania, w zależności od platformy, przesuwając globalną medianę LCP we wszystkich nawigacji o 6,4 ms. Obecnie wdrażamy wstępne renderowanie wyszukiwań inicjowanych za pomocą omniboksa.
  • Chrome ciężko pracował, aby karty działające w tle nie przeszkadzały. Wdrożenie ograniczania kart dla kart działających w tle w EcoQOS w systemie Windows 11 oraz dostosowania ról zadań i QoS w systemie macOS doprowadziło do ulepszeń w zakresie największego malowania zawartości (LCP) i interakcji z następnym malowaniem (INP).
  • Nowoczesna zdolność Internetu do uruchamiania wszelkiego rodzaju aplikacji wiąże się również z koniecznością zarządzania związanym z tym obciążeniem. Optymalizowaliśmy Chrome pod wieloma aktywnymi kartami i z radością ogłaszamy ulepszenia harmonogramu i rywalizacji, które poprawiają INP o 5% i LCP o 2% w ciągu ostatnich 6 miesięcy.
  • W 2022 r. wprowadziliśmy ukierunkowane ulepszenia w kodzie ładowania strony w przeglądarce Chrome. Spowodowało to poprawę LCP o 10% na Androidzie i poprawę współczynnika przepuszczalności CWV o 1,5%.
  • Mechanizm renderujący Chrome również uległ pewnym ulepszeniom. Główny wątek modułu renderującego zawiera kolejki zadań dla JavaScript, renderowania i ładowania obrazu. Niektóre zmiany zmieniające priorytet tych zadań w celu uzyskania optymalnego CWV obejmują.
    • Ładowanie obrazu o wysokim priorytecie: W przeszłości ładowanie obrazu miało ten sam lub niższy priorytet niż renderowanie. Jednak eksperyment pokazał, że pomiędzy zadaniem ładowania obrazu a zadaniem renderowania wybranie najpierw zadania ładowania obrazu może zapobiec przesunięciu układu ramki pośredniej, która nie zawiera obrazu, a także poprawia LCP.
    • Poprawa w systemie Android na 75. percentylu wyniosła -6,66% w przypadku CLS i -0,82% w przypadku LCP, co oznacza poprawę współczynnika przepuszczalności CWV w systemie Android o +0,24%. Podobny eksperyment, który zwiększył priorytet ładowania do „średniego” pierwszych pięciu obrazów przeanalizowanych z kodu HTML (w przypadku obrazów o rozmiarze innym niż ikony), wykazał poprawę w systemie Android na 75. percentylu wynoszącą -6,08% dla CLS i -0,53% dla LCP. Połączony eksperyment wykazał, że skutki obu zmian były w dużej mierze niezależne.
    • Nadaj priorytet komponowaniu po opóźnieniu: Jeśli od ostatniego uruchomienia zadania komponowania minęło więcej niż 100 ms, podnieś priorytet każdego zadania komponowania w kolejce, tak aby wyprzedziło pracę o normalnym priorytecie. Spowodowało to poprawę o -0,27% w przypadku CLS w systemach Android i Windows na 95. percentylu.
    • Optymalizacje rastrów SVG: Kolejna optymalizacja rysunków SVG poprawiła współczynnik przepustowości INP na komputerach stacjonarnych o -2,28% dla systemu MacOS na 75. percentylu.

Oficjalny post na blogu możesz przeczytać tutaj , na stronie Chromium.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *