Arkiv för kategori ‘HTML & CSS’

Kolla upp sajtens laddningstid

onsdag, 12 maj, 2010

Det ryktas om att Google börjar straffa sajter som tar lång tid att ladda. Detta tror jag att Google redan gör, men inte genom att mäta laddningstiden. Om en sajt tar lång tid att ladda ökar risken att användarna inte orkar vänta, och klickar sig tillbaka till sökresultatet. Detta tolkar Google i sin tur som en avvisning (bounce), och ett tecken på att din sajt inte var relevant för den aktuella sökningen.

Websiteoptimization.com har en bra tjänst som mäter laddningstiden på din sajt vid olika uppkopplingshastigheter. Här får du också en utförlig rapport om de faktorer som påverkar sidans laddningstid, samt tips på hur du åtgärdar detta och inom vilka gränser du ska hålla dig.

Detta område av sökmotoroptimeringen är nog det jag tycker är svårast. Det handlar om att banta ner olika delar av innehållet på sidan. Många gånger är det saker man inte vill ta bort eftersom det försämrar för besökaren på andra områden. Det kan t.ex. vara färre antal bilder som dessutom är av sämre kvalitet (mer komprimerade). Tack och lov använder jag inte mycket Javascript på mina sajter, bortsett från annonser och statistik.

Anpassning till Internet Explorer

tisdag, 27 april, 2010

Nu har jag tagit mig i kragen och äntligen fixat till Bilsemester.net och Lübeck.nu så att dessa ser ut som de ska i Internet Explorer och Firefox.  detta gäller i varje fall version 7 av Internet Explorer, de övriga orkar jag inte kolla upp just nu. i Firefox var problemet störst, men enklars att åtgärda. Där handlade det om en höjd på menyn som inte var tillräckligt tydligt definerad. det gjorde att innehåller hoppade ner och lade sig under en kolumn med en Adsense-enhet. Anpassningen till IE (7) var lite pilligare. Där var jag tvungen att göra en en separat CSS-fil som köra om användaren kommer via IE. Detta sköts via ett lite ASP-kod som känner av vilken webbläsare som används. Åtgärderna för att få sajterna att fungera i IE handlade om att på många ställen helt ange nya mått på olika DIV:ar.

Nu när detta arbete  äntligen är gjort hoppas jag på ökade intäkter från sajterna. Besökarna som använder IE kunde nämligen inte se högerkolumnen med annonser direkt, eftersom den tidigare hoppade ner och lade sig längst ner på sidan. Firefox-användarna däremot såg tidigare bara Annonser i en smal kolumn överst på sajten. Detta kan ju faktiskt ha gjort att de klickade på annonser oftare. Detta kan påverka intäkterna lite eftersom 22% av besökarna använde Firefox. Andelen för Internet Explorer är 68%.

Styla dina HTML-formulär

måndag, 1 mars, 2010

Hittade nyss några bra blogginlägg som visar hur man gör s.k. ”inline form labels” eller på ren svenska, rubriker i formulärfälten.

www.zurb.com/playground/inline-form-labels
www.alistapart.com/articles/makingcompactformsmoreaccessible

Korrekta rubriktaggar

tisdag, 12 januari, 2010

Jag har säkert gått igenom detta tidigare, men det tål att upprepas. Ett vanligt och onödigt riskabelt sätt att hantera rubrik-taggarna är att fylla dessa med ytterligare HTML-taggar. Det handlar främst om att länka texten inom rubriktaggen, eller att placera en IMG-tagg innanför <h1></h1>. Enligt min vetskap är det enda som ska finnas inom rubrik-taggarna (gäller samtliga; h1, h2, h3 osv.) är läsbar text. ASP- eller PHP-kod är såklert undantagen om denna endast är till för att generera läsbar text.

Länkar i rubriker

Jag har stött på fall där personer försökt öka värdet på en länktext genom att placera hela länken inom en rubriktagg. Som bekant värderas ju sökord i rubriker mer än när de enbart förekommer i brödtexten. Den enkla, och smått ogenomtänkta slutsatsen som dragits är att rubriktaggen på något magiskt sätt skulle öka värdet på sökorden. Jag är medveten om att Wordpress länkar rubriker hej vilt, så är det även på denna blogg. Jag är ganska säker på att det inte uppskattas av Google om det görs i syfte att öka sökordens värdering. Om det sker någon bestraffning kan jag inte säga säkert, troligtvis inte, då miljontals Wordpressbloggar skulle göra sig förtjänta av smisk. Mer troligt är nog att Google inte gör någon skillnad på dessa länkar överhuvudtaget. Det som däremot händer är att text/kod-ration på din sajt försämras. Onödigt mycket kod är inte bra! Om du bygger dina sajter från grunden, eller om det inte är för mycket jobb med att ändra befintlig design, vill jag bestämt avråda från ”onaturliga” ingrepp i rubriktaggarna.

Bilder i rubriker

Det förekommer även att img-taggar läggs inom rubriktaggarna (h1 osv.). Detta beror nog till största del på bristande HTML/CSS-kunskaper hos hemsidesnickaren. Vill man exempelvis ha en bakgrundsbild på rubriken ska man använda CSS till detta. H1 {background-image: url(bild.jpg) no-repeat;}

Det finns dock fall då orsaken inte är bristande kunskaper, utan ett försök att få vissa bilder att ranka bättre på Google’s bildsök. Inte att rekommendera! Kör på som vanligt med relevanta ALT- och TITLE-attribut istället.

Fler diskussioner om länkar i rubriktaggar

webmasterworld.com/search_engine_promotion/3155486.htm

Anpassning till olika webbläsare

fredag, 18 december, 2009

Nu har jag spenderat någon timma på att anpassa designerna till resesajterna till Firefox och Internet Explorer. Jag uppmärksammades på detta problem av en vänlig läsare och attackerade problemet direkt. När det däller dessa designer har jag slarvat en aning och struntat i att kontrollera hur de ser ut i andra webbläsare än Opera.

Ett problem återstår dock, jag får inte bakgrundsfärgerna att bli rätt i Firefox. Body-bakgrunden ska vara grå, men innehållsdelens bakgrund ska vara vit. Trots att jag gett div:en ”content” background: #FFFFFF; så funkar det inte. Body-bakgrunden används på hela sidan.

De andra felen i Firefox som bestod av felpositionerade div:ar löstes lätt i CSS:en, och påverkade inte heller designens utseende i Opera. När det kommer till fel i Internet Explorer tvingas man (ta mig fan) alltid skapa en <!–[if IE 7]> där man får ge div:arna helt ny bredd, marginal, padding m.m. Fel som uppstår i Firefox och Opera beror ofta på att man slarvat med att ange olika mått. Rättar man till, så funkar det sedan ofta i båda webbläsarna.

Popup-fönster på sajten

måndag, 7 december, 2009

Det var länge sedan jag använde mig av popup-fönster på mina webbplatser. Anledningarna till att jag övergett dem är flera. Det är dels ur SEO-synpunkt, men även av användarvänlighetsskäl.

Pop-up och SEO

Jag börjar med att förklara på vilket sätt sökmotoroptimeringen blir lidande av popup-fönster. Detta gäller under förutsättning att det är viktigt innehåll i popup:en som måste indexeras av Google. Jag tar ett exempel från WN där det handlade om en receptsajt som visar alla recept i ett popup-fönster. I det faller kommer en väldigt stor del av sajtens innehåll att ligga i olika popup:er.

Popup-fönstren använder sig oftast av JavaScript för att öppna det aktuella innehållet i ett nytt fönster. Google kan inte följa JavaScript (osäker på hur  det funkar nu för tiden, men det är helt klart bättre med rena HTML-länkar) på samma sätt som om fönstren skulle länkas med <a href=”"> som vanligt. Måste du använda JavaScript så bör länken se ut så här:

<a href=”recept.asp?id=123″ onclick=”window.open(this.href,’recept_window’);re turn false;”>Spaghetti och köttfärssås</a>

Då följer Google href-länken till innehållet och kan indexera det.

Problemet är dock inte löst i och med detta. Google har innehållet men kan få  problem när de ska länka direkt till recepten från sökresultatet. Ofta dyker samma problem upp som för i stort sett alla frame-baserade webbplatser. Sajten i sin helhet visas inte, utan besökaren ser bara innehållet på  recept.asp?id=123. Menyer, rubrik och kolumner försvinner och man tvingas ofta göra en länk under varje recept, något i stil med ”Ser du inte hela sajten? Klicka här!”.

Pop-up och användarvänlighet

Ur ett användarvänlighetsperspektiv kan popup-fönster vara både en bra och dålig lösning. Saker som jag tycker popup-fönster kan lämpa sig bra för är små korta notiser eller bekräftelser. Detta är innehåll som sökmotorer inte nödvändigtvis måste indexera. Meddelandena kan handla om att uppmuntra besökarna att bli medlem, eller bekräfta att ett meddelande har skickats.

Åter till receptexemplet. Om en så stor och viktig del av innehållet på sajten ligger i en pop-up finns risken att många besökare inte kommer åt innehållet. Många webbläsare nu för tiden har s.k. ”pop-up blockers” som hindrar dessa att automatiskt poppa upp på skärmen. Istället visas (t.ex. i Opera) ett litet meddelande i nederkant att ett pop-up har blockerats, och att man måste klicka på det meddelandet för att visa popup-fönstret. Många besökare har inte stenkoll på tekniken och upplever det som att sajten inte fungerar korrekt. Risken är då stor att du förlorar dessa besökare som inte hittar det de söker.

Ytterligare ett problem, som är både en SEO- och användarvänlighetsfråga handlar om djuplänkar till din sajt. Om ditt viktiga innehåll, recepten i detta fall, ligger i en pop-up så blir det svårare för andra att länka direkt till innehållet (s.k. djuplänkning). Användare som samtidigt driver bloggar kan uppleva det svårt att tipsa andra om intressanta recept. Dessutom förlorar du länkkraft i och med de uteblivna länkarna till din sajt.

Alternativ till JavaScript-popup

Lightbox är ett alternativ till de klassiska popup:erna i JavaScript. Det bygger istället på HTML/CSS och skapar ett lager ovanför sajten där nytt innehåll visas. Jag har dock inte satt mig in hur detta påverkar sökmotoroptimeringen, men spontant känns det som en mycket bättre lösning.

huddletogether.com/projects/lightbox

Google SERP och HTML-ankare, forts.

fredag, 23 oktober, 2009

Nu har jag fått mitt test av HTML-ankare indexerat och här ser ni hur det ser ut. En riktigt bra, och framförallt användarvänlig funktion tycker jag.

Sidan med hela innehållet är fortfarande huvudrubrik, men en extra länk har lagts till ”Hoppa till kapitel”. Därefter följer den vanliga korta sammanfattningen som visar i vilken kontext sökordet finns.

Namngivna HTML-ankare och Google

måndag, 19 oktober, 2009

Den 25 september meddelade Google att det nu är möjligt för sökarna att komma direkt till den del av målsidan som handlar om det de sökte efter. Om du sätter namngivna ankare (<a name=”introduktion”></a>) i början av de olika kapitlen/sektionerna på sidorna, så kan Google välja att länka besökarna direkt till det aktuella stycket.

För att öka chansen att Google väljer att djuplänka till dessa ankarnamn bör du lägga upp en innehållsförteckning eller liknande som länkar till dem. Det verkar alltså fungera på samma sätt som att få alla sajtens sidor indexerade genom att länka till dem. Sidan bör också vara välstrukturerad och tydligt indelad i kapitel/sektioner.

Min fråga är dock hur Google värderar dessa aningen annorlunda URL:er.
http://www.doman.se/sida.html#kapitel

http://www.doman.se/sida.html

Dessa två URL:er leder ju till samma sida, med skillnaden att den översta säger åt webbläsaren att hoppa ner till <a name=”kapitel”>. Kommer dessa indexeras, värderas och rankas som om de vore två separata sidor?

Jag är lite nyfiken på att testa hur detta fungerar. Jag ser inga nackdelar, det underlättar ju för besökarna att smidigt kunna klicka sig ner till det stycke/kapitel de vill läsa. Om sedan Google väljer att länka direkt dit så är det bara positivt. Det kan göra att besökarna inte återvänder till sökresultatet för att de inte hittar till informationen de vill åt.

http://googleblog…jump-to-information-you-want-right-from.html
http://googleweb…using-named-anchors-to-identify.html

Klickbar logga med CSS

måndag, 5 oktober, 2009

Här tänkte jag förklara hur man gör hela området för logon/rubriken klickbar. Det går ut på att placera en A-tagg inuti den DIV som innehåller bakgrundsbilden. A-taggen stylas sedan så att den fyller upp hela denna DIV. Vill du ändra storleken på det klickbara området så ändrar du bara på procentsatserna för höjd och bredd. För att ändra positionen kan du lägga till en margin-top och/eller en margin-left med önskat antal pixlar.

HTML
<div class=”title”>
<a href=”index.asp”></a>
</div>

CSS
.title {
width: 800px;
height: 200px;
background: url(rubrikbild.jpg) no-repeat;
}
.title a {
display: block;
height: 100%;
width: 100%;
}

Skriv till Access-databas med ASP

lördag, 5 september, 2009

Tänkte nu göra en liten guide till hur man enkelt skriver information från ett formulär till en Access-databas i ASP. I detta exempel är det en kommentarfunktion från en av mina sajter som får agera exempel. Först börjar vi med att skapa formuläret i HTML, ni får ursäkta den omoderna tabellösningen utan CSS jag använder här. För att göra det snyggare föreslår jag att du sätter en class på alla input och bilder för att styla dem i en extern CSS-fil.

<table width=”550″ align=”left” border=”0″>
<form method=”post” action=”
?do=spara”>
<tr>
<td colspan=”3″ width=”550″><b>Rubrik:</b> (max 45 tecken)<br><input maxlength=”45″ name=”rubrik”></td>
</tr>
<tr>
<td colspan=”3″ width=”550″><b>Text:</b><br><textarea name=”comment”></textarea></td>
</tr>
<tr>
<td width=”245″ valign=”top”><b>Namn:</b><br><input value=”" name=”namn”></td>
<td width=”245″ valign=”top”><b>Hemsida:</b><br><input value=”http://www.” name=”hemsida” ></td>
</tr>
<tr>
<td width=”275″ valign=”top”><b>E-post:</b><br><input value=”" name=”epost”>
</td>
<td width=”275″ valign=”top”><b>Spamskydd:</b><br><img src=”grafik/kod2.jpg”><input value=”" name=”spamprot”></td>
</tr>
<tr>
<td colspan=”3″ width=”550″>
<input type=”submit” value=”Posta kommentar”>
</td>
</tr>
</form>
</table>

När formulärt är färdigt ska vi skriva ASP-koden som hämtar informationen från formuläret, lägger dem i variabler och sedan matar in dem på rätt plats i databasen. Ursäkta att koden är lite slarvigt skriven med en blandning av engelska och svenska.

<%
If Request.Querystring(”do”) = ”spara” Then
Set Conn = Server.CreateObject(”ADODB.Connection”)
Conn.Open ”Provider=Microsoft.Jet.OLEDB.4.0;Data Source=” &Server.MapPath(”databas\db.mdb”)spamprotection = Request.Form(”spamprot”)

If spamprotection = ”34$LkT” Then
SQL = ”Insert Into comments (title,comment,datum,namn,hemsida,epost) Values(‘” & Request.Form(”rubrik”) & ”‘,’” & Request.Form(”comment”) & ”‘,’” & date & ”‘,’” & Request.Form(”namn”) & ”‘,’” & Request.Form(”hemsida”) & ”‘,’” & Request.Form(”epost”) & ”‘)”
Conn.Execute(SQL)
RecSet.Close
Conn.Close
Set RecSet = Nothing
Set Conn = Nothing
Response.Redirect ”kommentarer.asp”
Else
Response.Redirect ”kommentarer.asp”
End If
End If
%>