Hjælp til salg (Ikke internet)

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Fri, 23 Aug 2013 10:12:59 GMT

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
Vi kan blive enige om at være uenige, men som en sidste ting, følger du de ting jeg siger, vil du opleve en hurtigere server der kan håndtere langt flere brugere. Og det er uanset om du tror på det eller ikke :)

Lidt lad afslutning. "Vi kan blive enige om at være uenige, men jeg har ret". Så lad mig slutte med, at vi kan blive enige om at være uenige, men som en sidste ting, følger jeg de ting du skriver er det dårlig kodepraksis, unødig øget kompleksitet og øget behov for vedligeholdelse af koden. Noget jeg kun ville overveje hvis det var en edge case (100'er eller 1000'er af redirects uden et pattern man kan matche på), og ikke som en generel regel.

Det skal du være fuldt ud velkommen til at gøre som du vil, men det er bestemt ikke noget jeg vil anbefale nogen at gøre.

Uanset om min afsluttende kommentar er lad eller ikke, så ændre det ikke på tallene, og det ændre ikke på at hjemmesiden vil kunne håndtere flere brugere hurtigere. Det er ligegyldigt om det er flere tusinde eller 10 redirects lavet via rewrite i htaccess, de vil uanset hvad belaste en hjemmeside mere end de gavner.

Og nej det øger hverken kompleksitet eller vedligeholdelse hvis man tænker sig om når man laver det, læs fx: http://www.e-universe.dk/linkjuice-dc-usability. og det er på ingen måde dårlig kodepraksis at gøre eksakt som jeg siger tvært imod. Man vinder betydeligt mere ved at tænke, alt skal ud af htaccess og ind i vHost hvis man har den mulighed, ellers skal de ind i PHP. Man vinder både på hastighed, performance og ikke mindst på SEO siden.

Man kan altid bruge tid på at optimere den htaccess kode man har, men i de fleste tilfælde ændre det ikke på, at de vil belaste, især når man benytter sig af rewrites.

MVH Kim Tetzlaff

MVH Kim

Svar: Hastighedsoptimering på dit website

Mads — Fri, 23 Aug 2013 09:21:08 GMT

Kim Tetzlaff - KTJ-Media.dk:
Nej det er nu ikke en edge case, har mødt hundredvis af sites, der faktisk laver 1000+ redirects i deres htaccess, og har mødt endnu flere der laver 500+. og selv hvis du laver din skip, vil den rewrite alligevel belaste mere end hvis det stod i PHP. se fx eksemplet med den rewrite som wp bruger til permalinks, den er meget lille, men alligevel gør den at forespørgsler daler med næsten 16%.

Hvis man ligger med 1000 eller 500 unikke redirects i sin htaccess fil er det en edge case, typisk pga. manglende viden fra dem der har implementeret det eller hvis man virkelig kun har unikke URL'er. At du så tilsyneladende har oplevet 100-vis ændrer ikke på det. Jeg vil tro det max. er 1-2% af websites der har sådan noget snavs i deres htaccess fil.

Kim Tetzlaff - KTJ-Media.dk:
Vi kan blive enige om at være uenige, men som en sidste ting, følger du de ting jeg siger, vil du opleve en hurtigere server der kan håndtere langt flere brugere. Og det er uanset om du tror på det eller ikke :)

Lidt lad afslutning. "Vi kan blive enige om at være uenige, men jeg har ret". Så lad mig slutte med, at vi kan blive enige om at være uenige, men som en sidste ting, følger jeg de ting du skriver er det dårlig kodepraksis, unødig øget kompleksitet og øget behov for vedligeholdelse af koden. Noget jeg kun ville overveje hvis det var en edge case (100'er eller 1000'er af redirects uden et pattern man kan matche på), og ikke som en generel regel.

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Fri, 23 Aug 2013 08:56:46 GMT

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
Men jeg siger at de redirects som laves fx med rewrite i htaccess, belaster serveren unødvendigt meget, og at det er bedre for serveren og brugerne, og ja den generelle hastighed på siden, at man flytter disse redirects over i vHost hvor det kun læses en gang eller PHP hvor det kun læses 1 gang.

Jeg er enig i vHost, men det er stadig mod_rewrite (htaccess) der bliver brugt. PHP er jeg ikke enig i. Det kan også siges, at de brugere der skal redirectes vil opleve et langsommere site af at det kører gennem PHP, fordi de skal sende 2 HTTP requests for at komme til siden, i stedet for 1 hvis det var via htaccess.

Når brugeren skal redirectes, vil denne ikke kunne mærke forskel om det er den ene eller den anden der laver det. Det er kun i det tilfælde at rigtig mange brugere pludselig skal redirectes inden for meget kort tid at brugerne vil kunne mærke forskellen. Men det scenarie har jeg i min tid med optimering 12+ år, ikke oplevet ske. og det er selv på sites der har mere end 10.000 redirects indskrevet.

Tror stadig ikke rigtig du forstår hvad det er jeg skriver, jeg siger ikke at selve redirecten er hurtigere i PHP end i htaccess, men at alt hvad du skriver i din htaccess, belaster serveren mere end hvis det bare stod i PHP.

også selvom du skriver dette

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
Jeg prøvede dette med 300 redirects (via rewrites) på en normal hjemmeside. Jeg testede forsiden på hjemmesiden med og uden htaccess, først uden for at se hvad hjemmesiden kunne klare , og derefter med htaccess og de 300 redirects (3 gange langsommere end udgangspunktet). Dernæst flyttede jeg de 300 redirects over i php, omskrev dem selvfølgelig så de testede om det var den rette url, ca 1200 linjer PHP blev lavet i denne forbindelse. Jeg testede så forsiden igen, og performance kom næsten helt op til udgangspunktet (10 forespørgslers forskel). altså det samme som hvis ikke der havde været nogen htaccess fil på serveren.

Og dette er som sagt fordi htaccess læses linje for linje ved hvert forespørgsel til en fil, uanset om du har brug for det eller ikke.

Ja okay, 300 redirects linje for linje er vel også en edge case som skal behandles individuelt. Det kan godt være du får en forbedring ved at lave 1200 linjer if-else-redirect-helvede i PHP, men du kunne jo også have optimeret htaccess filen og nok opnå samme effekt.

htaccess filen bliver kun læst linje for linje hvis du laver den på den måde. Der er et skip flag man kan bruge til at springe linjer over i htaccess filen. Hvis du har 300 linjer med f.eks. ?page=ID som skal redirectes til en bedre struktur, kan man bruge noget i stil med:

RewriteCond %{QUERY_STRING} ^page=([0-9]*)$
RewriteRule . - [S=300]
...300 redirects her...

Hvis den så ikke matcher den første linje, vil den springe de næste 300 RewriteRule's over, som så ikke vil blive læst linje for linje. Præcis det samme som en if statement i PHP.

Nej det er nu ikke en edge case, har mødt hundredvis af sites, der faktisk laver 1000+ redirects i deres htaccess, og har mødt endnu flere der laver 500+. og selv hvis du laver din skip, vil den rewrite alligevel belaste mere end hvis det stod i PHP. se fx eksemplet med den rewrite som wp bruger til permalinks, den er meget lille, men alligevel gør den at forespørgsler daler med næsten 16%.

og med den skipmetode vil du i de fleste tilfælde ende ud i at skrive en langt større rewrite. en ting er query_string som man netop kan klare med lidt kode (som alligevel vil belaste). Men prøv at tage et scenarie som hedder:

forside.php -> /
index.php -> /
testurlen.html -> /urlen-vi-tester/

osv. hvor der stort set ikke er noget pattern at gå efter.

Uanset hvordan du vender og drejer det du siger så lyver tallene nu engang ikke, næsten uanset hvad du skriver i din htaccess, så belaster du mere end hvis du skrev det i php især når vi snakker rewrites. og det vil som jeg har skrevet en del gange før, belaste ved alle filer der bliver hentet, og der hentes typisk mere end 1 fil fra en webserver, når man besøger en hjemmeside.

Og i disse dage med page caching mm, så er det endnu mere omsonst at skrive i htaccess filen, da selv kaldet til html filen vil blive belastet mere end hvis dine redirects stod i php. stod det i PHP, ville det slet ikke blive berørt når en helt almindelig bruger besøger siden. og jeg kan love dig for at langt de fleste kald til din server/hjemmeside, vil være til filer der findes og sider der eksisterer og dermed ikke skal redirectes på nogen måde.

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
Yderligere giver det også andre fordele såsom catch all, ingen tab af linkjuice mm. så der nu engang kun fordele ved at putte det over i php frem for at blive ved med at spæde til i sin htaccess.

De ting har ikke noget at sige. Du kan lave de samme ting i en .htaccess fil (catch-all, ingen tab af linkjuice).

selvfølgelig kan man det, men så skal du jo så bare spæde til htaccess filen, frem for at lave en smartere og bedre løsning. og det kræver samtidig også at du hele tiden holder øje med om der nu er noget der skal redirectes.

En catch all vil dog være noget svær for dig at lave i en htaccess fil, da den som ordet siger, fanger alt, også dem man ikke kender til, og skal du lave det i htaccess, vil det kræve at htaccess filen ved eksakt hvilke sider der findes på dit site.

Vi kan blive enige om at være uenige, men som en sidste ting, følger du de ting jeg siger, vil du opleve en hurtigere server der kan håndtere langt flere brugere. Og det er uanset om du tror på det eller ikke :)

MVH Kim

Svar: Hastighedsoptimering på dit website

Mads — Fri, 23 Aug 2013 08:13:36 GMT

Kim Tetzlaff - KTJ-Media.dk:
Men jeg siger at de redirects som laves fx med rewrite i htaccess, belaster serveren unødvendigt meget, og at det er bedre for serveren og brugerne, og ja den generelle hastighed på siden, at man flytter disse redirects over i vHost hvor det kun læses en gang eller PHP hvor det kun læses 1 gang.

Jeg er enig i vHost, men det er stadig mod_rewrite (htaccess) der bliver brugt. PHP er jeg ikke enig i. Det kan også siges, at de brugere der skal redirectes vil opleve et langsommere site af at det kører gennem PHP, fordi de skal sende 2 HTTP requests for at komme til siden, i stedet for 1 hvis det var via htaccess.

Kim Tetzlaff - KTJ-Media.dk:
Jeg prøvede dette med 300 redirects (via rewrites) på en normal hjemmeside. Jeg testede forsiden på hjemmesiden med og uden htaccess, først uden for at se hvad hjemmesiden kunne klare , og derefter med htaccess og de 300 redirects (3 gange langsommere end udgangspunktet). Dernæst flyttede jeg de 300 redirects over i php, omskrev dem selvfølgelig så de testede om det var den rette url, ca 1200 linjer PHP blev lavet i denne forbindelse. Jeg testede så forsiden igen, og performance kom næsten helt op til udgangspunktet (10 forespørgslers forskel). altså det samme som hvis ikke der havde været nogen htaccess fil på serveren.

Og dette er som sagt fordi htaccess læses linje for linje ved hvert forespørgsel til en fil, uanset om du har brug for det eller ikke.

Ja okay, 300 redirects linje for linje er vel også en edge case som skal behandles individuelt. Det kan godt være du får en forbedring ved at lave 1200 linjer if-else-redirect-helvede i PHP, men du kunne jo også have optimeret htaccess filen og nok opnå samme effekt.

htaccess filen bliver kun læst linje for linje hvis du laver den på den måde. Der er et skip flag man kan bruge til at springe linjer over i htaccess filen. Hvis du har 300 linjer med f.eks. ?page=ID som skal redirectes til en bedre struktur, kan man bruge noget i stil med:

RewriteCond %{QUERY_STRING} !^page=([0-9]*)$
RewriteRule . - [S=300]
...300 redirects her...

Hvis den så ikke matcher den første linje, vil den springe de næste 300 RewriteRule's over, som så ikke vil blive læst linje for linje. Præcis det samme som en if statement i PHP.

Kim Tetzlaff - KTJ-Media.dk:
Yderligere giver det også andre fordele såsom catch all, ingen tab af linkjuice mm. så der nu engang kun fordele ved at putte det over i php frem for at blive ved med at spæde til i sin htaccess.

De ting har ikke noget at sige. Du kan lave de samme ting i en .htaccess fil (catch-all, ingen tab af linkjuice).

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 21:33:29 GMT

Rasmus L. Knabe:

Jeg har ikke særlig meget erfaring med at konfigurere eller optimere serverside, men har til gengæld arbejdet en del på optimering af alt hvad der sker i klienten, efter ySlows anbefainger, og her er det min erfaring at en sådan optimering vi føre til mærkbar perfomance forbedringer på de fleste hjemmesider.

Kunne dog være fedt at få styr på backend delen også... På større dynamiske webapps kan det jo være hel essentielt for brugeroplevelsen :)

Ja det giver også en mærkbar hastighedsforbedring, jeg selv har mange års erfaring med begge verdener. Backend optimering kan også giver lige så store og mærkbare resultater. Du kan typisk godt optimere på den PHP kode der er lavet, sådan at time to first byte bliver hurtigere. altså den ventetid der går fra du har efterspurgt hjemmesiden, til du rent faktisk får tilsendt html koden. Det har jeg gjort et utal af gange.

Yderligere kan man jo også optimere på serverens indstilinger, man kan som her, optimere sin htaccess, eller helt fjerne den hvis det er muligt, og på den måde opnå det at hjemmesiden kan håndtere flere brugere på en gang. man kan cache siderne (kan man også gøre via frontend optimeringer, selvom de jo reelt er backend fx w3tc's page caching)

mit udgangspunkt er typisk ikke, hvor meget hardware kan jeg stoppe ind i serveren for at min hjemmeside køre optimalt, men mit udgangspunkt er typisk, hvordan kan jeg optimere selve løsningen, så den kan klare den lille server som den nu ligger på. og som rigtig mange hjemmesider i dag ligger på. det betyder ikke at det ikke kan være nødvendigt med større og dyrere servere, det er bare ikke der mit udgangspunkt er. Man kan jo lige så godt optimere løsningen, så den selv på små servere sparker r.., og så kan man altid flytte den over på større servere hvor den så vil sparke endnu mere r.. hvis der bliver brug for det.

MVH Kim

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 21:22:01 GMT

Kim Tetzlaff - KTJ-Media.dk:

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
så det er og bliver PHP der er mindst belastende for performance

Jeg må indrømme at jeg har meget svært ved at tro at PHP generelt skulle være hurtigere end .htaccess til at lave en redirect. Ved at lave en i .htaccess bliver redirect opfanget af Apache inden PHP filen bliver fortolket af serveren, hvilket i teorien burde være hurtigere.

Edit: En kilde her med samme konklusion.

Tror du læser det jeg skriver forkert. Jeg siger ikke at PHP er hurtigere end htaccess til at lave redirects, Det har jeg aldrig sagt på noget tidspunkt og skriver det heller ikkenogen steder.

Men jeg siger at de redirects som laves fx med rewrite i htaccess, belaster serveren unødvendigt meget, og at det er bedre for serveren og brugerne, og ja den generelle hastighed på siden, at man flytter disse redirects over i vHost hvor det kun læses en gang eller PHP hvor det kun læses 1 gang.

Den store forskel ligger i at de fleste brugere på en webserver bør være reelle brugere der ikke skal redirectes konstant, og disse vil med redirects i en htaccess belaste serveren, og ja som jeg skriver i indlægget, så læses linjerne altså også selvom brugeren ikke har brug for at læse dem. Men var de flyttet over i PHP, ville de reelt ikke blive læst, og simple test (ifs) på om en url er en url der skal redirectes, går betydeligt hurtigere, og belaster nærmest ikke serveren (PHP er jo allerede igang på dette tidspunkt). det er testet og du kan læse mere om det ovre på http://www.e-universe.dk/htaccess-guide

hvor jeg viser at performance kommer tæt på udgangspunktet for hvad serveren kan klare lige ved den side der er testet.

Yderligere giver det også andre fordele såsom catch all, ingen tab af linkjuice mm. så der nu engang kun fordele ved at putte det over i php frem for at blive ved med at spæde til i sin htaccess.

MVH Kim

En lille tilføjelse til det du kan læse ovre på e-universe.dk.

Jeg prøvede dette med 300 redirects (via rewrites) på en normal hjemmeside. Jeg testede forsiden på hjemmesiden med og uden htaccess, først uden for at se hvad hjemmesiden kunne klare , og derefter med htaccess og de 300 redirects (3 gange langsommere end udgangspunktet). Dernæst flyttede jeg de 300 redirects over i php, omskrev dem selvfølgelig så de testede om det var den rette url, ca 1200 linjer PHP blev lavet i denne forbindelse. Jeg testede så forsiden igen, og performance kom næsten helt op til udgangspunktet (10 forespørgslers forskel). altså det samme som hvis ikke der havde været nogen htaccess fil på serveren.

Og dette er som sagt fordi htaccess læses linje for linje ved hvert forespørgsel til en fil, uanset om du har brug for det eller ikke.

MVH Kim Tetzlaff

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 20:45:09 GMT

Mads Mogenshøj:

Kim Tetzlaff - KTJ-Media.dk:
så det er og bliver PHP der er mindst belastende for performance

Jeg må indrømme at jeg har meget svært ved at tro at PHP generelt skulle være hurtigere end .htaccess til at lave en redirect. Ved at lave en i .htaccess bliver redirect opfanget af Apache inden PHP filen bliver fortolket af serveren, hvilket i teorien burde være hurtigere.

Edit: En kilde her med samme konklusion.

Tror du læser det jeg skriver forkert. Jeg siger ikke at PHP er hurtigere end htaccess til at lave redirects, Det har jeg aldrig sagt på noget tidspunkt og skriver det heller ikkenogen steder.

Men jeg siger at de redirects som laves fx med rewrite i htaccess, belaster serveren unødvendigt meget, og at det er bedre for serveren og brugerne, og ja den generelle hastighed på siden, at man flytter disse redirects over i vHost hvor det kun læses en gang eller PHP hvor det kun læses 1 gang.

Den store forskel ligger i at de fleste brugere på en webserver bør være reelle brugere der ikke skal redirectes konstant, og disse vil med redirects i en htaccess belaste serveren, og ja som jeg skriver i indlægget, så læses linjerne altså også selvom brugeren ikke har brug for at læse dem. Men var de flyttet over i PHP, ville de reelt ikke blive læst, og simple test (ifs) på om en url er en url der skal redirectes, går betydeligt hurtigere, og belaster nærmest ikke serveren (PHP er jo allerede igang på dette tidspunkt). det er testet og du kan læse mere om det ovre på http://www.e-universe.dk/htaccess-guide

hvor jeg viser at performance kommer tæt på udgangspunktet for hvad serveren kan klare lige ved den side der er testet.

Yderligere giver det også andre fordele såsom catch all, ingen tab af linkjuice mm. så der nu engang kun fordele ved at putte det over i php frem for at blive ved med at spæde til i sin htaccess.

MVH Kim

Svar: Hastighedsoptimering på dit website

Mads — Thu, 22 Aug 2013 20:02:58 GMT

Kim Tetzlaff - KTJ-Media.dk:
så det er og bliver PHP der er mindst belastende for performance

Jeg må indrømme at jeg har meget svært ved at tro at PHP generelt skulle være hurtigere end .htaccess til at lave en redirect. Ved at lave en i .htaccess bliver redirect opfanget af Apache inden PHP filen bliver fortolket af serveren, hvilket i teorien burde være hurtigere.

Edit: En kilde her med samme konklusion.

Svar: Hastighedsoptimering på dit website

Rasmus L. Knabe — Thu, 22 Aug 2013 17:59:26 GMT

Jeg har ikke særlig meget erfaring med at konfigurere eller optimere serverside, men har til gengæld arbejdet en del på optimering af alt hvad der sker i klienten, efter ySlows anbefainger, og her er det min erfaring at en sådan optimering vi føre til mærkbar perfomance forbedringer på de fleste hjemmesider.

Kunne dog være fedt at få styr på backend delen også... På større dynamiske webapps kan det jo være hel essentielt for brugeroplevelsen :)

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 17:49:40 GMT

Powerhosting:

Kim Tetzlaff - KTJ-Media.dk:
Men det kan jeg da lige teste på samme fil jeg allerede har testet på i indlægget.

Det er svært at teste realistisk da serveren, i dit tilfælde, vil cache indholdet af .htaccess-filen i RAM.

Permanent caching af .htacess vil nok næppe være en realitet in the wild på en travl produktions-server - men nem at opnå i et syntetisk benchmark.

Af samme årsag vil forskellen også være tydligere på et system hvor der kæmpes om disk I/O

Kim Tetzlaff - KTJ-Media.dk:
Så det du siger er, uanset om jeg tester på filen og serveren i indlægget eller på en server hvor der rent faktisk er flere tusinde brugere på. Så vil forskellen ikke være synlig i en ab test?
Det virker lidt usandsynligt at man ikke skulle kunne teste det, især når i lægger op til at det har meget at sige.

Så har jeg testet det, og det giver rent faktisk et lidt højere gennemsnit. +8,78% i forhold til udgangspunktet. hvilket vil sige lige under 500 forespørgelser mere. Så den er da værd at tage med hvis man da har muligheden for vHost. De fleste vil dog ikke kunne drage nytte af det, da de har almindelige webhoteller.

MVH Kim

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 16:53:03 GMT

Så det du siger er, uanset om jeg tester på filen og serveren i indlægget eller på en server hvor der rent faktisk er flere tusinde brugere på. Så vil forskellen ikke være synlig i en ab test?
Det virker lidt usandsynligt at man ikke skulle kunne teste det, især når i lægger op til at det har meget at sige.

Mvh kim.

Svar: Hastighedsoptimering på dit website

Powerhosting — Thu, 22 Aug 2013 16:02:52 GMT

Kim Tetzlaff - KTJ-Media.dk:
Men det kan jeg da lige teste på samme fil jeg allerede har testet på i indlægget.

Det er svært at teste realistisk da serveren, i dit tilfælde, vil cache indholdet af .htaccess-filen i RAM.

Permanent caching af .htacess vil nok næppe være en realitet in the wild på en travl produktions-server - men nem at opnå i et syntetisk benchmark.

Af samme årsag vil forskellen også være tydligere på et system hvor der kæmpes om disk I/O

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 22 Aug 2013 15:53:41 GMT

Powerhosting:

Kim Tetzlaff - KTJ-Media.dk:
Men ud over det behøver man nu ikke deaktivere brugen af htaccess, tvivler på at det batter ret meget at deaktivere det, men det kan være jeg tager fejl.

Det gør du.

Med en Allowoverride aktiveret i en Vhost, vil apache altid kigge i current working dir og alle niveauer op til doc_root for at bestemme om en .htaccess-fil skal overvejes inden respons.

Derfor er det ikke nok blot at fjerne .htaccess-filen, sæt Allowoverride None i vhosten istedet og inkludér evt. regler der.
-Præcis som Mikkel (og dokumentationen) nævner.

Jep, men som jeg også skriver er det bare ikke realistisk for langt størstedelen af brugernes hjemmesider, da de fleste ligger på helt almindelige webhoteller. men igen, jeg tvivler stadig på hvor meget indflydelse det har at deaktivere det fuldstændigt.

Men det kan jeg da lige teste på samme fil jeg allerede har testet på i indlægget.

MVH Kim

Svar: Hastighedsoptimering på dit website

Powerhosting — Thu, 22 Aug 2013 15:42:27 GMT

Kim Tetzlaff - KTJ-Media.dk:
Men ud over det behøver man nu ikke deaktivere brugen af htaccess, tvivler på at det batter ret meget at deaktivere det, men det kan være jeg tager fejl.

Det gør du.

Med en Allowoverride aktiveret i en Vhost, vil apache altid kigge i current working dir og alle niveauer op til doc_root for at bestemme om en .htaccess-fil skal overvejes inden respons.

Derfor er det ikke nok blot at fjerne .htaccess-filen, sæt Allowoverride None i vhosten istedet og inkludér evt. regler der.
-Præcis som Mikkel (og dokumentationen) nævner.

Svar: Hastighedsoptimering på dit website

Kim Tetzlaff - Kim Tetzlaff ApS — Wed, 21 Aug 2013 12:42:04 GMT

Mikkel Mikjær Christensen:

Det er ikke nok bare at fjerne .htaccess filen, de skal deaktiveres serverside.

Derudover skal du flytte funktionerne over i webserveren config filer, ikke i php. Webserveren er meget hurtigere til at lave redirects end PHP er :-)

bare ikke en holdbar løsning for langt de fleste hjemmesider. de fleste har ikke engang adgang til vHost, så det er og bliver PHP der er mindst belastende for performance.

Men ud over det behøver man nu ikke deaktivere brugen af htaccess, tvivler på at det batter ret meget at deaktivere det, men det kan være jeg tager fejl.