Witaj
Mam podobny problem, jak go rozwiązałeś?
Ludzie lubią przeginać. To raczej standard :)
]]>Jak tak przeglądam ten post, to mam wrażenie, że kogoś nieźle pogięło. I tym kimś jest zarówno Google, które ma wręcz obsesję prędkości, jak i webmasterzy, którzy tą obsesję próbują wypełniać.
>So I’m forced to manually concatenate (and minify) all the Javascript files before we defer the loading:
Jasne. Przy jQuery + 3 pluginach na krzyż działa bez problemu. Później po prostu grzęźniemy w bagnie dziwnych zależności. Lepiej zinlinować loader AMD i czytać sobie wygodnie moduły (albo wstawić loader przez script[async])
>so we will have to use their inline Javascript snippet to defer the loading.
a to to mnie już po prostu rozwaliło. muszę użyć snippetu Google’a do wczytania mojego JS i to dopiero po zdarzeniu load. czyli zaciągam większy obrazek i wszystko leży, bo czeka na skrypt JS, który się odpali tylko po to, żeby… załadować więcej JS. jak już ciągniemy asyncem, to IMO jak najwcześniej a nie jak najpóźniej
+inline całego „above the fold” CSS. w 98% projektów to jest po prostu sztuka dla sztuki.
takie samo, bzdurne i bezsensowne, znaczenie miał niegdyś zielony znaczek walidatora, który co poniektórzy wręcz wielbili jak bożka. jeden i drugi znaczek pokazuje jedynie jak bardzo umiesz hackować pod jedno narzędzie. Zakas napisał kiedyś wspaniały artykuł czemu nie uznaje zielonego znaczka i dlaczego dobry webmaster może sobie pozwolić na nieprawidłowy kod.
ja rozumiem, gdyby moja strona miała porównywalną odwiedzalność jak Google czy była cholernie popularnym widgetem, jak przycisk „Lubię to!” – wtedy tak ostre optymalizacje mają jakikolwiek sens. ale zwykła strona?
mam nadzieję, że pozostanie to tym, czym jest – eksperymentem. bo test prędkości Google IMO nie jest aż tak bardzo miarodajny (np nie łapie wgl całego offline, które diametralnie przyspiesza całą witrynę). zresztą nigdy ogólny test nie będzie miarodajny dla wszystkich możliwych rozwiązań i ślepe podążanie za tymi regułami jest po prostu naiwną głupotą. a przy agresywnym cache połowę tych zarzutów można o kant stołu roztrzaść, bo wystąpią tylko przy 1. wczytaniu strony (co fejs doskonale wie i nawet nie próbuje minifikować CSS)
BTW serio ktoś, kto chce uzyskać najwyższą z możliwych wydajność, użyje Bootstrapa? :D
]]>Taka dygresja do tematu: https://webroad.pl/blogroll/737-100-100-w-pagespeed-insights-na-bootstrapie
]]>A tak ;) Dzisiaj rano dopiero go zobaczyłem. Dzięki :D Może kiedyś (ale to naprawdę kiedyś) zmotywuję się na tyle, żeby napisać dla Was jakiś tutek albo art ;)
]]>Łooo, gratulacje :D Niezły wynik.
PS. Kubek dotarł?
Jak (nie) mówiłem, tak zrobiłem :D 92 na mobilnych i 98 na desktopy. Kolejne optymalizacje są po prostu przerostem formy nad treścią ;)
]]>akurat z tym można sobie bardzo szybko poradzić… przechodząc na GA ;)
]]>Oh, nie każdy. Zawsze można go zapomnieć gzipnąć :D
]]>No ja nie bardzo mam co nawet zrobić. Mam „ujemne punkty” za Google Fonts, Modernizr i własny, jeden plik CSS (skompresowany). 100/100 dostaje chyba tylko plain text, ale to trochę jak z walidatorem W3C.
]]>fakt, strona Google się poprawiła (wcześniej miała ok. 80 dla desktopów). a Tobie gratuluję wyniku ;) IMO nie widzę sensownego sposobu jego zwiększenia (nie, wciąż nie mam zamiaru inlinować JS-a i CSS-a – nie w czymś, co nie jest webappem)
]]>Mam dokładnie ten sam wynik, no i szewc się chyba poprawił :)
]]>Artykuł bardzo przydatny… Pomaga w optymalizacji portalu. Pozdrawiam!
]]>Odnośnie SPDY : http://sekurak.pl/spdy-jak-przyspieszyc-dzialanie-aplikacji-webowych-czesc-1/
Fajnie napisane dlaczego opłaca się stosować jedno połączenie.
]]>Odnośnie SPDY : http://sekurak.pl/spdy-jak-przyspieszyc-dzialanie-aplikacji-webowych-czesc-1/
Fajnie napisane.
]]>> Niekoniecznie, ja korzystam z http://www.megiteam.pl/
Dzięki za cynk – aż się przyjrzę ;)
> Akurat mnie node’a polecać nie musisz ;) nie wyobrażam sobie kodzenia bez ..
Nie przekonuję, cieszę się że można spotkać kolejnego sympatyka tego niesamowitego narzędzia jakim jest nodejs :)
Co do npm-a, to nie wiem czy przypadkiem on się nie wzorował z tego pythonowego menadżera pakietów. Ten pytonowy z kolei prawdopodobnie wzorował się na tym linuxowym menadżerze pakietów (chociażby apt-get) :D
Ale co jak co, composer to nieudolna próba naśladownictwa.
>obecnie nie znać/nie korzystać z node to jak pchać kwadratowy kamień pod stromą górę.
Doskonałe porównanie :)
>owszem, to akurat prawda. moduł node-spdy jest aż za prosty w obsłudze ;) tylko, że w polskich realiach node i tak oznacza VPS-a/dedyka albo chmurę.
Niekoniecznie, ja korzystam z http://www.megiteam.pl/ . Oprócz tego że jestem bardzo zadowolony to posiadają oni także nodejs w swojej ofercie. Każda z opcji ma ten pakiet.
Za serwer płacę do 200 zł jakoś.
> super duże żądania IMO są tak samo złe (z samego założenia – takie żądanie 5MB na mobilnych choćby) jak wiele zapytań HTTP
Fakt. Żadne super narzędzie czy biblioteka nie zastąpi zwykłego zdrowego rozsądku. Nie można przesadzać z ilością pobierania danych z serwera.
> jeśli mamy dobrze skrojony HTML, to w zasadzie okrojona wersja dla mobilnych sprowadzałaby się do wykorzystania loadera JS wykrywającego MQ- w tym momencie warunkowo dołączalibyśmy jedynie potrzebną funkcjonalność. przynajmniej tak bym spróbował
No i takie podejście jest cool. W dodatku nie trzeba angażować backandu do serwowania odpowiednich plików gdyż te same w zależności od potrzeb są dociągane przez przeglądarkę a co za tym idzie, łatwiejsze zarządzanie kodem projektu po stronie backendu. Mniej zależności, mniej problemów, łatwiej konserwować kod :)
]]>Akurat mnie node’a polecać nie musisz ;) nie wyobrażam sobie kodzenia bez takich rzeczy jak choćby grunt, bower czy yeoman (nie wspominając już o LESS) – przecież z tych cudeniek można korzystać nawet nie pisząc w JS. no i sam npm jako menedżer pakietów (wcale nie widać, że composer się na nim wzorował, prawda? :D). obecnie nie znać/nie korzystać z node to jak pchać kwadratowy kamień pod stromą górę.
> No ale i tak mieć jedno super duże żądanie niż 50 małych to oszczędzamy na koszcie nawiązania nowego połączenia.
zawsze jeszcze zostaje keep-alive
>Co do uruchamiana SPDY na serwerze, to w przypadku nodejs nie trzeba robić nic szczególnego.
owszem, to akurat prawda. moduł node-spdy jest aż za prosty w obsłudze ;) tylko, że w polskich realiach node i tak oznacza VPS-a/dedyka albo chmurę.
>W kwestii certyfikatu to można zdobyć wersję darmową
można, ale czasami potrzeba zielonego paska w pasku adresu ;) oczywiście samo użycie SSL złe nie jest (sam popieram ten pomysł – szyfrowanie danych w Sieci powinno być standardem) – problem sprowadza się do przekonania środowiska do takiego pomysłu
>Więc nie widzę sensu łączenia tylko jsów w jeden plik, lepiej wszystkie żądania łączyć razem za pomocą SPDY w jedno połączenie.
skoro już server push będziemy wykorzystywać, to jak najbardziej. 1. żądanie powinno przesłać wszystkie podstawowe pliki (CSS, loader JS, inne potrzebne). raczej chodzi mi o to, że nie można przesadzać. super duże żądania IMO są tak samo złe (z samego założenia – takie żądanie 5MB na mobilnych choćby) jak wiele zapytań HTTP.
>Dla mobilnych i tak zazwyczaj daje się wersję bardziej okrojoną więc nie powinno być problemów.
jeśli mamy dobrze skrojony HTML, to w zasadzie okrojona wersja dla mobilnych sprowadzałaby się do wykorzystania loadera JS wykrywającego MQ- w tym momencie warunkowo dołączalibyśmy jedynie potrzebną funkcjonalność. przynajmniej tak bym spróbował
]]>http://caniuse.com/spdy – Desktopowe wsparcie wygląda całkiem nieźle. No oprócz ie które jak zwykle musi być wyjątkowe. Dla mobilnych i tak zazwyczaj daje się wersję bardziej okrojoną więc nie powinno być problemów.
No ale i tak mieć jedno super duże żądanie niż 50 małych to oszczędzamy na koszcie nawiązania nowego połączenia.
Z tym UDP to ciekawe, poczytam.
Co do uruchamiana SPDY na serwerze, to w przypadku nodejs nie trzeba robić nic szczególnego. Wystarczy doinstalować moduł i po prostu uruchomić SPDY.
Przykładowy moduł : https://github.com/indutny/node-spdy
Sama instalacja certyfikato sprowadza się do podania ścieżek do plików kluczy.
Nie terzeba VPS-a, wystarczy używać nodejs-a. Nodejs ma wiele innych fajnych zabawek przy których apache i php się nie umywa no ale nie będę się o tym rozpisywał.
W kwestii certyfikatu to można zdobyć wersję darmową :
http://yuppy.pl/2011/05/darmowy-certyfikat-ssl-dla-twojej-strony/
Więc nie widzę sensu łączenia tylko jsów w jeden plik, lepiej wszystkie żądania łączyć razem za pomocą SPDY w jedno połączenie.
]]>> Jeśli robisz proste stronki to wiadomo, async się sprawdzi.
Niekoniecznie tylko wtedy. Jak już wspominałem, przy użyciu odpowiednich build tools (choćby r.js/cram.js), można spokojnie połączyć kilka modułów AMD w jeden plik. wówczas sensownie można taki plik wstawić przez script[async].
> Odłożenie wczytania skryptów w czasie ma znaczenie dla użytkownika.
Nie przeczę. tylko, że samo odłożenie to… odłożenie problemu. przeglądarka i tak ściągnie wszystko, co jej każemy – nawet to, co niekoniecznie będzie potrzebne. lazy load obrazków jest tutaj świetnym przykładem jak ładować tylko to, co jest potrzebne. jeśli np mamy bardzo skomplikowany system komentarzy, ale na samym dole strony a user nie kwapi się zescrollować (bo np artykuł mu się nie spodobał), to całego systemu komentarzy po prostu nawet nie wczytujemy. dopiero jak user zacznie ruszać kółkiem myszy i będzie np 200px od komentów, ślemy szybkie zapytanie do serwera.
> Ale i rozwiązanie tego problemu jest banalne gdyż trzeba się pochylić bardziej nad protokołem SPDY który zdaje się obecnie chyba jest brany pod uwagę jako zaczątek specyfikacji „HTTP 2.0”
Owszem, jest zalążkiem HTTP 2.0. server push to genialny pomysł, tylko, że znając nas, webmasterów, zamiast jednego pojawi się inny problem. Zamiast 50 żądań zrobimy jedno superduże ;)
pomijając fakt, że obecnie wsparcie dla SPDY w przeglądarkach jest jeszcze mniejsze niźli dla [async] (który de facto nawet w nieobsługujących jest wewnętrznie wykorzystywany przy dynamicznych skryptach i jedynie czeka na ustandaryzowanie) ;). a to tylko jedna strona medalu. oparcie się na SPDY oznacza wymuszenie ich implementacji na serwerach. owszem, mamy VPS-a/dedyka – możemy się bawić. ale od razu pojawia się kolejny problem: wymóg SSL (ok, da się bez, ale to z kolei wymaga babrania się z flagami w chrome choćby). a i tak oprócz SPDY musimy reagować na zwykłe żądania HTTP, bo przeglądarka może tego nie akceptować albo user nie wpisze https:// w pasku adresu i trza będzie przekierować. SPDY to piękna przyszłość, ale no właśnie – przyszłość. pomijając już wgl fakt, że obecnie Google i tak serwuje nowy protokół – QUIC, czyli… SPDY po UDP ;) chyba nie trzeba mówić, że jest jeszcze szybszy
Jeśli robisz proste stronki to wiadomo, async się sprawdzi.
Odłożenie wczytania skryptów w czasie ma znaczenie dla użytkownika. User dostaje na „dzień dobry” 90% gotowej strony (onet nazywa ten paramet „speed index”, patrz ostatni barcam). User jest bardziej zadowolony jak mu się szybko pojawi treść strony a to że przycisk „lubię to” facebooka pojawi mu się za 5 sekund po wczytaniu treści ma mniejsze znaczenie.
Odnosząc się do Twojego argumentu rozdrobnienia żądań HTTP. To jak z każdą rzeczą tak i z tą nie można przesadzić. Ale i rozwiązanie tego problemu jest banalne gdyż trzeba się pochylić bardziej nad protokołem SPDY który zdaje się obecnie chyba jest brany pod uwagę jako zaczątek specyfikacji „HTTP 2.0”.
]]>To zależy od tego jak problem zależności rozwiązujemy. Oczywistym jest, że wczytywanie asynchronicznie 10 skryptów to po prostu odłożenie problemu w czasie. Dlatego też często i tak posyła się paczkę startową będącą połączeniem loadera i podstawowych modułów. AMD krytykowany jest właśnie za to, że zachęca do wczytywania wielu plików, co daje pokaźne opóźnienia. Niektóre systemy modułów wręcz żądają, żeby moduły były złączone przed wysłaniem do przeglądarki.
Owszem, [async] nie ma wszędzie obsługi, ale jest ona na tyle szeroka, że można stosować IMO
> Nie twierdzę, że nie należy stosować loaderów. Stwierdziłem jedynie, że skoro taki
> loader i tak zaciągamy asynchronicznie, to zyskamy jeszcze więcej jeśli osadzimy go
>bezpośrednio w kodzie strony, co, wnioskując z Twojej wypowiedzi robisz.
Ok. Czyli jednak zgadzamy się w tej kwestii.
> Nie zgodzę się także ze stwierdzeniem, że każdy skrypt zewnętrzny blokuje
> rendering. Jest już wspomniany przeze mnie atrybut [async], który dociąga
> skrypt asynchronocznie. I jest to jeszcze mniejszy nakład pracy niźli
> loader w przypadku, gdy nie ma ścisłych zależności między skryptami
Istotnie, w przypadku atrybutu „async” czy też „defer” tak nie jest i dociągany skrypt nie blokuje renderowania strony. Tylko że marna jest przydatność tych atrybutów z tego względu że można ich użyć w momencie gdy nie występują zależności pomiędzy skryptami. W dodatku nie wszystkie przeglądarki przeglądarki wspierają te atrybuty.
http://caniuse.com/script-async
http://caniuse.com/script-defer
W tym momencie trend jest taki że skryptów javascript jest coraz więcej i coraz bardziej zależą od siebie nawzajem.
]]>Nie twierdzę, że nie należy stosować loaderów. Stwierdziłem jedynie, że skoro taki loader i tak zaciągamy asynchronicznie, to zyskamy jeszcze więcej jeśli osadzimy go bezpośrednio w kodzie strony, co, wnioskując z Twojej wypowiedzi robisz.
Nie zgodzę się także ze stwierdzeniem, że każdy skrypt zewnętrzny blokuje rendering. Jest już wspomniany przeze mnie atrybut [async], który dociąga skrypt asynchronocznie. I jest to jeszcze mniejszy nakład pracy niźli loader w przypadku, gdy nie ma ścisłych zależności między skryptami
Bynajmniej. Ja robię tak że zawartość tego pliki „autoloadjs-seed.js” wklejam sobie bezpośrednio do nagłówka strony.
Pytasz co zyskam tym ? Doskonałe pytanie zadałeś ;) A zyskuję to że nie mam w źródle strony ani jednego znacznika który by się odwoływać do plików javascriptowych. Jak wiadomo każde dociąganie skryptu blokuje renderowanie strony na czas tego dociągnięcia.
W momencie gdy tych znaczników nie ma na stronie (osadzonych tym staromodnym sposobem, fuj) to zyskuję czas który strona by traciła na ich dociąganie.
Ja nie widzę przesady w zmniejszaniu czasu ładowania i to jeszcze bardzo niskim nakładem mojej pracy.
ad. 2) loader dociągany asynchronicznie to już przesada. IMO inlinowanie go w tym momencie. no i zawsze można po prostu dać [async] dla skryptów jeśli nie mamy złożonej sieci zależności
ad. 1) najważniejszy i tak jest above the fold, więc tutaj scroll mało pomoże IMO ;)
Lazy Load nie bardzo się przyda; we wpisach grafika jest głównie zaraz pod tytułem, na głównej wpisy są pobierane ajaxem ;)
Możecie polecić jakiś plugin do optymalizacji grafiki? Do tej pory korzystałem z Responsive.io, niestety (dla mnie) wyszli z bety i korzystanie jest płatne ;)
EWWW Image Optimizer nie działa na moim hostingu (zenbox).
Tak na szybko możesz spróbować dwa rozwiązania.
1. http://www.appelsiini.net/projects/lazyload – Obrazki doczytywane są na scrollu. Dzięki temu jest mniej żądań na początku. Dopiero przy przewijaniu się dociąga reszta.
2. https://github.com/szagi3891/autoloadjs – Asynchroniczne dociąganie skryptów js. Nawet sama biblioteka dociąga się asynchronicznie.
Te dwa rozwiązania „na szybko” mocno przyśpieszyć stronę. Oczywiście nie można zapominać o innych optymalizacjach.
]]>Mi za to Page Speed robi psikusa, i dla websem.pl nie wskazuje nic a nic – wyrzucając błąd :D
]]>Ja muszę za to pobawić się z cache, bo mam akurat wyłączone. Ciekawe jak przełoży się to na szybkość ładowania witryny.
]]>Super! Gratuluję wyniku.
]]>a dzięki ;) pomyślę jeszcze z tym CSS-em – być może uda mi się go jeszcze wyśrubować :D
]]>szewc bez butów chodzi?
Wygląda na to, że tak :)
BTW, wynik prędkości naprawdę dobry, gratuluję.
Może kiedyś choć zbliżę się do 100 ;)
]]>90 to rewelacyjny wynik. Tylko pogratulować! :)
Co do 100 – nie widziałem żadnej takiej strony, natomiast myślę że da się stworzyć stronę maksymalnie zoptymalizowaną, uwzględniając poszczególne elementy wskazane w narzędziu, choć czasami jest to niemożliwe – ze względu na chęć uzyskania konkretnych efektów :)
]]>W praktyce jest możliwość uzyskania 100 punktów?
]]>