Mimo, iż znam angielski to bardzo mnie drażni, że kupiona przezemnie kopia Photoshopa zainstalowana została po Polsku.

Ten mały trick jest całkowicie odwracalny i można dowolnie zmieniać z j. Polskiego na angielski i z powrotem.

A tak przy okazji ten patent działa na każdym języku obcym np. niemiecki, francuski, hiszpański etc. do języka angielskiego (oryginał).

Miłego oglądania.

URL: www.turbruk.pl

Online:

Opis: Usługi brukarskie to domena firmy TURBRUK. Od 2005 roku zajmowała się tylko tym. Od 2010 r. otarto nową hurtownie kostki brukowej i granitowej. Na dzień dzisiejszy firma dynamicznie się rozwija, przyjmuje nowych pracowników i zamawia nowe towary. Strona oczywiście działa w oparciu o "webSEOsys" i kilka ciekawych dodatków, jak np. Lightbox 2.0 jQuery. Jeszcze nie jest do końca skończona bo brakuje tu portfolio z usług brukarskich. Na dzień dzisjeszy głównie pozycjonuje tą stronę i rozwijam o nowe wpisy. Dopiszę tu coś jak tylko strona będzie skończona w 100% :D.

Sys: webSEOsys

Użytkownicy internetu mają obecnie dostęp do szerokiej gamy przeglądarek do serfowania po sieci. Naszą odpowiedzialnością jako designerów i developerów jest aby zapewnić by strony które tworzymy były kompatybilne z większością używanych przeglądarek.

To nas prowadzi do prostego aczkolwiek dość krytycznego pytania - jakiej przeglądarki używają nasi użytkownicy? Według w3school, najczęściej używanymi przeglądarkami są Internet Explorer 7 & 8 jak również Firefox z Safari i Google Chrome to tyczy się całości internetu (ogół). Jednak dane mogą się różnić od czasu do czasu, to zależy od różnych obliczeń. Najlepszą odpowiedź dostarczy nam monitoring naszych własnych stron takimi narzędziami jak na przyprzykład Google Analytics.

Kiedy już zidentyfikujemy najczęściej używane przeglądarki naszych użytkowników, należy sprawdzić czy nasza witryna poprawnie się wyświetla. Prawie niemożliwe jest aby instalować wszystkie typy przeglądarek na jednym komputerze aby to sprawdzić. Dla tego też istnieje szereg aplikacji i usług webowych, które ułatwią nam sprawdzenie, jak wygląda nasza witryna w różnych przeglądarkach.

W tym artykule spróbuje przykuć waszą uwagę na pewne rozwiązania które pomogą nam sprawdzić kompatybilność waszych stron w różnych przeglądarkach. Pełna lista na dole.

Testy Kompatybilności Online

Browsershots

Browsershots jest darmową i najbardziej popularną platformą do sprawdzania kompatybilności witryn w wielu przeglądarkach. Browsershots wykonuje screenshoty waszych internetowych projektów w różnych przeglądarkach. W bazie Browsershots występują prawie wszystkie popularne przeglądarki. Platforma jest dość łatwa do użycia, podajemy adres strony klikamy jaka przeglądarka ma zadziałać dla jakiego systemu operacyjnego i czekamy. Średni czas oczekiwania to około 30 min ale nie zawsze wszystkie nasze screeny przejdą w tym czasie więc możemy przedłużyć czas oczekiwania. Główną wadą jest czas który trzeba poświęcić na tej platformie. Polecam opcję płatną, wszystkie wyniki prawie natychmiast.

Browser Sandbox - POLECAM!

Ta platforma, stworzona przez Spoon.net, pozwala nam uruchomić różne przeglądarki wprost na naszym komputerze za pośrednictwem waszej przeglądarki. TO TAKIE PROSTE. W skład przeglądarek wchodzą IE, Firefox, Safari, Chrome i Opera. Największą zaletą tego sytemu to to, że możemy spokojnie i płynnie przejrzeć naszą witrynę z każdej strony, od strony głównej po panel administratora.

Netrenderer

IE NetRenderer to darmowa platforma do testowania kompatybilności witryn. Z IE NetRenderer możesz sprawdzić jak wasza witryna wygląda w różnych wersjach Internet Explorer. Po beta testach, IE NerTender stanie się integralną wersją przeglądarek od IE - IE9 i będziesz mógł zobaczyć błędy własnej witryny dla danej przeglądarki.

Browsrcamp

Browsrcamp pozwala nam sprawdzić nasze witryny z przeglądarkami Mac OS X. jeśli nie chcecie tracić pieniędzy możecie sprawdzić kompatybilność waszej witryn z Safari 3.1.2. Po prostu dodaj adres URL swojej witryny i otrzymasz screenshot. Ale jeśli chcesz sprawdzić waszą witrynę na innych Mac-owskich przeglądarkach musicie poświęcić 3$.

Adobe Browserlab

Adobe Browserlab to narzędzie, które pozwala twórca witryn do testowania is a web hosted service which allows designers to test designs on multiple browsers and operating systems. In this system are included a zoom function and measurement tools like rulers and guides, and the ability to move quickly to specific areas of a screenshot. Browser sets allow designers to customize, edit, and save a combination of browsers to test. ...

Litmusapp

Litmus pokazuje wam screenshoty waszej witryny gdy przejrzy projekt wszystkimi głównymi przeglądarkami internetowymi. Po skończeniu testów dostaniecie pełen raport kompatybilności gotowy do przejrzenia przez waszych klientów. Litmus posiada 4 plany cenowe. Możecie zarejestrować się za darmo ale używać można tylko IE 7 i FF2. AND IT'S IN ENGLISH. 

Anybrowser siteviewer

Anybrowser Site Viewer pozwala nam zobaczyć witrynę od zupełnie innej strony. Czyści kod i sprawia, że przeglądamy witrynę bez specjalnego kodowania. Możemy poruszać się po linkach jak w normalnej przeglądarce ale będzie to widok tylko tekstowy. Dobre kodowanie strony pozwoli nam również zobaczyć zdjęcia w stronie. Ciekawe narzędzie, warto sprawdzić.

Fundisom

Fundisom to Mac screenshot generator który pozwala na zobaczenie witryny na Macintosh G5 in Safari, MacIE lub Mozilla. Na chwilę obecną lixlpixel Safari Screenshot Generator jest offline, ale możecie sprawdzić ją później.

Delorie lynxview

Delorie lynxview to ciekawe narzędzie pozwalające zobaczyć tekstowa wersję waszej witryny. To ciekawe narzędzie przydaje się do różnych punktacji oraz pozwala narzędziom dla niewidomych poprawnie widzieć waszą witrynę. Do poprawnego działania narzędzia potrzebne jest umieszczenie pustego pliku delorie.htm w folderze głównym waszej witryny. 

Browsera

Browsera jest przeznaczona by użwać ją jako narzędzie do testowania a nie jedynie jako narzędzie do robienia screenshotów. Działa na wszystkie poziomy waszej witryny. Posiada plan darmowy dla 1 użytkownika do max 25 stron. Reszta planów jest płatna ale podlega 14dniowym, bezpłatnym testom.

IE Tab

IE Tab to dodatek dla Firefox który pozwala włączyć wam witryny w IE, bez konieczności otwierania innych okien przeglądarki. Wystarczy tylko kliknąć guzik na pasku FF i zostanie otwarta obecna strona w nowej zakładce która będzie używać silnika IE zamiast FF.

Pluginy i Narzędzia

IETester

IECapt

Multi-Safari

Expression Web SuperPreview

Iphoney

MultipleIEs

Multiple IE

SortSite Professional

Lunascape

Płatne usługi

Browsercam

Crossbrowsertesting

Browser Photo

Url2image

SortSite

Multi Browser Viewer

Cloud Testing

Więcej info znajdziecie tu: Complete Guide to Cross-Browser Compatibility Check http://www.hongkiat.com/blog/complete-guide-to-cross-browser-compatibility-check/#ixzz12yxO72Cc

Kody kolorów HTML są zapisane w systemie hexadecimal reprezentujące kolory czerwony, zielony i niebieski. Dla przykładu, w kolorze czerwonym, kodem koloru jest FF0000, co znaczy '255' czerwieni, '0' zieleni, i '0' Niebieskiego.

Kompletne informacje na temat jak stosować paletę kolorów w HTML używając w CSS, opiszę w innym artykule.

Tabele kolorów poniżej.

Podstawowa paleta kolorów hexadecimal

 Kolory wymieszane z podstawowej palety hexadecimal

 99% programów wspiera ten zapis kolorów, w przypadku gdyby wasz program nie radził sobie z zapisem hexalnym użyjcie dowolnego color pic np. CollorZilla dla FireFox.

Artykuł pochodzi z CODROPS

Ostatnio znalazłem dość ciekawe menu. Boczne inne niż wszystkie. Dziś spróbuje się zwami nim podzielić.

Zobacz Live Demo

Jeżeli demo was zainteres owało to bierzemy się do pracy.

1. Struktura HTML

Ustalamy prostą nawigację pamiętając o używaniu ID ponieważ będzie potrzebne przy javaScript

1 <ul id="navigation"> 2  <li class="home"><a title="Home"></a></li> 3  <li class="about"><a title="About"></a></li> 4  <li class="search"><a title="Search"></a></li> 5  <li class="photos"><a title="Photos"></a></li> 6  <li class="rssfeed"><a title="Rss Feed"></a></li> 7  <li class="podcasts"><a title="Podcasts"></a></li> 8  <li class="contact"><a title="Contact"></a></li> 9 </ul>

2. Kodowanie CSS

Najpierw musimy zakodować style dla listy:

 

1 ul#navigation { 2     position: fixed; 3     margin: 0px; 4     padding: 0px; 5     top: 10px; 6     left: 0px; 7     list-style: none; 8     z-index:9999; 9 }

 

Nawigacja powinna być zawsze dostępna dla użytkownika nawet podczas przesuwania strony.  Ten proglem rozwiązuje nam parametr position z opcją fixed. Aby Nawigacja była w odpowiednim miejscu ustawiamy parametry Margin i Padding na 0px . Teraz należy ustawić naszą nawigację nad wszystkimi innymi elementami dla tego też ustawiamy parametr z-index na najwyższą wartość 9999.

Teraz możemy zająć się kodowaniem elementów listy

1 ul#navigation li { 2     width: 100px; 3 }

Dla linków w liście nawigacji ustawiamy następujące style

01 ul#navigation li a { 02     display: block; 03     margin-left: -85px; 04     width: 100px; 05     height: 70px; 06     background-color:#CFCFCF; 07     background-repeat:no-repeat; 08     background-position:center center; 09     border:1px solid #AFAFAF; 10 }

Dla parametru Margin-left ustawiamy -85 px ponieważ chcemy ukryć tylko ikony a nie całą nawigację.

W części JavaScript zdefiniujemy opcję wysuwania się tej navigacji. Lecz najpierw dodajmy coś co IE nie lubi, tzn. zaokrąglenia :D

Na koniec nadajemy poszczególnym linkom ich ikony. Najlepsze icony znadziecie na portalu DryIcons. Polecam icony z 4 stron: 1, 2, 3 i 4.

I oto całe potrzebne CSS teraz zajmiemy się JavaScript aby tchnąć w naszą nawigację odrobinę życia.

3. Kodowanie JavaScript

Używamy jQuery, zrobimy tak aby ikony pokazywały się zawsze kiedy najedziemy na dany element listy. Pamiętaj, elementy listy same w sobie mają szerokość 100 px, tylko elementy linku są wypychane na zewnątrz strony tak aby nie były widoczne.

Musimy zdefiniować następującą funkcję (przed końcem body tag [</body>]) to spowoduje wykonanie funkcji kiedy nadjedziemy nad li:

A więc, najeżdżając na dany element dostaniemy lewy margin na -2 px, dodatkowo pięknie się animuje, nie za wolno i płynnie (200 milisekund). Odsuwając myszkę na zewnątrz menu element z powrotem wraca na swoją starą pozycje lewy margin -85 px. Funkcja stop() “stops all the currently running animations on all the specified elements”  która nadaje nam piękny efekt zatrzymania w przypadku szybkiego najeżdżania na wszystkie elementy. (bez tej funkcji całe menu będzie pływało aż wykona wszystkie wywołania).

Teraz na prawdę miło by było sprawić aby użytkownik miał świadomość istnienia tak niesamowitej nawigacji na jego stronie. W tej chwili, użytkownik ledwo widzi małe szare obramowania wystające z poza strony. Czy może być coś lepszego od pokazania całej nawigacji krótko przez załadowaniem się strony? I to właśnie zrobimy.

Tak więc, celowo, sprawimy aby nawigacja pojawiła się. Do tego celu zmienimy lewy margin elementu linku:

I dodamy następującą linię na początku funkcji JavaScript:

W tej linii zdefiniowaliśmy margin wszystkich elementów listy powinien dostać wartość -85 px na czas 1 sekundy. Dzięki temu pokazujemy nawigację a JavaScript ją ukryje.

I to wszystko!

Jeśli jesteś fanatykiem cieni, możemy dodać poniższe linie do swojego CSS:

Dodanie boxów cienia i usuwając parametr opacity, nadamy naszej nawigacji wygląd 3D. Zostawiając parametr opacity wygląd będzie nadal fajny, wypróbujcie to sami i bawcie się dobrze!

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ę.

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 i 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

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.

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:

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:

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:

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.