---

Det bør være kendt for de fleste, at Google er gået ud med en direkte
opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider
kan påvirke placering negativt (jeg synes så også, man skal skele til,
at det irriterer brugerne helt enormt med langsommme sider, men whatever
synspuinkt man nu lægger).

Jeg faldt over deres "best practise" (en af dem), og her er bl.s. nogle
ting taget op, som ikke før har haft så stor bevågenhed - bl.a.
optimering af CSS.

http://code.google.com/intl/da/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

Bl.a. handler det om at tage hensyn til, hvordan CSS læses og udføres af
browseren.

Eksempel:

ul#menu{ egenskaber ]

er måske godt for læsbarheden, men skidt for hastigheden, da en ID
allerede er unik. Ovenstående regel vil kræve mere beregning fra
maskinen end:

#menu{ egenskaber ]


Nuvel, jeg siger ikke, man *skal* følge disse retningslinjer (og der er
iøvrigt en del flere end denne) i alle tilfælde, men det at Google nu
offentligt er gået frem med disse for mange næsten glemte regler, det
tyder på, det er værd at bide mærke i, og i det mindste skele til, når
man koder..

Der er flere gode råd på samme side, bl.a. hvordan man skal placere sin
inline style i forhold til eksterne scripts/stylesheets og eksterne
stylesheets i forhold til javasacripts, samt nogle egentlige værktøjer
og udvidelser til din browser til optimering af ens side. En del af
rådene er også ret nemme at implementere, så der er IMO ingen
undskyldning for ikke at gøre det.

Brugere af CMSer som WordPress kan med fordel lede efter plug ins, som
automatisk kan optimere koden, f.eks. GZIPing og minifying og samling af
flere scripts i ét enkelt.



MVH
Rune Jensen

---

Den 22-04-2010 10:14, Rune Jensen skrev:

> Eksempel:
>
> ul#menu{ egenskaber ]
>
> er måske godt for læsbarheden, men skidt for hastigheden, da en ID
> allerede er unik. Ovenstående regel vil kræve mere beregning fra
> maskinen end:
>
> #menu{ egenskaber ]

Visse plug ins til CMSer kan minifye CSS on the fly. Dvs. at remarks i
CSSen fjernes, og white-space så vidt muligt også, inden det serveres
til browseren.

Bruger man et sådant plugin, kan man måske med fordel inddele sin CSS i
sektioner, sådan at overblikket bevares i filen på serveren, f.eks.

/* ----------------- MENU ----------------- */

#menu{ egenskaber }


I stedet for at sætte selve den underforståede tag på hver gang:

ul#menu{ egenskaber ]


MVH
Rune Jensen

---

Den 22-04-2010 10:14, Rune Jensen skrev:

> Brugere af CMSer som WordPress kan med fordel lede efter plug ins, som
> automatisk kan optimere koden, f.eks. GZIPing og minifying og samling af
> flere scripts i ét enkelt.

Mht. GZIPing:

http://code.google.com/intl/da/speed/page-speed/docs/payload.html#GzipCompression

Tilsyneladende kan man selv systematisere både sin HTML og CSS, så
kompressionsalgoritmen udnyttes bedst muligt.

Som jeg fortår det:

I CSS at sætte egenskaberne i alfabetisk orden (hvilket nogle allerede
anbefaler)

I CSS at sætte attributter i alfabetisk orden

I både CSS og HTML at bruge kun én af enten " eller ' igennem hele koden.


....er dette opfattet korrekt?


MVH
Rune Jensen

---

Rune Jensen skrev:
> Det bør være kendt for de fleste, at Google er gået ud med en direkte
> opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider
> kan påvirke placering negativt (jeg synes så også, man skal skele til,
> at det irriterer brugerne helt enormt med langsommme sider, men whatever
> synspuinkt man nu lægger).

Ikke for noget, men jeg erindrer bemærkninger
her i gruppen (eller var det ris+ros) om at
følgende var ligegyldigt:
http://webdesign101.dk/artikler/csscompress.php


--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Den 22-04-2010 11:40, Jørgen Farum Jensen skrev:
> Rune Jensen skrev:
>> Det bør være kendt for de fleste, at Google er gået ud med en direkte
>> opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider
>> kan påvirke placering negativt (jeg synes så også, man skal skele til,
>> at det irriterer brugerne helt enormt med langsommme sider, men
>> whatever synspuinkt man nu lægger).
>
> Ikke for noget, men jeg erindrer bemærkninger
> her i gruppen (eller var det ris+ros) om at
> følgende var ligegyldigt:
> http://webdesign101.dk/artikler/csscompress.php
>

Det er ikke brugbart (for mig) med en statisk kompression. Det vil være
alt for tidskrævende at lave det manuelt med f.eks. to versioner, som
man så skal opdatere hver gang, man har lavet en lille rettelse.

Jeg synes det ødelægger overblikke at have det hele på en linje, det er
det, jeg mener. Så skal jeg scrolle helt ud til højre, hvis jeg skal
have en egenskab derude (her kan man selvfølgelig bare have to skærme -
det har jeg ikke mere).

Hvad jeg foreslår er derfor i første omgang mest til dem, som bruger
CMSer, at man finder en plug in, som automatisk kan tage originaludgaven
af en CSS-fil og minify den inden den sendes til browseren. Andre kan
selvfølgelig gøre det samme (hvis man f.eks. alene koder i hånden), men
så skal man til at kode noget ekstra for at lave den minify-funktion,
hvilket nok kræver en del (serverside) kodeerfaring.

Jeg er lidt opmærksom på her, at des mere man mister af overblikket, des
større er chancen for fejl, så det er en vurderingssag.

Til gengæld, så tror jeg det var hos dig, jeg læste første gang om
alfabetisering af CSS, og den (systematisering) tror jeg helt klart på,
da den ikke ødelægger overblikket, tværtimod ...hvorvidt det iøvrigt
ødelægger eller ikke ødelægger overblik med whitespace removal, det er
nok meget individuelt, så sandsynligvis er ikke alle heller alligevel
enige med mig i det.

Men at det kan være godt for hastigheden at fjerne whitespace, deri er
vi helt enige, og det er også målet for mig med større hastighed. Google
idéer omkring hastighed er, at en side bør kunne ses med "a snap of a
finger". Mit mål er fuldstændigt det samme.


MVH
Rune Jensen

---

Rune Jensen kom med denne ide:
> Den 22-04-2010 11:40, Jørgen Farum Jensen skrev:
>> Rune Jensen skrev:
>>> Det bør være kendt for de fleste, at Google er gået ud med en direkte
>>> opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider
>>> kan påvirke placering negativt (jeg synes så også, man skal skele til,
>>> at det irriterer brugerne helt enormt med langsommme sider, men
>>> whatever synspuinkt man nu lægger).
>>
>> Ikke for noget, men jeg erindrer bemærkninger
>> her i gruppen (eller var det ris+ros) om at
>> følgende var ligegyldigt:
>> http://webdesign101.dk/artikler/csscompress.php
>>
>
> Det er ikke brugbart (for mig) med en statisk kompression. Det vil være alt
> for tidskrævende at lave det manuelt med f.eks. to versioner, som man så skal
> opdatere hver gang, man har lavet en lille rettelse.
>
> Jeg synes det ødelægger overblikke at have det hele på en linje, det er det,
> jeg mener. Så skal jeg scrolle helt ud til højre, hvis jeg skal have en
> egenskab derude (her kan man selvfølgelig bare have to skærme - det har jeg
> ikke mere).
>
> Hvad jeg foreslår er derfor i første omgang mest til dem, som bruger CMSer,
> at man finder en plug in, som automatisk kan tage originaludgaven af en
> CSS-fil og minify den inden den sendes til browseren. Andre kan selvfølgelig
> gøre det samme (hvis man f.eks. alene koder i hånden), men så skal man til at
> kode noget ekstra for at lave den minify-funktion, hvilket nok kræver en del
> (serverside) kodeerfaring.
>
> Jeg er lidt opmærksom på her, at des mere man mister af overblikket, des
> større er chancen for fejl, så det er en vurderingssag.
>
> Til gengæld, så tror jeg det var hos dig, jeg læste første gang om
> alfabetisering af CSS, og den (systematisering) tror jeg helt klart på, da
> den ikke ødelægger overblikket, tværtimod ...hvorvidt det iøvrigt ødelægger
> eller ikke ødelægger overblik med whitespace removal, det er nok meget
> individuelt, så sandsynligvis er ikke alle heller alligevel enige med mig i
> det.
>
> Men at det kan være godt for hastigheden at fjerne whitespace, deri er vi
> helt enige, og det er også målet for mig med større hastighed. Google idéer
> omkring hastighed er, at en side bør kunne ses med "a snap of a finger". Mit
> mål er fuldstændigt det samme.
>
>
> MVH
> Rune Jensen

Et PHP eller ASP script, der tager din CSS og fjerner ny linie efter
semikolon, og hvad du ellers har af overflødigt i din CSS, inden det
leveres til browseren, kan vel ikke være helt umuligt at skrive..
<link type="text/css" href="css_comp.php?fil=mincss.css">
Jeg har f.eks. altid mellemrum både før og efter : i min CSS, og bruger
indrykning:
#mindiv {
height : 234px;
}
Der er mange overflødige tegn her - og det bliver til meget, som Jørgen
også siger.
Men det er vigtigt, at læsbarheden bevares, og at det ser ud "som det
plejer". Ellers kommer man til at bruge meget tid på at lede efter
tingene i stedet.
Så en eller anden balance, er vel at foretrække.
Der er vel også et problem med ovenstående, at bruger man værktøjer
online, vil koden måske være komprimeret (læs:ulæselig), og det vil
vanskeliggøre fejlfinding.

Og så har jeg det lidt som det måske er lidt ligegyldigt, hvis der også
hentes et framework ind, der måske ikke bruges ret meget af.
Det kan være ligegyldigt med at spare et par nano-, mikro- eller
millisekunder, hvis man alligevel bruger tiendedele sekunder eller mere
på at hente overflødig scripting.

Jeg bruger ikke frameworks - men jeg optimerer heller ikke min CSS.
Men det er måske noget man skulle/burde overveje.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 22-04-2010 12:45, Birger Sørensen skrev:

> Et PHP eller ASP script, der tager din CSS og fjerner ny linie efter
> semikolon, og hvad du ellers har af overflødigt i din CSS, inden det
> leveres til browseren, kan vel ikke være helt umuligt at skrive..

Nej, men jeg mener at kunne huske, at jeg tror, det handler om cashing.

En statisk fil sender - så vidt jeg forstår - altid sidste ændringsdato
med, det er fordelen. Gør en dynamisk genereret fil det - og hvis ikke,
hvordan får man gjort opmærksom på, at filen er ændret, hvis den
allerede er cashed?

Mine CSS og JS-filer på den server, jeg kører på er ikke GZIPpet, det
har jeg lige testet, så der vil være rigtigt rigtigt meget at spare ved
en sådan (helst dynamisk) minify-løsning.


MVH
Rune Jensen

---

Birger Sørensen skrev:

> Et PHP eller ASP script, der tager din CSS og
> fjerner ny linie efter semikolon, og hvad du ellers
> har af overflødigt i din CSS, inden det leveres til
> browseren, kan vel ikke være helt umuligt at
> skrive.

Nej, ikke umuligt, men pisseirriterende for andre
at fejlsøge i.

> Der er mange overflødige tegn her - og det bliver
> til meget, som Jørgen også siger.

Er der nogen der har regnet på hvor meget man
sparer på en normal 5-megabit-linje?

Jeg kan ikke tro at nogen kan mærke forskel.

> Men det er vigtigt, at læsbarheden bevares, og
> at det ser ud "som det plejer".

Jeg bruger hellere ekstra tid på at få det til at stå
optimalt i forhold til vedligeholdelse - det er jo ikke
sikkert at det mig selv der skal gøre det fremover.

> Så en eller anden balance, er vel at foretrække.

Min balance er altså hældt mod vedligeholdelse
frem for hastighed.

I dag vælger jeg også png-billeder frem for hårdt
pakkede jpg-billeder, netop fordi hastigheden kan
bære det.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 22-04-2010 23:53, Allan Vebel skrev:

> I dag vælger jeg også png-billeder frem for hårdt
> pakkede jpg-billeder, netop fordi hastigheden kan
> bære det.

Det er i hvert fald som udgangspunkt forkert format til foto. Det er kun
JPEG, som dur til det. Jeg har forsøgt mig med "næsten-foto"-grafik i
PNGer på webdewsigngruppen.dk, og de fylder som et ondt år, selvom alt
unødigt er stripppet væk. Havde faktisk planer om en del flere, for jeg
kan såmænd ret godt lide PNG-formatet, men når hver går op over de 70kb,
så synes jeg smertegrænsen er nået for grafikken.


MVH
Rune Jensen

---

Den 24-04-2010 03:53, Rune Jensen skrev:

> Det er i hvert fald som udgangspunkt forkert format til foto. Det er kun
> JPEG, som dur til det. Jeg har forsøgt mig med "næsten-foto"-grafik i
> PNGer på webdewsigngruppen.dk, og de fylder som et ondt år, selvom alt
> unødigt er stripppet væk. Havde faktisk planer om en del flere, for jeg
> kan såmænd ret godt lide PNG-formatet, men når hver går op over de 70kb,
> så synes jeg smertegrænsen er nået for grafikken.

Med foto holder jeg også fast i .jpg. .png bruger jeg mere der hvor jeg
i gamle dage brugte .gif.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 24-04-2010 08:07, Philip Nunnegaard skrev:
> Den 24-04-2010 03:53, Rune Jensen skrev:
>
>> Det er i hvert fald som udgangspunkt forkert format til foto. Det er kun
>> JPEG, som dur til det. Jeg har forsøgt mig med "næsten-foto"-grafik i
>> PNGer på webdewsigngruppen.dk, og de fylder som et ondt år, selvom alt
>> unødigt er stripppet væk. Havde faktisk planer om en del flere, for jeg
>> kan såmænd ret godt lide PNG-formatet, men når hver går op over de 70kb,
>> så synes jeg smertegrænsen er nået for grafikken.
>
> Med foto holder jeg også fast i .jpg. .png bruger jeg mere der hvor jeg
> i gamle dage brugte .gif.

Man kan SVJV få størrelsen af en PNG kraftigt ned ved bl.a. at sikre
sig, at der ikke er en alpha-kanal. Det er den, som man kan bruge til
graderende gennemsigtigthed, og en af årsaerne til, jeg ikke er så god
til IE6.

http://en.wikipedia.org/wiki/Alpha_compositing

Men det er stadig ikke helt det bedste til foto. Som udgangspunkt.

GIF behøver vi forhåbentlig ikke tænke på mere. PNG er langt bedre i
faktisk alle tilfælde. Dog undtaget, hvis man er nødsaget til at tage
særlige hensyn, som f.eks. IE6. Raster-gennemsigtighed er ufatteligt grimt.


MVH
Rune Jensen

---

Philip Nunnegaard wrote:

> Med foto holder jeg også fast i .jpg.

Jpg er specielt udviklet til fotos, hvor man 'fjerner' det det menneskelige
øje ikke kan se - analogt med f.eks. MP3, hvor man fjerner informationer.

Så der er ikke alene tale om kompression, men fjernelse af informationer, så
man kan ikke genskabe originalen.

> .png bruger jeg mere der hvor jeg
> i gamle dage brugte .gif.

png og gif er lossless formater baseret på LZH (tror jeg nok det hedder)
kompression, og er specielt velegnet til 'billeder' hvor flader er
ens(gentagne bitmønstre).

Så jpg til foto's med stor varians, og png(gif) til grafik.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Philip Nunnegaard wrote:
>
>> Med foto holder jeg også fast i .jpg.
>
> Jpg er specielt udviklet til fotos, hvor man 'fjerner' det det menneskelige
> øje ikke kan se - analogt med f.eks. MP3, hvor man fjerner informationer.
>
> Så der er ikke alene tale om kompression, men fjernelse af informationer, så
> man kan ikke genskabe originalen.
>
>> .png bruger jeg mere der hvor jeg
>> i gamle dage brugte .gif.
>
> png og gif er lossless formater baseret på LZH (tror jeg nok det hedder)

LZH brugtes/bruges af 'lharc/lha" til at komprimere filer
http://en.wikipedia.org/wiki/LHA_(file_format)

LZW (patenteret) dårlig kompression velegnet til hardware (analog modems i 80'erne)
blev desværre brugt valg af Compuserve til GIF (1987) mange år før unisys
opdagede/håndhævede patent på software.
Zip compression i GIF kunne reducere med 25-30% mere, men så var GIF-imaget
ikke kompatibelt.
Selv LHA (LZH) havde været bedre end LZW, så Compuserve
fik lavet et uheldigt valg med LZW til GIF, men hvem kunne vide at Unisys
ville håndhæve et hardware patent over en elendig kompressionsalgoritme som LZW ....
http://en.wikipedia.org/wiki/LZW


PNG bruger "deflate" som den anvendt i zlib/zip i dag.
http://en.wikipedia.org/wiki/Portable_Network_Graphics
Deflate bruger en kombination af LZ77 + Huffmann .

GIF havde mange mangler, max 256 farver mfl., men MS var meget længe
om ordentlig support af PNG , på trods af PNG er fra 1995 !


> kompression, og er specielt velegnet til 'billeder' hvor flader er
> ens(gentagne bitmønstre).
>
> Så jpg til foto's med stor varians, og png(gif) til grafik.

korrekt.

PNG er også fint til scanning af dokumenter med få farver
(f.eks. 2 farver sort/hvid).

kommer man op i 24/32 bit farver vil PNG fylder meget, men er
det grafik/tegninger der scannes, så kan man med fordel reducere farvetabel,
og dermed reducere PNG filen.

---

Den 22-04-2010 12:45, Birger Sørensen skrev:
v
> <link type="text/css" href="css_comp.php?fil=mincss.css">
> Jeg har f.eks. altid mellemrum både før og efter : i min CSS, og bruger
> indrykning:
> #mindiv {
> height : 234px;
> }
> Der er mange overflødige tegn her - og det bliver til meget, som Jørgen
> også siger.
> Men det er vigtigt, at læsbarheden bevares, og at det ser ud "som det
> plejer". Ellers kommer man til at bruge meget tid på at lede efter
> tingene i stedet.

Man kunne også GZIPpe. Minifyling fjerner whitespace og remarks, men
GZIP fjerner ikke noget, den komprimerer loss-less. Som Stig skriver, er
det dog serveren, som bestemmer, om man kan GZIPpe.

Så vidt jeg forstår på Google, så arbejder GZIP kompressionen bedst med
sytematik, så er man vel allerede godt på vej, når man i forvejen
arbejder systematisk.

Jeg kender ikke algoritmen bag GZIP, men hvis det er en standard
kompression, sådan som jeg har lært komprimering altså, så leder
algoritmen efter elementer/strenge, som er indbyrdes ens, og så sætter
den en værdi for antal gentagelser, samt hvor i koden det skal lægges.

I så fald kan der være idé i altid at bruge samme form i egenskabernes
værdier også, enten kort form eller den fulde form, ligesom en
systematisering af egenskaberne måske er en god idé.

Jeg har f.eks. mange steder

margin:0;
padding:0

og hvis det skrives på nøjagtigt samme måde hver gang, kan det tages som
en enkelt streng, som bare gentages. Om der er mellemrum eller anden
white-space vil nok ikke gøre den helt store forskel i mindre
stylesheets, sålænge fremgangsmåden er nøjagtigt den samme.

GZIP er godt for loadtid af siden*), men minify kan nok gøre noget ved
selve udførelsen af CSSen, for når der ikke er noget
fyldkode/remarks/white-space i den færdige CSS, går det sandsynligvis
også hurtigere at udføre.

Yderligere, i PHP som "de fleste" nok bruger, har mange, bl.a. Google,
lavet sådanne optimerings-scripts, som kombinerer de forskellige
optimeringsformer, og som frit kan downloades.


MVH
Rune Jensen

*) hvilket man kan teste hvis man har TamperData extention til firefox,
og sætter accept-encoding tom. Der er *meget* mærkbar forskel fra GZIP
til none-GZIP.

---

Rune Jensen skrev:

> Jeg kender ikke algoritmen bag GZIP, men hvis det er en standard
> kompression, sådan som jeg har lært komprimering altså, så leder
> algoritmen efter elementer/strenge, som er indbyrdes ens, og så sætter
> den en værdi for antal gentagelser, samt hvor i koden det skal lægges.

Det er forkert.

> I så fald kan der være idé i altid at bruge samme form i egenskabernes
> værdier også, enten kort form eller den fulde form, ligesom en
> systematisering af egenskaberne måske er en god idé.

At lave opstillingen i sin kode af hensyn til en
komprimeringsalgoritme!? Det får du ikke mig til.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 23-04-2010 08:06, Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Jeg kender ikke algoritmen bag GZIP, men hvis det er en standard
>> kompression, sådan som jeg har lært komprimering altså, så leder
>> algoritmen efter elementer/strenge, som er indbyrdes ens, og så sætter
>> den en værdi for antal gentagelser, samt hvor i koden det skal lægges.
>
> Det er forkert.

Og? Hvor er forklaringen?

Jeg elsker bare de dér indlæg, som alene indeholder ja eller nej, ingen
begrndelse overhovedet. Det er så god debatteknik.


MVH
Rune Jensen

---

Rune Jensen skrev:

> >> Jeg kender ikke algoritmen bag GZIP, men hvis det er en standard
> >> kompression, sådan som jeg har lært komprimering altså, så leder
> >> algoritmen efter elementer/strenge, som er indbyrdes ens, og så sætter
> >> den en værdi for antal gentagelser, samt hvor i koden det skal lægges.

> > Det er forkert.

> Og? Hvor er forklaringen?

Du vil have en populær forklaring på zips kompressionsalgoritme?

Wikipedia har en artikel på engelsk:
http://en.wikipedia.org/wiki/Huffman_coding

> Jeg elsker bare de dér indlæg, som alene indeholder ja eller nej, ingen
> begrndelse overhovedet. Det er så god debatteknik.

Jeg havde ikke tænkt mig at skrive en lærebog i
kompressionsalgoritmer. Det er et ganske komplekst emne og
forudsætter kendskab til bl.a. forskellige datastrukturer.

Kort fortalt går metoden ud på at der tildeles en bitværdi til
hver forskellig element i datamaterialet på en sådan måde at
værdien angiver stien til elementet i et binært træ. I dette
binære træ indføjer man så de elementer man efterhånden støder
på.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:

> Wikipedia har en artikel på engelsk:

Her er en anden, lettere tilgængelig artikel:

   http://cba.winthrop.edu/acm/PLDS210/huffman.html

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 23-04-2010 08:55, Bertel Lund Hansen skrev:
> Rune Jensen skrev:

>> Jeg elsker bare de dér indlæg, som alene indeholder ja eller nej, ingen
>> begrndelse overhovedet. Det er så god debatteknik.
>
> Jeg havde ikke tænkt mig at skrive en lærebog i
> kompressionsalgoritmer. Det er et ganske komplekst emne og
> forudsætter kendskab til bl.a. forskellige datastrukturer.

Nej, det er mere det med bare at skrive ja eller nej. Jeg takker for
linket, og jeg er ved at læse.


MVH
Rune Jensen

---

Bertel Lund Hansen wrote:

> Du vil have en populær forklaring på zips kompressionsalgoritme?
>
> Wikipedia har en artikel på engelsk:
> http://en.wikipedia.org/wiki/Huffman_coding

Huffman's RLE blev brugt i modem tiderne hmm.. mon ikke det var V.42 bis?

Når man snakker lidt mere moderne kompressionsalgoritmer, skal du nok søge
på
'Lempel','Ziv','Welsch','Huffman',
og tage i agt hvilke allgoritmer der er/var patent på. (hint GIF).

--
Med venlig hilsen
Stig Johansen

---

Den 23-04-2010 14:04, Stig Johansen skrev:
> Bertel Lund Hansen wrote:
>
>> Du vil have en populær forklaring på zips kompressionsalgoritme?
>>
>> Wikipedia har en artikel på engelsk:
>> http://en.wikipedia.org/wiki/Huffman_coding
>
> Huffman's RLE blev brugt i modem tiderne hmm.. mon ikke det var V.42 bis?
>
> Når man snakker lidt mere moderne kompressionsalgoritmer, skal du nok søge
> på
> 'Lempel','Ziv','Welsch','Huffman',
> og tage i agt hvilke allgoritmer der er/var patent på. (hint GIF).

OK, Hofman var forholdsvist nemt at forstå, men de andre kræver nok, jeg
bruger en del mere tid på det.

Jeg synes dog det er interessant, for så vidt at GZIP er det nye
"buzzword" indenfor visse grene af webdesign. Også det, at man kender
baggrunden for den teknik, man bruger.


MVH
Rune Jensen

---

Den 23-04-2010 08:06, Bertel Lund Hansen skrev:
> Rune Jensen skrev:

>> I så fald kan der være idé i altid at bruge samme form i egenskabernes
>> værdier også, enten kort form eller den fulde form, ligesom en
>> systematisering af egenskaberne måske er en god idé.
>
> At lave opstillingen i sin kode af hensyn til en
> komprimeringsalgoritme!? Det får du ikke mig til.

http://code.google.com/intl/da/speed/page-speed/docs/payload.html#GzipCompression

Google skriver bl.a.:

"For example, on Google's search results page, when HTML attributes were
alphabetized, a 1.5% reduction in the size of the gzipped output resulted. "

Jeg kan ikke tolke det som andet, end at jo mere systematik, des bedre
kompression, når man bruger GZIP. Jeg synes det er en hammerfed idé,
fordi jo mere systematik, des nemmere er det at finde rundt i koden.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg kan ikke tolke det som andet, end at jo mere systematik, des bedre
> kompression, når man bruger GZIP. Jeg synes det er en hammerfed idé,
> fordi jo mere systematik, des nemmere er det at finde rundt i koden.

Systematik der letter overblikket for dem der skal læse koden:
helt nødvendigt.

Systematik af anden årsag: ligegyldigt.

Vi skal ikke øge hastigheden blot for at øge hastigheden. Vi skal
kun øge hastigheden hvis det er en følge af at vi opstiller vores
kode på en mere effektiv og læsevenlig måde.

"Effektiv" betyder stadig ikke "maskin- og algoritmeteknisk mere
effektiv". Det betyder f.eks. at vi samler ens erklæringer under
én hat. Det er mere overskueligt.

Googles initiativ er aldeles glimrende. Højere cpu-hastighed får
folk til at sløse med ressourcerne. Klem deres pengepung, og de
lytter.

'Vi andre' der ikke sløser med ressourcerne, skal ikke til at
kvadre fornuftigt opstillet kode for at lokke en
hastighedsforøgelse på 1 sekund ud af serveren.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 23-04-2010 10:31, Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Jeg kan ikke tolke det som andet, end at jo mere systematik, des bedre
>> kompression, når man bruger GZIP. Jeg synes det er en hammerfed idé,
>> fordi jo mere systematik, des nemmere er det at finde rundt i koden.
>
> Systematik der letter overblikket for dem der skal læse koden:
> helt nødvendigt.
>
> Systematik af anden årsag: ligegyldigt.

Men hvad så med dynamiske løsninger for forbedret hastighed? Er det så
også ligegyldigt, man kan spare tid?

F.eks. en funktion, som automatisk minifyer og samler de CSS-filer der
skal bruges?

Det vil på ingen måde lette overblikket, ejheller forværre det. Men det
vil gøre loadtiden langt hurtigere for de fleste. Mao. en optimering kun
pga. bedre hastighed.

> Vi skal ikke øge hastigheden blot for at øge hastigheden. Vi skal
> kun øge hastigheden hvis det er en følge af at vi opstiller vores
> kode på en mere effektiv og læsevenlig måde.

Som ovenfor.

> "Effektiv" betyder stadig ikke "maskin- og algoritmeteknisk mere
> effektiv". Det betyder f.eks. at vi samler ens erklæringer under
> én hat. Det er mere overskueligt.

OK.

> Googles initiativ er aldeles glimrende. Højere cpu-hastighed får
> folk til at sløse med ressourcerne. Klem deres pengepung, og de
> lytter.

Kommer BING med, er det helt optimalt.

> 'Vi andre' der ikke sløser med ressourcerne, skal ikke til at
> kvadre fornuftigt opstillet kode for at lokke en
> hastighedsforøgelse på 1 sekund ud af serveren.

1 sekund er meget, så hvis du kan opnå dét, er det bare med at gøre det ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Men hvad så med dynamiske løsninger for forbedret hastighed? Er det så
> også ligegyldigt, man kan spare tid?

Hvis det betyder at brugerne får serveret pakkede filer i stedet
for klar kode, så er det noget juks.

Hvis det betyder at opsætningen af webservere bliver mere
kompleks så vi får flere klamphuggere til at drive servere der
går ned og rammes af hackerangreb, er det noget juks.

Kort sagt: Jeg gider ikke spilde min tid med andre overvejelser
end dem der forbedrer kvaliteten af koden efter de retningslinjer
jeg har forklaret.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 23-04-2010 12:12, Bertel Lund Hansen skrev:

> Kort sagt: Jeg gider ikke spilde min tid med andre overvejelser
> end dem der forbedrer kvaliteten af koden efter de retningslinjer
> jeg har forklaret.

OK, jeg interesserer mig skam også for strukturering, eftersom der også
kan opstilles best practise for dette, og jeg har haft kig på følgende:
http://www.michael-ostergaard.dk/sadan-arbejder-du-struktureret-med-css

Samt denne:
http://www.michael-ostergaard.dk/saadan-arbejder-du-struktureret-med-css-og-html-del-2

Det handler i dén grad om strukturering, og et par af rådene fandt jeg
sådan set selv brugbare, omend jeg stadig er imod, man sætter en
underforstået tag ind foran en ID (her mener jeg stadig, det er bedre at
lave sektionsoversigter i remarks og så om muligt minify dem væk).

Om dynamisk kompression/cashing, det er der også nogle, som har skrevet
om, og hvadenten man nu kan lide idéen eller ej, så er der altså for en
dels vedkommende brug for "en eller anden løsning" på højere hastighed,
og det her er så ét bud. Dette er dog til WordPress:
http://da.clausheinrich.com/hurtigere-wordpress-blog/


MVH
Rune Jensen

---

Den 22-04-2010 11:40, Jørgen Farum Jensen skrev:

> følgende var ligegyldigt:
> http://webdesign101.dk/artikler/csscompress.php
>

Det første link virker ikke længere, så det skal nok opdateres...

Kunne du være interesseret i at tilføje en tekst om muligheder for
dynamiske løsninger?

Der burde være flere derude, men jeg havde bl.a. denne i tankerne, som
dog kun virker til PHP. Jeg er *ikke* PHPer og jeg har heller ikke
testet den, så det er et skud:

http://code.google.com/p/minify/

Jeg tror, det er bl.a. overblikket, som også Bertel henviser til, og så
det at det er statisk, som gør folk måske ikke nørkler med det. Med en
dynamisk løsning vil man kunne plugge det direkte ind (så vidt jeg
forstår teksten), og det laver tingene on the fly i stedet. Det tror jeg
der er mere penge i i længden for den generelle bruger.


MVH
Rune Jensen

---

"Jørgen Farum Jensen" <jfjenzen@yahoo.dk> wrote in message
news:4bd01994$0$282$14726298@news.sunsite.dk...
> Rune Jensen skrev:
> > Det bør være kendt for de fleste, at Google er gået ud med en direkte
> > opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider
> > kan påvirke placering negativt (jeg synes så også, man skal skele til,
> > at det irriterer brugerne helt enormt med langsommme sider, men whatever
> > synspuinkt man nu lægger).
>
> Ikke for noget, men jeg erindrer bemærkninger
> her i gruppen (eller var det ris+ros) om at
> følgende var ligegyldigt:
> http://webdesign101.dk/artikler/csscompress.php
>


Nu skal jeg ikke udtale mig om hvad er sagt i gruppen, men et
kardinalpunktetr at visse ting kunne ligge forkomprimeret (a la gzip'et).

Folketinget.dk har været udsat for noget kritik, og CSS'et er voldsomt
stort.

Jeg har gemt CSS'et i 2 versioner:
http://w-o-p-r.dyndns.dk/css.axdo.css
og
http://w-o-p-r.dyndns.dk/css.asx.css

Den ene er gzip'et, og den andener ikke, og forskellen er:
-rw-r--r-- 1 root root 41095 Apr 22 12:25 css.asx.css
-rw-r--r-- 1 root root 277228 Apr 22 12:24 css.axdo.css
Dvs. en besparelse på 230+B ved at zippe skidtet.

(De UA'er der ikke understøtter Gzip få den unzippede version).

--
Med venlig hilsen/Best regards
Stig Johansen

---

Rune Jensen skrev:

> Jeg faldt over deres "best practise" (en af dem), og her er bl.s. nogle
> ting taget op, som ikke før har haft så stor bevågenhed - bl.a.
> optimering af CSS.

Hvis vi bkliver ved på den måde, ender vi i de 'gode' gamle dage
hvor man kunne se programkode uden et eneste mellemrum eller
linjeskift.

Kode skal være let læselig for dem der skal arbejde med den.

Hvis man kan optimere uden at gå på kompromis med det princip, er
det kun helt fint.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 22-04-2010 12:00, Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Jeg faldt over deres "best practise" (en af dem), og her er bl.s. nogle
>> ting taget op, som ikke før har haft så stor bevågenhed - bl.a.
>> optimering af CSS.
>
> Hvis vi bkliver ved på den måde, ender vi i de 'gode' gamle dage
> hvor man kunne se programkode uden et eneste mellemrum eller
> linjeskift.
>
> Kode skal være let læselig for dem der skal arbejde med den.
>
> Hvis man kan optimere uden at gå på kompromis med det princip, er
> det kun helt fint.

Hvilket også er hvad jeg foreslår i nummer to indlæg ;)

Om ikke andet, så er og bliver langsomme hjemmesider et voksende
problem. Ikke bare på loadtid af siden (som f.eks. kan skyldes alenlange
viewstates fra NET), men også på udførelsen, hvor mange ukritisk
indføjer indtil flere forskellige JS-frameworks for bare nu at tage
nogle eksempler på "moderne webdesign".

Derfor har jeg sukket i lang tid efter nogle best practise principper,
som man kan holde fast i, og så bruge hver gang - og også anbefale til
andre, selvfølgelig, og så man har nogle overbevisende argumenter for det.

En minify til CSS (for nu at være on-topic), når man koder i hånden vil,
som jeg skriver til Jørgen, ikke kunne betale sig for mig. Men *idéen*
om højere hastighed er helt rigtigt efter min mening. Jeg bruger mest
Google som opbakning her, fordi det er dem, som i øjeblikket råber mest
op om det, og ja, jeg er helt klart fanboy i den forbindelse ;)

Spørgsmålet om hastighed er alene hvordan og hvor meget man evt. vil gå
på kompromis med overblik eller iøvrigt ændre på sine arbejdsrutiner.
Jeg går ikke ligeså højt op i midlet, som i målet i den forbindelse. Kan
man finde andre løsninger er det også OK med mig. Så længe "midlet" bare
kan bruges (nogenlunde) konsekvent, så det er nemt at huske også.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Om ikke andet, så er og bliver langsomme hjemmesider et voksende
> problem.

Det er ikke placeringen af en linje i en CSS-fil der får et site
til at sluge tid. Det er udenomsbras som flash, javascript osv.
brugt til blær uden omtanke.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 22-04-2010 13:21, Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Om ikke andet, så er og bliver langsomme hjemmesider et voksende
>> problem.
>
> Det er ikke placeringen af en linje i en CSS-fil der får et site
> til at sluge tid. Det er udenomsbras som flash, javascript osv.
> brugt til blær uden omtanke.

Det er nu ikke kun det. Whitespace som Jørgen nævner har også en del at
sige i både JS, CSS og HTML. Lægger man det hele sammen, så kan man
spare rigtigt meget. Men nok specielt, hvis man følger best practise fra
start.

Men man kan selvfølgelig også bare GZIPe CSS-filen i stedet? Dette
skulle være muligt via/indbygget i PHP, men jeg kan ikke umiddellbart
tiltvinge det i ASP (kræver nok serveradgang).

Men der er som sagt andre ting end lige CSS i de best practises fra
Google, det var jo bare hvad jeg hev frem, og hvad jeg synes der var
interessant. De bygger sådan set videre på nogle andre tests og
opfølgende best practises fra Yahoo, som også tager højde for f.eks.
uforholdsmæssigt store billeder, bare som eksempel.
CSS-optimering er først interessant (for de fleste), når alle de
lavthængende frugter er taget. Dog synes jeg man skal kende baggrunden,
hvis man vælger ikke at optimere/følge best practise i sin CSS, så man
har valgt udfra viden.

Mange store hjemmesider bruger allerede de fleste af de retningslinjer,
bl.a. minify, GZIPing, sammensatte scripts og styles og CSS-sprite. Til
trods altså for deres samtidige ukritiske brug af JS-frameworks, men
hastigheden skal jo hentes et eller andet sted, ellers skrider brugerne.

BTW... Flash? Hvad er det?? Det eneste sted, jeg får Flash ind ad døren,
er på YouTube, og også det eneste sted det ikke blockes automatisk af
enten AD-blocker til FF, eller alm. rettigheder i Opera... Og YouTube
går vel forhåbentlig snart HTML5.. ;)


MVH
Rune Jensen

---

Rune Jensen wrote:

> Men man kan selvfølgelig også bare GZIPe CSS-filen i stedet?

Hvis din server understøtter gzip'ede filer, så skriver du bare(linux):
gzip 'dit.fil.navn', og så får du en fil der hedder 'dit.fill.navn.gz', og
den kan du så rename og lægge ud.

Men det er _serveren_, der afgør om det kan lade sig gøre, og ikke sproget
(ASP/PHP eller andet).

--
Med venlig hilsen
Stig Johansen

---

Den 22-04-2010 16:28, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Men man kan selvfølgelig også bare GZIPe CSS-filen i stedet?
>
> Hvis din server understøtter gzip'ede filer, så skriver du bare(linux):
> gzip 'dit.fil.navn', og så får du en fil der hedder 'dit.fill.navn.gz', og
> den kan du så rename og lægge ud.
>
> Men det er _serveren_, der afgør om det kan lade sig gøre, og ikke sproget
> (ASP/PHP eller andet).

Ja, jeg undersøgte det jo senere i dag, og det ligner en dead end (for
mig). Altså jeg ville gerne have GZIPing af JS og CSS-filer, og serveren
understøtter også GZIP, men GZIPping af disse filer er vel en
serverindstillling.

Jeg forstår ikke, hvorfor man opsætter serveren til kun at GZIPpe rene
HTML-filer. Hvad har de andre filer gjort?


MVH
Rune Jensen

---

Rune Jensen wrote:

> Jeg forstår ikke, hvorfor man opsætter serveren til kun at GZIPpe rene
> HTML-filer. Hvad har de andre filer gjort?

Jeg ved ikke hvordan man opsætter de forskellige servere.
Min egen server har jeg lavet, så den selv finder ud af om det er gzip'et
eller ej, så der er ikke noget opsætning.

--
Med venlig hilsen
Stig Johansen

---

Den 23-04-2010 19:27, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Jeg forstår ikke, hvorfor man opsætter serveren til kun at GZIPpe rene
>> HTML-filer. Hvad har de andre filer gjort?
>
> Jeg ved ikke hvordan man opsætter de forskellige servere.
> Min egen server har jeg lavet, så den selv finder ud af om det er gzip'et
> eller ej, så der er ikke noget opsætning.

Hej, Stig,

Jeg har forsøgt at finde lidt om emnet, men det har ikke været helt let.

Så vidt jeg lige forstår, så er det en default-setting på servren, at
kun HTML-filer GZIPes - om det er korrekt, ved jeg dog ikke.

Men - jeg har lavet en test af en komplet HTML-side med tilhørende CSS
og JS både med og uden GZIP, og forskellen var - synes jeg - ret
mærkbar, og det altså selv om der ikke GZIPes på hverken JS eller CSS i
nogle af tilfældene.

Andre kan/har måske lave bedre, mere præcise tests end jeg på det punkt,
jeg har ikke haft måleværktøj til at understøtte testen, så den er ikke
"videnskabelig redelig", kun hvad jeg selv havde af fornemmelse omkring
hastigheden.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Men - jeg har lavet en test af en komplet HTML-side med tilhørende CSS
> og JS både med og uden GZIP, og forskellen var - synes jeg - ret
> mærkbar, og det altså selv om der ikke GZIPes på hverken JS eller CSS i
> nogle af tilfældene.

Jeg tror nok FF noglle gange springer reload over på JS og CSS selvom den er
sat til 'ask every time'.

Jeg er ikke 1000% sikker, men mener jeg har haft nogle 'mærkelige' episoder
med rettelse af JS/CSS.

> Andre kan/har måske lave bedre, mere præcise tests end jeg på det punkt,
> jeg har ikke haft måleværktøj til at understøtte testen, så den er ikke
> "videnskabelig redelig", kun hvad jeg selv havde af fornemmelse omkring
> hastigheden.

Du kan bare lave en ls (dir) af filen før og efter gzip, så kan man se
forskellen.

unzip delen(i browseren) koster stort set ingen (cpu) tid.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen skrev:

> Det er nu ikke kun det. Whitespace som Jørgen
> nævner har også en del at sige i både JS, CSS
> og HTML. Lægger man det hele sammen, så kan
> man spare rigtigt meget.

Det var netop den måling jeg efterlyste - prøv at
lave to ens siden, den ene med optimering af den
slags, den anden uden.

Jeg lavdede sådan noget for 10 år siden - her var
der en målbar forskel - i dag er der ingen den kan
se forskel - man kan måske måle det i millisekunder.

Der skal virkelig store filer til, før man kan mærke en
forskel. Er en css- eller js-fil først indlæst i brugerens
casche, går det lynhurtigt - det samme med billeder.

Ikke-optimerede databaseopkald tager væsentligt
længere tid, men det er en anden snak.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 23-04-2010 23:58, Allan Vebel skrev:
> Rune Jensen skrev:
>
>> Det er nu ikke kun det. Whitespace som Jørgen
>> nævner har også en del at sige i både JS, CSS
>> og HTML. Lægger man det hele sammen, så kan
>> man spare rigtigt meget.
<SNIP>
> Der skal virkelig store filer til, før man kan mærke en
> forskel.

....eller mange samtidige brugere.


MVH
Rune Jensen

---

Rune Jensen skrev:

>> Der skal virkelig store filer til, før man kan mærke
>> en forskel.
>
> ...eller mange samtidige brugere.

Det er sket ikke det jeg mener, og det ved du godt.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 24-04-2010 01:34, Allan Vebel skrev:
> Rune Jensen skrev:
>
>>> Der skal virkelig store filer til, før man kan mærke
>>> en forskel.
>>
>> ...eller mange samtidige brugere.
>
> Det er sket ikke det jeg mener, og det ved du godt.

Næh, det ved jeg ikke. Det er en glimrende idé at optimere sin side, -
bl.a. - hvis man har mange samtidige brugere. Det kan man sådan set
spare penge på i mere end én forstand. Det er ikke kun brugeren, som
spilder tiden med at hente uudnyttede bytes, det koster også på
serverressourcer.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Det er en glimrende idé at optimere sin side, -
> bl.a. - hvis man har mange samtidige brugere.

Det er ikke lige det det drejer sig om her - jeg
snakker om store sider med få brugere.

Fik du lavet de eklsempler jeg foreslog?

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 24-04-2010 02:30, Allan Vebel skrev:

> Fik du lavet de eklsempler jeg foreslog?

Ikke egentlig. Går med en idé om en multi-funktion ligesom den til WP,
godt nok i ASP, så burde man kunne se en forskel. Men det er lidt sent,
og tænkehatten er ikke rigtigt opladet, så det må blive senere.


MVH
Rune Jensen

---

Den 23-04-2010 23:58, Allan Vebel skrev:

> Ikke-optimerede databaseopkald tager væsentligt
> længere tid, men det er en anden snak.

Dette er jeg til gengæld helt enig i. Men det findes der så også
løsninger på, jeg har set en slags disk-cashe, dvs. en funktion, som
laver en statisk udgave af en given side, så altfor mange databasekald
undgås.

Om det så lige er den allerbedste løsning, det ved jeg ikke, kan ikke
huske, hvem af de 20+ hjemmesider, jeg har gennemtrawlet, jeg har læst det.

Men i og for sig burde man nok i stedet i første omgang kigge på
optimering af selve databasen.

V2 har vidst haft lidt om netop dette kørende et stykke tid.


MVH
Rune Jensen

---

Rune Jensen wrote:

> V2 har vidst haft lidt om netop dette kørende et stykke tid.

Det kommer jævnligt, for PHK (der blogger der) er 'fadder' til Varnish, som
er et cachesystem til større sites.

--
Med venlig hilsen
Stig Johansen

---

Den 23-04-2010 23:58, Allan Vebel skrev:

> Ikke-optimerede databaseopkald tager væsentligt
> længere tid, men det er en anden snak.

Og det kan jeg snakke med om.
Databaseopkald er langt mere performancedræbende på mine sider end
css-filen (eller var det i hvert fald indtil jeg for 1-2 måneder siden
fandt ud af at en database med fordel kunne indekseres).

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 24-04-2010 08:12, Philip Nunnegaard skrev:
> Den 23-04-2010 23:58, Allan Vebel skrev:
>
>> Ikke-optimerede databaseopkald tager væsentligt
>> længere tid, men det er en anden snak.
>
> Og det kan jeg snakke med om.
> Databaseopkald er langt mere performancedræbende på mine sider end
> css-filen (eller var det i hvert fald indtil jeg for 1-2 måneder siden
> fandt ud af at en database med fordel kunne indekseres).

Så har du jo allerede mærket hvad en optimering vil sige[1]. Og du må
også have fået gladere brugere af det. Måske Google-bot også vil belønne
det, man kan aldrig vide...


[1] Det siger sig selv, at man som udgangspunkt sætter ind der, hvor der
er størst besparelse at hente i forhold til arbejdsindsats og evt. krav
fra brugerne/serverload.


MVH
Rune Jensen

---

Philip Nunnegaard wrote:

> Databaseopkald er langt mere performancedræbende på mine sider end
> css-filen (eller var det i hvert fald indtil jeg for 1-2 måneder siden
> fandt ud af at en database med fordel kunne indekseres).

Uha, Phillip - en database uden (passende) indexer er næsten den sikre død.
Indexer er godt, for mange indexer er ikke godt.

Men den diskussion hører vist til i dk.edb.database

--
Med venlig hilsen
Stig Johansen

---

Den 24-04-2010 12:38, Stig Johansen skrev:

> Uha, Phillip - en database uden (passende) indexer er næsten den sikre død.
> Indexer er godt, for mange indexer er ikke godt.
>
> Men den diskussion hører vist til i dk.edb.database

Det gør den (altså hører hjemme i databasegruppen). Men så forstår I
sikkert hvorfor jeg er mere optaget af databasekald end besparelse af
millisekunder på en css-fil.
Dette her gav en besparelse der kunne måles i hele sekunder.

Og jeg indekserer selvfølgelig kun de kolonner som jeg hyppigt har med i
where-delen af sql-sætningerne.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 24-04-2010 15:24, Philip Nunnegaard skrev:
> Den 24-04-2010 12:38, Stig Johansen skrev:
>
>> Uha, Phillip - en database uden (passende) indexer er næsten den sikre
>> død.
>> Indexer er godt, for mange indexer er ikke godt.
>>
>> Men den diskussion hører vist til i dk.edb.database
>
> Det gør den (altså hører hjemme i databasegruppen). Men så forstår I
> sikkert hvorfor jeg er mere optaget af databasekald end besparelse af
> millisekunder på en css-fil.

Hmmm. OK, men jeg mener nu at al optimering er interessant (omend det
ikke er alt man skal bruge). Specielt interessant er den, som direkte
gavner brugeren, og jeg er også enig med Betel - udfra en
risikovurdering for fejl - at man skal have et vidst overblik, selv om
man optimerer. Men jeg er ret ny indenfor feltet, jeg har kun testet en
brøkdel, og derfor har jeg ikke som sådan nogle foretrukne metoder,
eller nogle jeg ikke ville bruge. Jeg havde nok ikke lige gjort det helt
tydeligt i min indledning.


MVH
Rune Jensen

---

Philip Nunnegaard wrote:

> Dette her gav en besparelse der kunne måles i hele sekunder.
>
> Og jeg indekserer selvfølgelig kun de kolonner som jeg hyppigt har med i
> where-delen af sql-sætningerne.

Det kan også være en fordel at kigge på indexering i forbindelse med join's
(hvis du har sådan nogle).

Det med for mange indexer gik bare på, at indexer nedsætter
skrivehastigheden, men øger læsehastigheden.

Så afvejning skal ske i de enkelte tilfælde.

--
Med venlig hilsen
Stig Johansen

---

Bertel Lund Hansen skrev:

> Det er ikke placeringen af en linje i en CSS-fil der får
> et site til at sluge tid. Det er udenomsbras som flash,
> javascript osv. brugt til blær uden omtanke.

Helt enig.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 23-04-2010 23:59, Allan Vebel skrev:
> Bertel Lund Hansen skrev:
>
>> Det er ikke placeringen af en linje i en CSS-fil der får
>> et site til at sluge tid. Det er udenomsbras som flash,
>> javascript osv. brugt til blær uden omtanke.
>
> Helt enig.

Men at i ikke bruger hverken Flash eller JS, betyder ikke, at verden
udenom står stille og gør som jer. Ikke at jeg selv synes Flash er fedt,
men jeg ser det aldrig alligevel, for det bliver altid blocked.

JS er en nødvendighed i mange web2-applikationer, fordi det giver
brugerne muligheder, de ellers ikke ville få. Og at ville stille verden
"tilbage til dengang nettet var ren tekst", det er en meget gammeldags
tankegang, som iøvrigt også vil dræbe nettet i længden.

Udfordringen ligger ikke i at få JS mm. banlyst, men i at finde ud af en
måde at leve med det på. Jo, måske at få Flash banlyst pga.
skodsikkerhed hos Adobe den går jeg helt ind for, men ikke JS.


MVH
Rune Jensen

---

Rune Jensen skrev:

>> Helt enig.

> at ville stille verden "tilbage til dengang nettet var
> ren tekst", det er en meget gammeldags
> tankegang, som iøvrigt også vil dræbe nettet i
> længden.

Jeg har bare set så mange eksempler på funktioner
i javascript, der kunne laves meget mere effektivt
og brugervenligt i css.

> Udfordringen ligger ikke i at få JS mm. banlyst,
> men i at finde ud af en måde at leve med det på.

Javascript har været en del af web gennem mange
år - det skal bare ikke misbruges til noget der kan
laves på en nemmere måde.

Enkelte ældre brugere slår for eksempel javascript
helt fra i deres browser, og mister her navigation,
hvis en menu er lavet i javascript.

Er den lavet i html og css, er den mere tilgængelig,
også blandt søgemaskinerne.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk | http://webdesigngruppen.dk

---

Den 24-04-2010 01:50, Allan Vebel skrev:
> Rune Jensen skrev:
>
>>> Helt enig.
>
>> at ville stille verden "tilbage til dengang nettet var
>> ren tekst", det er en meget gammeldags
>> tankegang, som iøvrigt også vil dræbe nettet i
>> længden.
>
> Jeg har bare set så mange eksempler på funktioner
> i javascript, der kunne laves meget mere effektivt
> og brugervenligt i css.

Det er noget andet. For hvis man erlægger den indstilling, at JS ikke er
slemt i sig selv, men forkert brug af den er slemt, er man allerede nået
langt.

>> Udfordringen ligger ikke i at få JS mm. banlyst,
>> men i at finde ud af en måde at leve med det på.
>
> Javascript har været en del af web gennem mange
> år - det skal bare ikke misbruges til noget der kan
> laves på en nemmere måde.

Det er jeg helt enig i. Men ikke desto mindre, er det hvad folk gør.
Bl.a. ved ukritisk brug af frameworks.

Og selv om jeg er indædt modstander af teknologi-misbrug, må jeg også
sande, at nye teknologier kan give nye muligheder for ikke teknisk
mindede til at ytre sig online. Og det ser jeg som en god ting, og langt
henad vejen måske også vigtigere (dog ikke ultimativt, når det gælder
sikkerhed og viden om det).

> Enkelte ældre brugere slår for eksempel javascript
> helt fra i deres browser, og mister her navigation,
> hvis en menu er lavet i javascript.

Det er en gammel best practise ikke at lave sin menu i ren JS. Det må
vel også være os, som skal prædke den. Men som et tidligere eksempel fra
Jørgen viste, så er man også her nået langt - også selv om jeg
principielt er modstander af frameworks udfra en betragtning om, de
henter mere ind end nødvendigt - er det bedre at bruge dem, som trods
alt er kodet af folk med en del erfaring, end at lave en "egendesignet"
ren JS-menu.

Jeg tror ikke rigtigt på, man kan "løfte barren" til den største højde
fra start. Men kan man løfte den lidt, og måske højere hver gang, er det
bedre end ingenting. Så er det bare med at gøre folk opmærksomme på, der
er altid mulighed for forbedringer.

> Er den lavet i html og css, er den mere tilgængelig,
> også blandt søgemaskinerne.

Ja. Men det gør ikke noget, at JS er tilføjet for at forøge
funktionaliteten. Hvis man nu skal være pedantisk ;)


MVH
Rune Jensen

---

Den 24-04-2010 01:14, Rune Jensen skrev:

> JS er en nødvendighed i mange web2-applikationer, fordi det giver
> brugerne muligheder, de ellers ikke ville få. Og at ville stille verden
> "tilbage til dengang nettet var ren tekst", det er en meget gammeldags
> tankegang, som iøvrigt også vil dræbe nettet i længden.

Jeg opfatter det også som en gammeldags opfattelse at skulle spare på én
skide css-fil. Halloooo! Jeg har sgu 6 Mbit download! Og så er min
forbindelse endda langsom i forhold til hvad de fleste efterhånden har!
(TDC leverer bare ikke hurtigere hastighed her hvor jeg bor)

Så synes jeg at det er mere relevant at optimere de der kæmpe
javascriptframeworks som mange hjemmesider kører med for lige at have en
funktion der reelt kunne klares med 3 linjer kode.
Eller få ryddet dem af vejen der bruger 20 linjer javascript til noget
der kunne klares med 3 linjer CSS.

Det er ikke sider som Hjemmesideskolen.dk, vebel.dk eller lignende jeg
ville gå efter. Jeg ville hellere gå efter sider som dr.dk,
berlingske.dk osv. som kan lægge enhver ældre PC ned, så man må
genstarte efter et besøg.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 24-04-2010 08:05, Philip Nunnegaard skrev:

> Det er ikke sider som Hjemmesideskolen.dk, vebel.dk eller lignende jeg
> ville gå efter. Jeg ville hellere gå efter sider som dr.dk,
> berlingske.dk osv. som kan lægge enhver ældre PC ned, så man må
> genstarte efter et besøg.

Berlingske.dk benytter skam i dén grad optimering. De benytter Drupal
som CMS

http://www.version2.dk/artikel/11241-drupal-skal-levere-60-mio-sidevisninger-for-btdk

og en diskcashe (hovedsageligt) udviklet af en dansker, Poul Henning
Kamp til det. En cashe, som han vel for så vidt er blevet ret berømt
for, eftersom den kører over hele verden. Den er iøvrigt OSS.

http://en.wikipedia.org/wiki/Varnish_%28software%29

Du kan følge hans Blog på v2.dk.

PS.: Jeg har *ikke* skrevet nogetsomhelst sted, at det er
hjemmesideskolen eller lign. man skal gå efter. Men at have en
opfattelse af at *alle* herinde laver sider på samme måde som de
tre-fire mest aktive, det mener jeg ikke nødvendigvis er repræsentativt.
Jeg henviste også bl.a. til WP-optimering af den grund.

Minify i en dynamisk version er jeg selv interesseret i - om andre er,
det må være op til dem. Jeg vil i hvert fald ikke udelukke noget
udelukkende pga. ideologi. Det skal prøves, før jeg afviser
nogetsomhelst. Jeg har ikke DB, så den vej kan jeg ikke gå i optimering.


MVH
Rune Jensen

---

Den 24-04-2010 09:27, Rune Jensen skrev:

> Jeg henviste også bl.a. til WP-optimering af den grund.

Jeg optimerer ikke kun selv for at opnå bedre hastighed her og nu. Jeg
gør det også for at lære teknikkerne bag at kende, og det gælder både på
loadtid og performance/responsiveness. Bl.a. CSS3 tror jeg vil stille
nye krav til brugerens maskine på visse punkter (transition, transform
og box-shadow som eksempel), og jeg vil godt vide, hvor jeg kan sætte
ind, hvis det er. Derfor udelukker jeg heller ikke noget på forhånd, men
tager det fra A-Z.

MS har iøvrigt taget konsekvensen af øget krav fra brugerne om
performance, og IE9 vil køre over GPUen, hvilket vil gøre den ret kvik
til dynamisk grafik, hvis ellers de holder hvad de lover. Om det er den
rigtige løsning, ved jeg ikke, men man kan håbe, de andre også finder
nogle løsninger på bedre hastighed i browseren selv. Her er Opera sjovt
nok foran Google i de seneste benchmarks, hvilket måske kan undre,
eftersom det ikke er mere end et år siden eller så, den var på linje med
IE8 (og den, som så forsinker udviklingen vil, som altid, være IE(now)-1).


MVH
Rune Jensen

---

Den 24-04-2010 10:38, Rune Jensen skrev:

> (...) Bl.a. CSS3 tror jeg vil stille
> nye krav til brugerens maskine på visse punkter (transition, transform
> og box-shadow som eksempel)

Man kan måske få en fornemmelse for dette af denne test:

http://www.webdesigngruppen.dk/designteknik/css3_tests.asp

Hvis man kigger på den i Opera, hvor CSS3 renderes fuldt, i forhold til
FF som kun forstår et minimum valid CSS3, så er siden ved scroll
mærkbart langsommere i Opera, og det er netop CSS3en, som gør det, da
den CSS3-grafik kræver en masse ekstra beregninger. Fordelen ved en
CSS3-løsning til grafik er naturligvis skalérbarheden uden pixellering.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Man kan måske få en fornemmelse for dette af denne test:

> http://www.webdesigngruppen.dk/designteknik/css3_tests.asp

> Hvis man kigger på den i Opera, hvor CSS3 renderes fuldt, i forhold til
> FF som kun forstår et minimum valid CSS3, så er siden ved scroll
> mærkbart langsommere i Opera,

Ikke hos mig. Opera (10.10) ruller hurtigt men har så jævnligt
pauser hvor det pludseligt går langsomt. FF er langsom hele
tiden.

Det spøjse er at rulningen går lige så hurtigt som man bare vil
have det hvis man bruger musens rullehjul (begge browsere).

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 24-04-2010 13:27, Bertel Lund Hansen skrev:
> Rune Jensen skrev:
>
>> Man kan måske få en fornemmelse for dette af denne test:
>
>> http://www.webdesigngruppen.dk/designteknik/css3_tests.asp
>
>> Hvis man kigger på den i Opera, hvor CSS3 renderes fuldt, i forhold til
>> FF som kun forstår et minimum valid CSS3, så er siden ved scroll
>> mærkbart langsommere i Opera,
>
> Ikke hos mig. Opera (10.10) ruller hurtigt men har så jævnligt
> pauser hvor det pludseligt går langsomt.

Det er når man skal over grafikken. Når man er forbi den, behøver
browseren ikke regne på grafikken (tror jeg).

> FF er langsom hele
> tiden.

Hos mig er den lige hurtig hele tiden med FF.

Jeg spørger mig selv, mener nemlig at have oplevet det før, om det er
fordi FF forsøger at tolke den CSS, som den ikke forstår, og så kløjes i
det.

> Det spøjse er at rulningen går lige så hurtigt som man bare vil
> have det hvis man bruger musens rullehjul (begge browsere).

Det overrasker mig så. For her er det ens, om man bruger rullebjælken
eller musehjul.

Jeg bruger iøvrigt Opera 10.51 og FF 3.6.3, der kan måske også være
forskelle i versionerne.

Men summasummarum for mig er, at det skal være hurtigt, når det er
endeligt færdigimplementeret i browserne, ellers bliver det lidt af en
skuffelse, når man nu venter på det og har forventninger til det.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Det overrasker mig så. For her er det ens, om man bruger rullebjælken
> eller musehjul.

Hvordan går det hvis du bruger Page Up/Down? Hos mig er det lige
så hurtigt som tastaturet kan sende signaler - også begge
browsere.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:

> Hvordan går det hvis du bruger Page Up/Down? Hos mig er det lige
> så hurtigt som tastaturet kan sende signaler - også begge
> browsere.

Først nu ser jeg at du taler im rullebjælken. rullebjælke,
rullehjul eller page-knapperne - det går rasende hurtigt ved dem
alle.

Det går kun langsom hvis jeg bruger piletasterne op/ned.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:

> Det går kun langsom hvis jeg bruger piletasterne op/ned.

Nu har jeg opgraderet til Opera 10.51, og så går det langsomt.

Piletasterne er så langsomme at de er ubrugelige. Rullebjælken er
hurtig med en lille forsinkelse ved dobbelt baggrund og en
opbremsning ved multitesten, og noget lignende sker ved brug af
page-knapperne.

Version 10.10 er kun hurtig fordi den ikke tager sig af
CSS3-effekterne..

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Den 24-04-2010 14:51, Bertel Lund Hansen skrev:
> Bertel Lund Hansen skrev:
>
>> Det går kun langsom hvis jeg bruger piletasterne op/ned.
>
> Nu har jeg opgraderet til Opera 10.51, og så går det langsomt.
>
> Piletasterne er så langsomme at de er ubrugelige. Rullebjælken er
> hurtig med en lille forsinkelse ved dobbelt baggrund og en
> opbremsning ved multitesten, og noget lignende sker ved brug af
> page-knapperne.
>
> Version 10.10 er kun hurtig fordi den ikke tager sig af
> CSS3-effekterne..

Aha...

Jeg håber dælme, det bliver bedre, da, med de nyere versioner ;)

På den anden side, så er f.eks. RGBA, rounded corners, multiple
backgrounds helt fine hver for sig her.


MVH
Rune Jensen

---

Den 24-04-2010 15:05, Rune Jensen skrev:

> På den anden side, så er f.eks. RGBA, rounded corners, multiple
> backgrounds helt fine hver for sig her.

Det er skyggerne, som tager al beregningen, det er ret tydeligt, så
box-shadow skal man måske vente lidt med at bruge.

Text-shadow tror jeg så ikke man taber det store hastighedsmæssigt eller
i IE8 ved at bruge, og det er én linje CSS. Det bruger jeg iøvrigt også
selv, sådan for sjov.


MVH
Rune Jensen

---

Den 24-04-2010 15:05, Rune Jensen skrev:

> På den anden side, så er f.eks. RGBA, rounded corners, multiple
> backgrounds helt fine hver for sig her.

Ja, jeg er bare vildt glad for at runde hjørner nu kan laves til alle
browsere undtagen IE nu.
Er allerede begyndt at bruge det i det små, og så lever jeg med at de
ca. 60% IE-brugere får kantede hjørner, eftersom jeg ville have haft det
alligevel ellers.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 24-04-2010 14:32, Bertel Lund Hansen skrev:
> Bertel Lund Hansen skrev:
>
>> Hvordan går det hvis du bruger Page Up/Down? Hos mig er det lige
>> så hurtigt som tastaturet kan sende signaler - også begge
>> browsere.
>
> Først nu ser jeg at du taler im rullebjælken. rullebjælke,
> rullehjul eller page-knapperne - det går rasende hurtigt ved dem
> alle.

Så går grænsen nok ved min maskines specifikationer.

Vista Home Basic, med alt intern pynt slået fra, Intel celeron 2,1 gHz,
1gb RAM

Jeg indrømmer, den er ikke verdens hurtigste eller bedst bestykkede, men
uden CSS3, der går det fint i både Opera og FF, men med CSS3, der hopper
og danser den i Opera, når jeg skal forbi den blå "blok".

Og alt andet lige ville jeg nok også være tvunget til at tage hensyn til
evt. andre med samme lave hastighed, altså finde en eller andet middelvej.

> Det går kun langsom hvis jeg bruger piletasterne op/ned.

Spøjst. Det burde da være det samme om det er mus eller keyboard...?

Men hos mig er det som sagt lidt hip som hap, hvis den skal forbi den
"klods", så brokker den sig.

Det kan selvfølgelig være, jeg har lavet for komplekst CSS3, det kan
også være, algoritmen bare endnu ikke er helt på plads i browseren.


MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@gmail.com> wrote in message
news:4bd2ae1c$0$4811$456a7185@news.cirque.dk...
> MS har iøvrigt taget konsekvensen af øget krav fra brugerne om
> performance, og IE9 vil køre over GPUen, hvilket vil gøre den ret kvik
> til dynamisk grafik, hvis ellers de holder hvad de lover.

Jeg tror du skal tage MS's ord med et vist gran salt.
Det er jo nok dee færreste websider der hr brug for hårdkogt
grafik-rendering, og din side:
http://www.webdesigngruppen.dk/designteknik/css3_tests.asp
loader, og vises 'within a blink of an eye' her på Win2K og FF/Opera og på
en ~850MHz 'klods'.

De ting du snakker om er basale rendering funktioner, som ikke kræver nogen
GPU.

Næh du, MS's budskab er, at man skal 'opgradere' sit OS, da Vista ikke blev
det de troede det ville, og nu prøver man at tvinge til opgradering til
Win7.

XP er vistnok supporteret til 2014 (indtil videre), så der går laaang tid
inden man kan betragte IE9 som 'standardbrowser' på windows.

Mit gæt er, at det tager længere tid end Win2K/IE6, da der er flere, samt
supporten ikke er opphørt.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Den 24-04-2010 12:38, Stig Johansen skrev:
> "Rune Jensen"<runeofdenmark@gmail.com> wrote in message
> news:4bd2ae1c$0$4811$456a7185@news.cirque.dk...
>> MS har iøvrigt taget konsekvensen af øget krav fra brugerne om
>> performance, og IE9 vil køre over GPUen, hvilket vil gøre den ret kvik
>> til dynamisk grafik, hvis ellers de holder hvad de lover.
>
> Jeg tror du skal tage MS's ord med et vist gran salt.
> Det er jo nok dee færreste websider der hr brug for hårdkogt
> grafik-rendering, og din side:
> http://www.webdesigngruppen.dk/designteknik/css3_tests.asp
> loader, og vises 'within a blink of an eye' her på Win2K og FF/Opera og på
> en ~850MHz 'klods'.
>
> De ting du snakker om er basale rendering funktioner, som ikke kræver nogen
> GPU.

Arh, OK, det var nu heller ikke budskabet. Men ved at kende til, hvordan
browsren fortolker CSSen og hvilke ting, som tager tid, kan man måske
hive lidt ekstra kræfter ud. Jeg er i "test-perioden", så jeg har sådan
set ingen præferencer hvad det angår - endnu. Men - et PS - hos mig, der
er den altså virkelig langsom, når man scroller ned over den CSS3-tingest...

> Næh du, MS's budskab er, at man skal 'opgradere' sit OS, da Vista ikke blev
> det de troede det ville, og nu prøver man at tvinge til opgradering til
> Win7.

Mig rører deres salgstaler ikke, jeg var offer for Vista selv, og har
besluttet mig for aldrig mere at betale én eneste krone til MS igen.
Sjældent er jeg blevet snydt så umanérligt groft, hvor sælgeren samtidig
har grinet af mig og hånet mig og været stolt af det. Det finder jeg mig
naturligvis ikke i. Herefter, der er det sådan set bare OSS hele vejen
igennem, så tager jeg det lidt ad gangen for at lære det, man kan hvad
man vil. Det er ikke et personligt had til MS som sådan, det ville have
været det samme ligemeget hvilket firma der snød mig, jeg har en grænse,
som er ultimativ, og den har de så overtrådt med flere kilometer, og så
er det dét.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Men - et PS - hos mig, der
> er den altså virkelig langsom, når man scroller ned over den
> CSS3-tingest...

Hvis du tænker på den blå 'klods', så hakker den en anelse ved scroll, men
ikke noget kritisk.

Bortset fra det ligner den mere noget der burde laves med et
baggrundsbillede.

--
Med venlig hilsen
Stig Johansen

---

Den 24-04-2010 13:19, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Men - et PS - hos mig, der
>> er den altså virkelig langsom, når man scroller ned over den
>> CSS3-tingest...
>
> Hvis du tænker på den blå 'klods', så hakker den en anelse ved scroll, men
> ikke noget kritisk.

Det irriterer så mig helt enormt...

> Bortset fra det ligner den mere noget der burde laves med et
> baggrundsbillede.

Ja, men det er jo en test ;)

Forestil dig, at man med to-tre CSS-deklarationer kunne lave
MAC-udseende på sine knapper i alle forme, at grafikken fulgte
størrelsen af knappen (kan ikke laves umiddelbar med baggrundsbillede -
med mindre, man bruger CSS3 stretch, som kan/vil pixellere, evt.
multiple backgrounds, som kræver flere billeder), og at det ikke krævede
den ekstra request til serveren.

Problemet synes jeg er hastigheden hos brugeren efter load, hvis man vil
lave pynt med CSS3. Jeg bryder mig ikke om, den "hopper", når man
scroller over grafikken, men det bliver forhåbentlig bedre. At det
kræver mere beregning for browseren end hvis man bare bruger et
baggrundsbillede, det er jeg dog ikke i tvivl om.

Jeg tror som sagt det bliver lidt af en udfordring at finde den "bedste
måde" at udnytte CSS3 "korrekt" på, for man kan virkelig lave avancerede
ting. Som risikerer at irritere brugeren også pga. hastighed, og det er
det eneste, som ville kunne afholde mig fra at bruge det.


MVH
Rune Jensen

---

I langt de fleste tilfælde er Viewstates så små at det i praksis ikke
betyder meget at de er der, 1000 karakterer kan se ud af meget men
selv på et 56K modem tager det kun et sekund at hente dem.
I tilfælde med meget store viewstates som fås med foreksempel en
datagrid giver det god mening at cache dem på serveren i stedet for at
sende dem frem og tilbage. Dette gøres med nogle (forholdsvis) få
linier kode.

Regards Jens Peter Karlsen.

On Thu, 22 Apr 2010 12:26:04 +0200, Rune Jensen
<runeofdenmark@gmail.com> wrote:

>problem. Ikke bare på loadtid af siden (som f.eks. kan skyldes alenlange
>viewstates fra NET), men også på udførelsen, hvor mange ukritisk

---

Den 22-04-2010 14:58, Jens Peter Karlsen skrev:
> I langt de fleste tilfælde er Viewstates så små at det i praksis ikke
> betyder meget at de er der, 1000 karakterer kan se ud af meget men
> selv på et 56K modem tager det kun et sekund at hente dem.
> I tilfælde med meget store viewstates som fås med foreksempel en
> datagrid giver det god mening at cache dem på serveren i stedet for at
> sende dem frem og tilbage. Dette gøres med nogle (forholdsvis) få
> linier kode.

Mjah. Hvis alle viestate er i den størrelsesorden af 1000 karakterer
(som er mere end 1000 bytes), så kommer man hurtigt deropad hvor det gør
ondt. 2kb her og 2kb der, kan blive mange kb.

Men om det er viewstate, som fylder unødige kb, eller om det er et
billede på 5mb man derefter har skaleret ned til 50 gange 50px - det er
for mig ens baggrund det kommer af. Begge dele skyldes misforståelse af
teknologien til skade for brugeren.

Så kan man sige det ikke er NETs skyld når webdesigneren/programmøren
ikke forstår teknologien (det er der i hvert fald nogle, som gør), og
det er da til dels rigtigt. Men NET lægger så heller ikke ligefrem i sig
selv op til best practise, som jo handler om, som udgangspunkt, ikke at
spilde unødigt plads på noget, som ikke gavner brugeren... Hvilket man
kan se af, at alene NET-sider har viewstates i kb-størrelse, man finder
det aldrig i rene ASP eller PHP-sider.

Hvis NET var optimeret til best practise, så var sådan noget ..juks er
et pænt ord...slået fra som default.


MVH
Rune Jensen

---

Følgende er skrevet af Rune Jensen:
> Det bør være kendt for de fleste, at Google er gået ud med en direkte
> opfordring til at hastighedsoptimere sin hjemmeside. Og at sløve sider kan
> påvirke placering negativt (jeg synes så også, man skal skele til, at det
> irriterer brugerne helt enormt med langsommme sider, men whatever synspuinkt
> man nu lægger).
>
> Jeg faldt over deres "best practise" (en af dem), og her er bl.s. nogle ting
> taget op, som ikke før har haft så stor bevågenhed - bl.a. optimering af CSS.
>
> http://code.google.com/intl/da/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
>
> Bl.a. handler det om at tage hensyn til, hvordan CSS læses og udføres af
> browseren.
>
> Eksempel:
>
> ul#menu{ egenskaber ]
>
> er måske godt for læsbarheden, men skidt for hastigheden, da en ID allerede
> er unik. Ovenstående regel vil kræve mere beregning fra maskinen end:
>
> #menu{ egenskaber ]
>
>
> Nuvel, jeg siger ikke, man *skal* følge disse retningslinjer (og der er
> iøvrigt en del flere end denne) i alle tilfælde, men det at Google nu
> offentligt er gået frem med disse for mange næsten glemte regler, det tyder
> på, det er værd at bide mærke i, og i det mindste skele til, når man koder..
>
> Der er flere gode råd på samme side, bl.a. hvordan man skal placere sin
> inline style i forhold til eksterne scripts/stylesheets og eksterne
> stylesheets i forhold til javasacripts, samt nogle egentlige værktøjer og
> udvidelser til din browser til optimering af ens side. En del af rådene er
> også ret nemme at implementere, så der er IMO ingen undskyldning for ikke at
> gøre det.
>
> Brugere af CMSer som WordPress kan med fordel lede efter plug ins, som
> automatisk kan optimere koden, f.eks. GZIPing og minifying og samling af
> flere scripts i ét enkelt.
>
>
>
> MVH
> Rune Jensen

Jeg har aldrig rigtigt forstået fidusen med
ul#menu{...}
Den kan selvfølgelig forhindre, at klassen bliver brugt, hvis jeg
sætter id="menu" på andet end en ul. Men det har jeg ikke tænkt mig at
gøre, og skulle det ske, er der nok en del andre ting der også går
galt, så jeg får det rettet.
#menu er rigeligt. Og det vil så også virke, hvis jeg finder på at lave
min ul om til en div.

ul.menu{...} kan jeg se lidt fornuft i. Men ikke ret meget.
Det giver mulighed for også at have en
div.menu{...} og/eller en
p.menu{..} og/eller
span.menu{..}
Reelt behøver jeg kun to, for at blive forvirret over hvilken af de to
klasser - .menu - det nu er der er tale om et givet sted, og at jeg i
stedet for klassens navn, skal leder efter tagget i CSS filen, gør det
ikke spor nemmere at finde den rigtige...
Så jeg kalder klasserne noget forskelligt
menu_ul, menu_div... f.eks.

Jeg bruger kun sjældent andet end id og klasse. Id hvor en definition
kun skal bruges een gang - klasse hvor den vil kunne genbruges.

Der er mange muligheder for selectorer
http://www.w3.org/TR/CSS21/selector.html
og jeg skal da ikke være den der påstår at de fleste er overflødige -
men der er ret få af dem, der er uundværlige.
Der er ingen grund til at gøre tingene mere komplicerede end de er i
forvejen.

At det tager længere tid at få en side med et komplekst sæt CSS
definitioner vist, end et med et simplere, kan vel ikke overraske.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 22-04-2010 12:50, Birger Sørensen skrev:

> At det tager længere tid at få en side med et komplekst sæt CSS
> definitioner vist, end et med et simplere, kan vel ikke overraske.

Helt så enkelt er det nu ikke for alle. Det var først, da jeg læste de
best practises første gang hos Mozilla, at jeg forstod baggrunden for,
hvad der mnenes med "kompleksitet" og f.eks. hvorfor der er en forskel
på en ID og en tag.

Det er nok forståeligt for dig (og andre, som har arbejdet lang tid med
DOM), men var det altså ikke umiddelbart for mig. Det tog mig adskillige
timer at forstå størstedelen faktisk, og så mange skærmsider var der
heller ikke ;)


MVH
Rune Jensen