Responsive Web Design - kto mało pyta, nie błądzi
•
0 gefällt mir•1,241 views
Prezentacja z krakowskiego ITFest 2013, na temat prawdziwego znaczenia słowa "responsive".
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Responsive Web Design - kto mało pyta, nie błądzi
Ähnlich wie Responsive Web Design - kto mało pyta, nie błądzi (20)
Responsive Web Design - kto mało pyta, nie błądzi
- 1. Responsive Web Design kto mało pyta, nie błądzi Jakub Wiśniewski, Kraków 24.5.2013
- 2. Agenda ● O znaczeniu słowa „responsive” ● Kilka słów o konsumpcji treści ● Wnioski, przykłady oraz jedna dygresja ● Wskazówki i porady praktyczne
- 3. Wstęp ● Poznań – Lublin – Kraków - ... ● UAM / UMCS / Zend PHP5 Certificate ● Freelancer od 2003 ● Od 2011 IT Project Leader w
- 5. „responsive” wg Oxford Dictionary reacting quickly and positively quickly - at a fast speed; rapidly http://oxforddictionaries.com/definition/english/responsive
- 6. WNIOSEK #1 responsive to nie tylko: @media screen and (max-width: 600px) { .class { background: #ccc; } }
- 7. Trochę o konsumpcji Różne treści i narzędzia do ich konsumpcji
- 9. Tekst pisany i gazeta / książka
- 11. Strony WWW i przeglądarki web
- 12. Analogia Strona www i przeglądarka są jak tekst pisany i książka
- 13. Czy aby na pewno? Czy strona www i przeglądarka naprawdę są jak tekst pisany i książka?
- 16. Analogia – podejście drugie Strona www i przeglądarka są jak tekst pisany i książka audycja TV i telewizor?
- 22. WNIOSEK #2 Strona www i przeglądarka są jak audycja TV i telewizor
- 23. Krótka dygresja
- 24. Wielkie Pytanie o Internet, RWD i Całą Resztę
- 26. POKAZ ● IE ● FF ● Chrome
- 27. Techniki i narzędzia dla większej prędkości działania responsive – quickly – at a fast speed; rapidly
- 31. Y U NO SPEED!?
- 32. Ograniczenia przeglądarek limit równoległych połączeń na host = 6 http://www.browserscope.org/?category=network
- 33. kto mało pyta (serwer o zasoby), nie błądzi ● mniej plików graficznych ● mniej plików .css ● mniej plików .js
- 34. mniej obrazków ● kod CSS3 zamiast <img> http://css3generator.com/ http://www.cssmatic.com/ ● data URIs zamiast <img> {background: url(data:image/gif;base64,R0lGODlh...)} https://github.com/nzakas/cssembed http://dataurl.net/ ● image sprites {background-position: -450px -300px}
- 35. XI. optymalizuj ● jpegtran http://jpegclub.org/ ● jpegoptim http://freshmeat.net/projects/jpegoptim/ ● OptiPNG http://optipng.sourceforge.net/ ● PNGOUT http://www.advsys.net/ken/util/pngout.htm ● TinyPNG http://tinypng.org/
- 36. mniej plików o mniejszym rozmiarze ● cssmin http://code.google.com/p/cssmin/ ● jsmin http://www.crockford.com/javascript/jsmin.html ● YUIcompressor http://developer.yahoo.com/yui/compressor/
- 37. mniej kodu CSS div { display: block; margin: 0; }
- 38. Mniej HTML ● mniej obiektów DOM <div><ul><li>... </li></ul></div> ● preg_replace return preg_replace('/[ ]{2,}/', ' ', preg_replace('/[nrt]{1,}/', '', $html)); ● <a href=”http://www.domain.com”>foo<a/>
- 39. Mniej transferu ● cache-controll ExpiresByType image/gif "access plus 1 month" ● kompresja zlib php_flag zlib.output_compression on ● statyczna treść na subdomeny, najlepiej kilka ● SSL ● lazyloading ● header 301
- 40. DNS prefetch <html> <head> <link rel="dns-prefetch" href="//www.domain1.com"> <link rel="prefetch" href="//www.domain2.com"> <!-- dla IE --> </head> <body> ... <img src="www.domain1.com/image1.jpeg"> <script src="www.domain2.com/script1.js"> </body> </html>
- 41. Bez DNS Prefetch
- 42. Z DNS Prefetch
- 43. Mniej bajerów* animacja w JS = większe obciążenie CPU = większy pobór mocy = krótsze życie baterii *animacje w CSS są OK {-webkit-transition: background-color .4s linear;}
- 44. POKAZ ● Animacja w iphone 3
- 45. Minimalizacja zmian układu strony Deklarowanie wymiaru obrazków http://dev.w3.org/html5/markup/img.html#img.attrs.height
- 46. POKAZ ● Smashing @ kindle
- 47. Czego dziś się dowiedzieliśmy? ● responsive == quick ● Strona www i przeglądarka ~ Audycja i TV ● Nope. ● Mniej jpg, css, js, html ● XI. optymalizuj, kompresuj i cache'uj
- 49. Dziękuję za uwagę kto mało pyta, nie błądzi Jakub Wiśniewski - j.w.wisniewski@gmail.com Responsive Web Design
Hinweis der Redaktion
- Witam wszystkich Nazywam się Jakub Wiśniewski Opowiem dziś wam trochę o Responsive Web Design Wbrew podtytułowi zachęcam wszystkich do zadawania pytań Znaczenie podtytułu wyjaśni się w trakcie prezentacji
- | Na początek krótko przedstawię znaczenie słowa „responsive” |Dalej powiemy sobie trochę o konsumpcji |Jesli ktoś w trakcie prezentacji zrobi się głodny, to na zewnątrz na pewno znajdzie coś na ząb |Wyciągniegniemy sobie kilka wniosków oraz zademonstruję wam kilka przykładów | A w drugiej części – mając podstawy teoretyczne – przejdziemy do wskazówek i porad praktycznych
- OK wiemy o czym będzie dziś prezentacja | Zanim jednak zaczniemy, kilka słów o osobie, która przed Wami stoi
- OK, to zaczynamy Będziemy mówić o responsive web design Czym dla... zwykłej osoby, gdzie przez zwykłą osobę rozumiem, programistę z wewnętrzną naturą „geeka”, który od kilku lat zajmuje tworzeniem stron, jest RWD? Słyszymy RWD, co przychodzi na myśl? - @media queries - Adaptowanie układu strony do szerokości ekranu urządzienia - CSS3 / HTML5 To wszystko prawda, ale...
- Spójrzcie jednak na definicję słowa 'responsive' ze słownika Oksforda To znaczenie, o którym większość dziś zdaje się zapominać I na tym znaczeniu słowa responsive, dziś będę się skupiał
- Czas zatem na pierwszy wniosek Responsive to nie tylko media queries Responsywność to przede wszystkim szybkość działania i reakcji na zachowania użytkownika: kliknięcia, tapnięcia i gesty palcami wykonywane na ekranie dotykowym … ??
- Teraz trochę o konsumpcji Każdy z nas jest konsumentem W taki lub inny sposób, nawet jeśli nie zdaje sobie z tego sprawy Oto kilka przykładów, które doprowadzą nas do drugiego wniosku w naszej prezentacji
- Pierwszy, najbardziej oczywisty przykład jeśli chodzi o konsumpcję: jedzenie Jedzenie jako treść I sztućce jako narzędzia do konsumowania treści
- Idąc dalej: Tekst/słowo pisane, które niesie ze sobą konkretny przekaz Oraz druk, książki, gazety, w setkach, tysiącach identycznych egzemplarzy jako narzędzi umożliwiających nam dostęp do tej treści
- Kolejny przykład. Telewizja. Treść - czyli audycja nadawana przez kabel lub satelitę (a od kliku dni tylko cyfrowo) oraz telewizor, czyli narzędzie przystosowane do oglądania tej treści
- No i w końcu internet Strony www oraz przeglądarki Treść oraz narzędzia, które używamy by z tą treścią się zapoznać Zauważcie, że w poprzednich dwóch przykładach, na przestrzeni czasu, wraz z rozwojem technologii, pokazane narzędzia ewoluują. Tekst pisany – rysunek naskalny/kamień, tekst pisany i zwoje papirusu, tekst drukowany i książki gazety, a teraz także „tekst cyfrowy” i czytniki ebooków Telewizja – cz/b i telewizory lampowe, później kolorowa, teraz wysokiej rozdzielczości i płaskie telewizory, cyfrowe hdtv Gdy pojawia się nowa technologia – stara wymiera, przestaje być wspierana i nikt z tego powodu się nie bulwersuje.
- Internet, strony WWW i przeglądarki to najmłodszy z pokazanych wynalazków Po jego stworzeniu, staraliśmy się jakoś go „skatalogować”, porównać przez analogię, do wcześniejszych Strony internetowe, z racji na ograniczoną szybkość łączy, sprowadzały się większości do treści pisanej. Stąd też przyjęliśmy analogię, że strony www i przeglądarki są jak tekst pisany i książki
- Pytanie jednak – czy to dobra analogia? W ramach jednego nakładu wszystkie książki są identyczne – i poprzez tę analogię – wpadliśmy w obsesje,
- aby strony internetowe w każdej przeglądarce wyglądały tak samo.
- Gdy sugerujemy coś innego, ludzie patrzą na nas krzywo i się złoszczą
- Spróbujmy zatem jeszcze raz i Zacznijmy naszą analogię od nowa
- Mamy starą przeglądarkę, która jest jak stary telewizor
- Oraz nową przeglądarkę, która jest jak nowy telewizor hd z bazylionem cali w przękątnej
- Jak widać sprawa jest prosta i wszystko jest jasne. Telewizja rozwiązała ten problem Nikt nie skaży się że na starym odbiorniku, nie może oglądać telewizji w HD.
- Taki efekt jednak osiągamy, gdy trzymamy się pierwszej analogii, według której we wszystkich przeglądarkach wygląd stron ma być identyczny.
- Nie trzeba chyba dodawać nic więcej, Nie jest to najlepsza droga
- Wniosek #2 zatem brzmi
- Dobrze, teraz czas na krótką dygresję... Pomoże nam ona w zrozumieniu poprawności drugiego wniosku
- Podam Wam teraz odpowiedź na wielkie pytanie dotyczące projektowanie stron www Czy ktoś z was wie jak ona jest ?
- Czy strony muszą być tak samo doświadczane w każdej przeglądarce?
- Teraz mała demonstracja, aby nie pozostać gołosłownym Jak widzicie, forma się różni, ale treść pozostaje bez zmian Innymi słowy aby przekazać użytkownikowi konkretną wiadomość nie jest konieczne dążenie do tego, by zawsze i wszędzie forma przekazu była identyczna
- OK, jesteśmy mniej więcej w połowie, zatem po odrobinie teorii, czas na trochę praktycznych wskazówek, jak osiągnąć wysoką prędkość działania
- Dlaczego prędkość jest tak ważna?
- Dotychczas, gdy internet nie był mobilny, sytuacja przedstawiała się następująco. Komputer stacjonarny, nierzadko podłączony bezpośrednio, z publicznym IP, oddzielony od docelowego serwera zaledwie o kilka hopów
- Teraz natomiast, pomiędzy użytkownikiem końcowym a serwerem jest znacznie dłuższa droga, mamy więcej maszyn pośrednich i biorących udział w komunikacji Użytkownik jest też mobilny, co niesie za sobą gorszą jakość łącza, większy potencjał błędów oraz technicznie patrząc – w porównaniu z kablem, czy światłowodem – niższą przepustowość
- Jeśli ktoś nadal nie jest przekonany, i zadaje sobie pytanie „no ale dlaczego(!)?”
- Powód jest prosty, limit połączeń wynosi 6 Wyjątkiem jest teraz IE 10 z limitem wynoszącym 8. Co to oznacza? Przeglądarka jest w stanie jednocześnie pobierać tylko 6 zasobów: CSS, JS, obrazków Gdy na stronie mamy ich 60, to potrzebnych będzie 10 cykli, by pobrać wszystkie i to że mamy akurat dostępne łącze 3G i dostępny 1 megabit, nie ma tu znaczenia
- Celem naszym jest zatem ograniczenie ilości zasobów, które będzie musiała pobrać przeglądarka.
- Wszędzie gdzie to możliwe powinniśmy zastąpić grafiki kodem CSS3 – cienie, gradienty, zaokrąglone rogi – wszystko to co kiedyś osiągalne było za pomocą grafik, teraz to jedynie kilka linii kodu Bardziej skomplikowane elementy graficzne można umieścić inline zamiast odwoływać się do zasobów zewnętrznych wykorzystując Data URI. Jedyną wadą tego rozwiązania jest około 40% przyrost danych w porównaniu z oryginałem z racji na kodowanie base64 Można też połączyć wiele obrazów w jeden większy sprite i zamiast n osobnych requestów, wykonywać tylko 1 i pobawić się ujemnymi wartościami background position
- Gdy skorzystanie z zewnętrznego zasobu jest jednak konieczne, to przed umieszczenie grafiki na serwerze dobrze będzie przepuścić ją przez optymalizator. Szczególnie duże oszczędności uzyskamy, w przypadku małych grafik zapisywanych z Photoshopa, w których procent komentarzy-śmieci pośród wszystkich danych w pliku graficznym wynosi nierzadko kilkadziesiąt procent
- Kolejnym elementem jaki można zoptymalizować to skrypty i style. Usuwanie zbędnych białych znaków, komentarzy, pustych bloków i deklaracji Także łączenie wielu plików w jeden wynikowy by zminimalizować ilośćrequestów do serwera, to przydatne zabiegi. Krótki research w google, da wam dziesiątki linków do aplikacji desktop i online
- Wszelkie minifikatory usuną nam zbędne spacje, zbędne średniki z końca linii, jednakże błędów logicznych, czy też semantycznych nie poprawią. O te rzeczy musimy dbać samemu.
- Owijanie listy, która jest już elementem blokowym, w kolejny kontener jest w większości przypadków zbędne Z pomocą w ograniczeniu ilości przesyłanych danych przyjdzie nam też zwykłe wycięcie zbędnych białych znaków z wynikowego HTMLa Zauważcie też, że prefix http: jest zbędny
- W ograniczeniu ilości przesyłania danych pomoże nam poprawna konfiguracja pamięci podręcznej i kompresji danych na wyjściu serwera Ciekawostka – kiedyś - Home.pl / nazwa.pl – brak kompresji i cache'owania Ststyczna treść na subdomen - Obrazki, video, css – ograniczenie ilosci cookie Ciekawostka - Analytics domyślnie na poddomeny SLL = brak pamięci podręcznej Lazy loading - Bounce rate, niepotrzebnie pobrane obrazki, treść Redirect w htaccess 20-30ms, w kodzie PHP 200-300ms
- Jak pamiętacie z jednego z poprzednich slajdów w przypadku użytkownika mobilnego serwer DNS może być od niego znacznie oddalony Warto zatem w nagłówku dokumentu, powiedzieć przeglądarce, o które domeny zawczasu ma odpytać serwer DNS http://tech.vg.no/2013/02/09/speed-up-websites-using-dns-prefetching/
- http://s.codepen.io/paulirish/fullpage/nkwKs http://codepen.io/paulirish/full/LsxyF Testowanie na różnych choć tych samych urządzeniach
- I na koniec jeszcze jedna wskazówka Zwracajcie uwagę na to, bo ograniczać ilość zmian układu strony. Atrybuty width i height dla obrazków są jak najbardziej poprawne w HTML5 Dają one przeglądarce informacje o tym ile miejsca zarezerwować na stronie na grafikę, która załaduje się dopiero za jakiś czas
- Wyolbrzymiony Ale dobitnie pokazujący w czym rzecz
- Na koniec, krótkie podsumowanie Responsywność to przede wszystkim szybkość działania i rekacji na akcje użytkownika Strony internetowe i przeglądarki, Aby zachować jednoznaczność przekazu, jego forma nie musi być zawsze ta sama. Możemy zrezygnować – mówiąć kolokwialnie – ze zbędnych bajerów, bez ryzyka, że snie przekażemy użytkownikowi części treści Aby zachowaćszybkośćdziałania, im mniej wszystkiego - mniej grafik ,styli, skryptów, użytego transferu, tym lepiej