För Blogger.com: Optimera laddningstiden (unikt tips) för din blogg

12/14/2008

Blogger.com ger tips om hjälpsidor när man har postat något nytt. En jag läste var: How can I make my blog load faster? Det fick jag mig att fundera över det problemet generellt och jag kom på ett mycket bättre tips specifikt för att lösa ett problem Blogger.com har som faktiskt gör en väldigt tydlig skillnad.

Vad rekommenderar Google?
Låt oss först börja tipsen Google ger som nog kan tillföra lite ibland även om situationer där det gör någon mätbar skillnad bör vara sällsynta. Därefter tar vi min potenta upptäckt. Tipsen Google ger är i sammandrag:

  1. Färre bloggpostningar man visar på startsida / arkivsida påverkar hastighet. Färre ger bättre laddningstid.
  2. Widgets, Javascript m.m. ska vara bättre att placera långt ner på sidan. Vill du ha dem i sidebar så placera dem långt ner.
  3. Fler bilder ökar laddningstiden.
  4. Google Picasa Web Albums påstås vara bättre än andra liknande men jag kan inte inse att det regelmässigt kan stämma (såvida inte Google gör någon onödig egen kontroll varje gång de ska presentera bild-tag men det tror jag inte alls att de gör). Det beror istället givetvis på hastigheten mellan bildtjänsten och den som besöker sidan. Faktiskt kan jag säga att min erfarenhet är att Flickr ger snabbare laddning på Blogger.com åtminstone i Sverige på Comhem i Uppsala än Google Picasa Web Albums (¬_¬) Läs här även Komplettering till "Blogger.com: Optimera laddningstiden (unikt tips) för din blogg"!!!
  5. Custom CSS ska vara bäst att ha högst upp i koden.
  6. De rekommenderar verktyget Stopwatch som beräknar laddningstid.

Kommentar om: Google/Blogger widgets, JavaScipt and links
Avseende tips två uttrycker sig Google så här:

"For optimal blog load speed, we recommend using Google/Blogger widgets, JavaScipt and links. However, if you need to use third party JavaScipt and links, your blog will load much faster if you put all JavaScript at the bottom of your blog. If you have third party JavaScript and links in your sidebar, put them in at the bottom of the sidebar."

Det vill jag göra några kommentarer om. Först och mst har det i sig ingen påverkan om det är Google/Blogger widgets eller inte. När det gäller de widget som finns i deras bibliotek går det av och till att snabba upp dem något lite genom att förbättra koden. Men jag ska inte utesluta att Google eller någon annan faktiskt jämfört med dessa med widget från annat håll och kommit fram till de Blogger.com har i sitt bibliotek faktiskt i genomsnitt är snabbare för exakt samma funktionalitet de leverar. Inte heller vill jag utesluta att Google lagt till någon (troligen onödig) teknisk detalj som skulle gynna just dessa Widgets. Men jag tivlar mycket starkt på detta (om jag inte helt fattat fel vad de egentligen menar).

Vidare det här med "third party links" vet jag inte riktigt vad de menar. Kanske menar man widgets som automatiskt visar länkar t.ex. till foton i ditt fotoalbum? Men samtidigt uttrycker de sig på ett sätt att det är separerat från widget.

Mitt mycket bättre optimeringstips för Blogger.com
Tipsen Google ger är i helhet helt ok och de flesta där är inte specifika för Blogger.com utan kan fungera för andra bloggar också. Däremot har de sällan någon stor effekt numera och hade mycket större betydelse säg för 5 - 10 år sedan. Det finns vissa undantag från detta t.ex. om du använder mycket bilder och visar många bloggpostningar på startsidan eller har massor av widgets som laddar data från många håll.

Men när det kommer till laddningstid på Blogger.com finns ett problem jag upplever är specifikt just för Blogger som är betydligt mer tydligt. Inga av tipsen adresserar detta. Problemet är följande:

  • Blogger.com kan för vissa nedladdningar "hänga".
  • När det sker kan du trycka return engång till på URL och då laddar sidan normalt direkt.

Det problemet har mycket sannolikt ingenting med själva innehållet på sidan utan hur det du visar på sidan utnyttjar delade resurser på Blogger.com. Detta är dock min tolkning och gissning (om än ganska kompetent sådan). Där finns kan man anta en resurs som lastdelas där besökaren kan ha otur och komma på en server som är lite överlastad. Att problemet normalt helt går bort när du trycker return igen i adressfältet indikerar just att det är en delad resurs som lastdelas.
En till förklaring som med den din information jag har är minst trolig och jag inte tänkte på finns i den här kompletteringen: En till komplettering avseende "Blogger.com: Optimera laddningstiden (unikt tips) för din blogg"

Detta problem kan man minska förekomsten av radikalt genom att minimera sådant i din template som skapar anslutningar just till denna typ av resurser.

Vad ställer frågor till dessa delade resurser?
Så vad handlar det här om? Jo det är sådant taggningssidor, interna search-sidor o.s.v. Egentligen allt som utnyttjar Blogger.com specifika variabler och data som är dynamiska.

Ett intressant exempel är äldre och nyare inlägg som utnyttjar search?updated-max". Desto färre sådana ju mer sällan får besökare problemet. Det behöver heller inte alltid innebära att du skär bort funktionalitet. Tar vi t.ex. search?updated-max blir problemet obefintligt om du kodar om den så att den länkar explicit istället på samma sätt som de flesta templates gör från bloggpostningarna när de är på egen sida. Det behöver heller inte innebära att du hårdkodar detta utan av det här problemet varierar faktiskt mellan olika typer av dataförfrågningar och där är search? slöare än alternativet. Orsaken kan man tänka är att search? är samma resurs som har hand om bloggsökningar vilket totalt troligen är mycket mer krävande.

Sedan är det dåligt att det här problemet överhuvudtaget finns. Som kontrast har jag aldrig träffat på det för Wordpress.com. Faktiskt tror jag heller inte att det är svårt att lösa. En vän till mig hade ett liknande problem på en av de större amerikanska internetbankerna och en lösning på det jag pekade på fixade det där mycket enkelt. Ingen särskilt dyr lösning heller även om det krävde en del ny hårdvara och ett till lager.

0 kommentarer

Kommentera