Google Page Speed

Google Page Speed and Yslow 2.0

Może to już nie jest super nowinka ale postanowiłem rozpisać się na ten temat troszkę. 

 

Wkrótce po wydaniu przez Yahoo swojego Yslow, Google opublikowało Page Speed. Te narzędzia służą głównie do optymalizacji stron internetowych. Szczerze powiem, że prócz standardu w3c, to właśnie Page Speed i Yslow są moimi głównymi narzędziami przy tworzeniu stron. 

 

Page Speed jest podobny do Yslow w wielu aspektach. Pracuje na pluginie FireFox "FIREBUG". Analizue stronę zgodnie z zestaw <script type="> langs/en.js" type="text/javascript"> em określ  onych reguł (któr  e tu opiszę). Nie trzymanie się tych reguł może sprawić słabsze wyniki w pozycjonowaniu (przynajmniej według mnie) automatycznie przy instalacji otrzymujemy monitor aktywności strony (Page Speed Activity) o którym dziś nie napiszę.


Google Page Speed
Dla każdej reguły, Page Speed podaje łatwo i prz  ejrzyście jak sobie radzisz, zielony haczyk (Dobrze - jak jest + to jeszcze coś można poprawić), czerwone kółko (Źle - szybko napraw) lub pomarańczowy trójkącik (Średnio - ani dobrze ani źle). Jest również ogólny wynik procentowy, ale wszystkie sugestie nie są posegregowane względem ważności. 

 

Page Speed i Yslow 1.0 wspólne reguły

Te reguły są takie same dla obu przypadków. Postaram się rozpisać je w dalszej części.

  • Avoid CSS expressions 
  • Combine external CSS
  • Combine external javascript
  • Enable gzip compression
  • Leverage browser caching
  • Minify javascript
  • Minimize DNS lookups
  • Minimize redirects
  • Parallelize downloads across multiple hostnames
  • Put CSS in the document head

Page Speed może czasami doradzać abyś zrobił dość głupie rzeczy. Np. reguła “Leverage browser caching”, Page Speed sugeruje abyś zrobił __utm.gif cacheable. Ten malutki gif jest używany przez Google Analytics do prowadzenia statystyk. Jeżeli zrobi się go cacheable, Analytics przestanie śledzić użytkowników którzy wrócili z cache. Moja rada Zostaw go w spokoju!

Page Speed i Yslow 2.0 wspólne reguły

  • Minimize cookie size
  • Serve static content from a cookie-less domain
  • Specify image dimensions

Minimize cookie size

Google jest tu troszkę bardziej konkretny niż Yslow: Utrzymaj średnią wagę cookie poniżej 400 bytes. Mój webSEOsys w standardzie spełnia tą regułę dla obu narzędzi.

Serve static content from a cookie-less domain

Nie jestem przekonany do tej reguły i podejrzewam, że wiele innych webmasterów też tak się do tego odniesie. Niespodziewanie Page speed i Yslow 2.0 sugerują aby komponenty strony take jak images (obrazy), również posiadały cookies. Według mnie to jest generalnie bezsensu i nie ma większego zastosowania przy ruchu sieciowym. Najlepszym sposobem naprawienia tej reguły to użycie CND, oczywiście to również pozwoli na wyższy wynik  w Yslow "Use a CDN".

Specify image dimensions

W końcu dość leniwym projektantom, którzy często biorą ogromne zdjęcia i używają HTML do zgniatania go do pożądanych rozmiarów. W konsekwencji waga pliku będzie znacznie większa niż potrzeba  .

Nie używaj HTML do zmiany rozmiaru zdjęć! Używaj do tego programów graficznych (np. darmowego programu FastStone Photo Resizer). Atrybuty width height w HTML w tagu <img> powinien dokładnie odpowiadać prawdziwym rozmiarom obrazu. Trzymając się tego nie będziecie mieć problemu z wyglądem obrazu w różnych przeglądarkach, bo nie będą musiały skalować obrazu.

Tu raczej powinniście mieć zawsze Perfekcyjny wynik! Tylko wszystko trzeba robić jak należy!

Reguły tylko dla Page Speed

W niektórych przypadkach porady Yslow mogą zawierać poniższe tematy, jednak nie są one wynikiem automatycznego sprawdzania waszej strony.

  • Defer loading of javascript
  • Optimize images
  • Optimize the order of styles and scripts
  • Remove unused CSS
  • Serve resources from a consistent URL
  • Leverage proxy caching
  • Use efficient CSS selectors

Defer loading of javascript

Zanim będziesz mógł uruchomić tę regułę, będziesz musiał uruchomić opcję “Profile Deferrable Javascript” w opcjach FireFox. Polecam wyłączyć tą opcję po wykonaniu testów ponieważ FireFox może bardzo zwolnić. Sam nie używam tej opcji przy sprawdzaniu. Większość błędów które otrzymałem pochodziły wprost od Google ga.js. W sumie mieszanie przy ich ustawieniach może pomieszać nam wyniki Google Analytics. 

Kiedyś to opiszę bardziej szczegółowo, może ktoś z was coś w komentarzach napisze.

A tu procedura uruchomienia “Profile Deferrable Javascript”

  1. (Re-)start Firefox.
  2. Select Tools > Firebug > Open Firebug.
  3. In the Firebug window, select the Page Speed tab, and click the down arrow to display the options pop-up menu
  4. From the pop-up menu, select Profile Deferrable JavaScript.
  5. Navigate to the web page you want to analyze. 
  6. When the page has finished loading, click Analyze Performance.
  7. To run the profiler against another page, close Firefox and restart the procedure.

Optimise images

Page Speed automatycznie tworzy zoptymalizowaną wersję waszych plików i linka do nich. Szczerze, to jest najlepsza funkcja w całym Page Speed.  This is similar to running your images through Smush.it.

Optimise the order of styles and scripts

To jest najprostsza reguła ze wszystkich. Pamiętaj Style nad skryptami!. Idealnie wygląda to mniej więcej tak

 

1 <head>
2
<link href="css/style.css" rel="stylesheet" type="text/css" />
3
<script language="javascript" type="text/javascript" src="js/slider/jquery-1.3.2.min.js"></script>
4 </head>

 

Remove unused CSS

No tak, to jest prawie nie możliwe. Dobrze, że mówię prawie :D. Jeżeli ktoś piszę szablon strony oparty o CSS to standardowo robi się prosty HTML z CSS który uwzględnia wszystkie zmienne, takie jak ramki, boxy, divy, ul ale również ul w div, ul w table itd. Próbujemy przewidzieć wszystkie możliwe elementy strony tak aby zawsze wyglądała pięknie. Ale właśnie to asekuranctwo jest karane. Idealne rozwiązanie to tworzenie strony np. index.html i index.css a w nim tylko to co ma index.html, potem np. artykuł-1.html i artykul-1.html. Chodzi po prostu o wywalenie nie potrzebnych styli. 

Tą regułę należy zmodyfikować do potrzeb własnych. Niestety w 90% przypadków nie można osiągnąć 100% ponieważ ciężko osiągnąć ideał dla np. CMS który ma 10 tyś. podstron. Polecam budować własne style od zera wtedy jest ładnie i przejrzyście. 

 

Serve resources from a consistent URL

To jest dość oczywisty punkt reguł Page Speed. W większości przypadku nie ma z tym problemów, jedynie jeśli robisz coś wymyślatego lub zautomatyzowanego, patrzy wszystkie CMS, rozdziel adresy do obrazów, bądź adresy styli, bądź adresy do .js po wielu subdomenach. np.

1 http://js1seo.svajs.pl/js/slider/jquery-1.3.2.min.js
2 http://img1seo.svajs.pl/images/articles/sample.gif
3 http://css1seo.svajs.pl/css/style.css

Leverage proxy caching

Dobra To jest sprytne. Kiedy ludzie odwiedzają twoją stronę, zasoby mogą by przechowywane przeznich ale nie tylko, również przez ich ISP. Jeśli po tym inny użytkownik przyjdzie z tego samego ISP, może ściągnąć zasoby o twojej stronie z cache swojego ISP, co będzie szybsze, ponieważ ma bliżej do niego niż do twojego serwera. Page Speed’s rekomenduje, z małymi wyjątkami, aby ustawić Cache-control: public header dla statycznych zasobów (takich jak obrazy).

Uwaga nie róbcie tego dla zasobów które mają ciasteczka dołączone, by nie skończyć na udostępnieniu informacji które powinny być prywatne o twoich odwiedzających. Również uważajcie z gzip-owaniem, niektóre Proxy mogą wysłać treść z gzip-a do przeglądarki które nie będą mogły go odczytać.

Na temat tej reguły zapraszam do dyskusji.

Use efficient CSS selectors

This rule is controversial. The idea is that some CSS selectors are much harder for the browser to parse than others; the most efficient are ID and Class selectors, because these do not require the browser to look higher up the document tree to determine a match.

With this rule, Google is recommending a radical change in the way we write CSS. Specifically, they are suggesting that we add otherwise unnecessary ID’s and classes to the markup, in return for a speed advantage. As an example, they consider the situation where you want different colours on ordered and unordered list items:

1 ul li {colorblue;}
2 ol li {colorred;}

That would be the usual way to do it; instead, Google recommends adding a class to each <li>, so that you can use class selectors:

1 .unordered-list-item {colorblue;}
2 .ordered-list-item {colorred;}

No doubt this is faster, but it also takes longer to write and imposes a maintainance burden in your markup. If there were tools that would automatically generate such optimised CSS and the accompanying markup, then it might be worth doing. I suppose you could use server-side coding to generate the markup—for example, using the HTML helper from CakePHP—but this seems a heavy-handed approach.

My scepticism over this rule was initially quashed by the towering authority of Google, but then I looked around to see whether there was any research on the subject. The most respectable tests I could find came from Steve Souders himself, in his post about theperformance impact of CSS selectors. Steve found that, in real-world conditions, the maximum possible benefit of optimising CSS is 50 ms; and for 70% of users (i.e. those running IE7 or FF3), it’s only 20 ms. These numbers were obtained with 6000 DOM elements and 2000 extremely inefficient CSS rules. This is pretty much a worst-case scenario; most sites, even complex ones, will have far fewer DOM elements and CSS rules, and their CSS will also be much simpler.

Steve concludes that the potential performance benefits are small, and not worth the cost. I’m inclined to agree, but I’d welcome more information.

Nevertheless, there’s no harm in getting into good habits: some of Google’s recommendations for CSS selectors are quite reasonable, such as not over-qualifying ID and class selectors with an antecedent tag selector (so .errorMessage is better than p.errorMessage). Such coding habits also sit harmoniously with object-oriented CSS.

If you read Steve’s post, be sure to check out Nicole Sullivan’s comment: “Micro-optimization of selectors is going a bit off track in a performance analysis of CSS. The focus should be on scalable CSS.” To me, this seems a much more sensible and maintainable approach than the monomaniacal one recommended by Google.

I do extremely badly on this rule (0%). Although I consider the recommendations to be unrealistic, my terrible score does reflect the excessive complexity and lack of modularity within my CSS.

Rules unique to Yslow 2.0

In some cases, Page Speed’s guidelines may include these topics, but not in the form of an automated check on your web page.

Note that Yahoo’s documentation includes other recommendations that are not checked by Yslow (because they haven’t discovered a sensible way to automate the test). Yslow has 22 rules, but Yahoo lists 34 best practices in total.

  • Reduce the number of DOM elements
  • Make favicon small and cacheable
  • Avoid HTTP 404 (Not Found) errors
  • Avoid AlphaImageLoader filter
  • Make AJAX cacheable
  • Use GET for AJAX requests

Reduce the number of DOM elements

The more DOM elements you have, the longer it takes to download your page, to render it, and to play with the DOM via javascript.

Essentially, this rule asks you to avoid large amounts of unnecessary markup, including markup added by javascript. As an example, yahoo.com has about 700 DOM nodes, despite being a busy page. My home page has 267 DOM nodes, and that could be reduced a lot. You can check how many nodes your page has, by entering the following into Firebug’s console:

1 document.getElementsByTagName('*').length

Blindly applying this rule can be dangerous (and that’s true of many performance rules). Don’t cut off your nose to spite your face! Markup purists will take this rule as a vindication for using the absolute minimum of markup, and in particular for avoiding the use of container <div>s whenever possible. This will leave them with hideously convoluted CSS and problems maintaining their code.

By all means remove extraneous markup, and also try to limit the complexity of DOM access in your javascript (for example, avoid using javascript to fix layout issues—here I have sinned). But never be afraid to throw in an extra container <div> when you can see it will make life easier.

Make favicon.ico small and cacheable

You might think that a favicon is not even worth the HTTP request, but you don’t get a say in the matter: the browser is going to request it anyway. Make one, make it small, and put it in the root directory of your website (where the browser will look for it).

Because you can’t change the name of this file—it must be called favicon.ico, or it won’t work—you should be moderate in setting its expiry date. It’s hardly essential that your visitors immediately get your latest favicon, but equally you wouldn’t want it to be cached for 10 years! I give mine a two-month shelf-life.

Avoid HTTP 404 (Not Found) errors

This one is obvious. If your document has broken links, fix them.

Avoid AlphaImageLoader filter

Ah, good old alpha-transparent PNG’s; how we love them! What web designer hasn’t flirted with multi-layer scrolling transparencies at some point? And who has not felt a sense of satisfied mastery, upon forcing IE6 to eat them via a clever hack?

The sobering reality is that, although you can make alpha-transparency work in IE6, you pay a heavy price for doing so. All the hacks rely on Microsoft’s AlphaImageLoader filter. Not only does this filter block rendering and freeze the browser while it’s being calculated, but it also increases memory consumption. To make matters worse, the performance penalty is incurred for each element, not for each image. For example, let’s say you have a fancy alpha-transparent bullet point image for your unordered list items; on a page with 20 bullets, you get the penalty 20 times over.

Use PNG-8 transparency instead, if you can. Incidentally, creating a web page from multiple layers of transparency is probably a bad idea anyway: even in good browsers, these kinds of pages are sluggish to scroll; find a better medium for expressing latent op art.

Make AJAX cacheable, and use GET for AJAX requests

I can’t pretend to understand these rules properly, having never used AJAX. Nevertheless, the ideas are straightforward.

If a resource has not changed since it was fetched, we want to read it from cache rather than getting a new copy; this applies just as much to something requested via AJAX. Steve summarises it thus:

Even though your Ajax responses are created dynamically, and might only be applicable to a single user, they can still be cached. Doing so will make your Web 2.0 apps faster.

Apparently, GET is more efficient than POST, because it can send data in a single packet, whereas POST takes two steps: first send the headers, then send the data. Providing your data is less than 2 kB (a limit on the URL length in IE), you should be able to use GET for AJAX requests.

Conclusions

Google Page Speed is a useful new tool for optimising your websites’ performance. However, some of its advice can be misleading—in particular, CSS selector efficiency is a red herring that distracts you from the more useful goal of building object-oriented CSS.

Yslow is the more mature tool, and I recommend you give it priority. After you’ve finished with Yslow, you may be interested in what Page Speed has to say.

Komentarze

Uwaga - Konta gości nie są zatwierdzane na bieżąco!