2013-12-17 19 views
7

Na miejscu Używam obecnie style.css i kilka innych stylów, 960.css itd załadowany tak:CSS zapytań o media: jeden plik vs. oddzielnych plikach i wpływu na szybkość ładowania

<link rel=​"stylesheet" media=​"screen" href=​"css/​style.css"> 
<link rel=​"stylesheet" media=​"only screen and (max-width:​ 960px)​" href=​"​css/​960.css"​> 
.... 

Teraz jestem zaniepokojony prędkością. Wiem, że mogłem połączyć pliki w jeden duży plik, ale oznaczałoby to również pobieranie nieistotnych danych.

Moje pytanie brzmi: czym jest lepsze podejście, minimalizujące liczbę żądań lub minimalizujące ilość danych przekazywanych do jednego użytkownika?

+0

Jakie nieistotne dane? Nagłówki odpowiedzi HTTP? – BoltClock

+1

@ BoltClock'saUnicorn Miałem na myśli tylko oznaczenie css, które nie zostanie użyte (masz szeroki ekran o rozdzielczości 1280 pikseli, ale dostajesz niepotrzebnie duży plik z np. 5 zapytaniami o media). – Roni

+2

Zostanie on załadowany, nawet jeśli jest nie jest używane, niezależnie od tego, czy zapytanie o media zostało umieszczone w CSS czy w tagu linku. – BoltClock

Odpowiedz

0

Chodzi zasadniczo o wydajność twojego systemu.

nawet jeśli korzystasz z urządzeń mobilnych, najlepszym sposobem jest zminimalizowanie liczby żądań z powodu (być może) powolnego połączenia sieciowego i (być może) powolnego zarządzania zasobami. oprócz Twojej strony, na przykład kontekst cordova takie podejście byłoby drogą, ponieważ zasoby zostały zainstalowane bezpośrednio na urządzeniu. wiele plików => wiele uchwytów => wolne (er) wydajność.

jeśli chcesz zminimalizować ilość danych przekazywanych do użytkownika - kwota jest taka sama jak IMHO, ponieważ tag będzie sprawdzał plik css na serwerze i będzie analizować/czytać/pobierać. IMHO nie ma istotnego problemu z wydajnością. możesz wygenerować i "nie nadmiarowy" plik css. ale to nie jest naprawdę małostkowe :)

0

Moje pytanie brzmi: czym jest lepsze podejście, minimalizujące ilość żądań lub minimalizujące ilość danych przekazywanych do jednego użytkownika?

Powiedziałbym jedno i drugie. Pamiętaj, że żądania będą buforowane przez przeglądarkę, więc dla powracających użytkowników Twoje obawy są nieistotne. Ogólnie mniej danych = szybsze czasy pobierania. Najlepszym rozwiązaniem byłoby podanie minimalnej ilości danych potrzebnych użytkownikowi.

3

Na rozsądnym łączu prędkości opóźnienie i obciążenie związane z dodatkowym żądaniem prawdopodobnie przeważą zyski, ponieważ nie pobierają niewielkiej ilości (mam nadzieję, że skondensowane i spakowane) danych tekstowych, które nie są wymagane dla tego użytkownika aby wyświetlić stronę o tej rozdzielczości. Zobacz Ilya Grigorik's excellent post on latency, aby uzyskać więcej informacji o tym, jak to jest głównym ograniczeniem wydajności dla wielu użytkowników.

Koszt opóźnienia dodatkowych danych będzie szczególnie istotny w przypadku użytkowników urządzeń mobilnych (które będą oszczędzać energię swoich radiotelefonów, gdy nie są używane), a jeszcze bardziej na mobilnych połączeniach 2G lub 3G, które mają stosunkowo wysokie koszty w nawiązywanie połączeń (wydaje się, że znacznie poprawia to 4G).

Kluczem, jak w przypadku wszystkich tych rzeczy, jest testowanie i mierzenie - ale prawie na pewno spodziewam się, że łączenie stylów okaże się szybsze dla użytkowników. Nie zapomnij o tym, że każdy poprawny arkusz stylów (where the media query evaluates to true) zablokuje renderowanie strony.

Warto również zauważyć, że Ilya (który pracuje dla Google, więc powinien wiedzieć), że cytuje WebKit będzie jeszcze pobrać arkusze stylów multimedialne zapytania, które zwróci false, aczkolwiek o niskim priorytecie oraz w non-blocking sposób.

jeśli zapytanie mediów wartość false następnie arkusz stylów jest oznaczone jako nonblocking i podana jest bardzo niski priorytet pobierania

i

Jedyne zastrzeżenie , jak wskazuje Scott, jest to, że przeglądarka pobierze wszystkie włączone arkusze stylów, nawet jeśli ekran urządzenia nie może nigdy przekroczyć t on [cytowane] szerokość krótko

Patrząc na źródło WebKit wydaje się, jakby to wciąż się dzieje, prawdopodobnie, aby umożliwić natychmiastową reakcję na obracanie ekranu lub zmiany rozmiaru okna.

// Load stylesheets that are not needed for the rendering immediately with low priority. 

223 ResourceLoadPriority priority = isActive ? ResourceLoadPriorityUnresolved : ResourceLoadPriorityVeryLow; 

224 CachedResourceRequest request(ResourceRequest(document().completeURL(url)), charset, priority); 

225 request.setInitiator(this); 

226 m_cachedSheet = document().cachedResourceLoader()->requestCSSStyleSheet(request); 

W przypadku takich pytań mogę bardzo polecić High Performance Browser Networking, które można przeczytać online za darmo.

+0

Jedynym wyjątkiem, jaki mogę dodać, jest posiadanie oddzielnego arkusza stylów "Drukowanie", którego nowoczesne przeglądarki nie będą pobierać ani zezwalać na blokowanie, dopóki nie będzie to wymagane. Wydruk jest zwykle działaniem opóźnionym (zainicjowanym przez użytkownika) i prawdopodobnie nie będzie używany przez większość użytkowników, więc dodatkowe żądanie nie będzie miało wpływu na początkowe renderowanie strony. Decyzja ta oczywiście zależy od kontekstu treści. – pwdst