Veel CSS, wat is handig
Maar als je een css bestand zo inlaadt:
<link rel="stylesheet" type="text/css" href="/css/css.php?file=main-form" />
Wordt het door de browser dan wel gecachet? Ziet de browser dit wel als een css bestand? Met andere woorden, als diezelfde link op pagina 2 wordt aangeroepen, haalt de browser 'm dan uit z'n eigen cache?
* Begrijp ik goed dat die .htaccess manier niet altijd gaat werken? Die mod-headers module is namelijk een extension, waarover ik hetvolgende terugvind: A module with "Extension" status is not normally compiled and loaded into the server. To enable the module and its functionality, you may need to change the server build configuration files and re-compile Apache.
Met andere woorden, dit zal dus niet altijd gaan werken. Dan zou je dus zeggen dat manier 2 (aanroepen van css / javascript) via een php bestand beter is, is dat een juiste conclusie? Maar dan vraag ik me dus nog steeds af of de browser dit goed cachet.
Ozzie PHP op 01/08/2011 11:50:59:
Thanks voor de link en de info!
Maar als je een css bestand zo inlaadt:
<link rel="stylesheet" type="text/css" href="/css/css.php?file=main-form" />
Wordt het door de browser dan wel gecachet? Ziet de browser dit wel als een css bestand? Met andere woorden, als diezelfde link op pagina 2 wordt aangeroepen, haalt de browser 'm dan uit z'n eigen cache?
Maar als je een css bestand zo inlaadt:
<link rel="stylesheet" type="text/css" href="/css/css.php?file=main-form" />
Wordt het door de browser dan wel gecachet? Ziet de browser dit wel als een css bestand? Met andere woorden, als diezelfde link op pagina 2 wordt aangeroepen, haalt de browser 'm dan uit z'n eigen cache?
Ja, want het PHP bestand geeft aan dat het danwel CSS danwel javascript is:
Geen probleem dus.
Ozzie PHP op 01/08/2011 11:50:59:
* Begrijp ik goed dat die .htaccess manier niet altijd gaat werken? Die mod-headers module is namelijk een extension, waarover ik hetvolgende terugvind: A module with "Extension" status is not normally compiled and loaded into the server. To enable the module and its functionality, you may need to change the server build configuration files and re-compile Apache.
Met andere woorden, dit zal dus niet altijd gaan werken. Dan zou je dus zeggen dat manier 2 (aanroepen van css / javascript) via een php bestand beter is, is dat een juiste conclusie? Maar dan vraag ik me dus nog steeds af of de browser dit goed cachet.
Met andere woorden, dit zal dus niet altijd gaan werken. Dan zou je dus zeggen dat manier 2 (aanroepen van css / javascript) via een php bestand beter is, is dat een juiste conclusie? Maar dan vraag ik me dus nog steeds af of de browser dit goed cachet.
Als bij de server bijvoorbeeld gzip uitstaat dan werkt het uberhaupt niet, welke manier je ook gebruikt. Je geeft namelijk enkel aan in de header (via htaccess of PHP met header()) dat je gzip wilt toepassen. Het is de server die het uiteindelijk voor zijn rekening neemt.
Het voordeel van het combine script is dat hij rekening houdt of een bepaalde browser bepaalde features ondersteund. Hij kijkt ook welke vormen van encoding ondersteund worden door de server. Wordt gzip ondersteund dan is het gzip, zoniet dan wordt gekeken of 'deflate' encoding ondersteund wordt:
Code (php)
Het script ondersteund ook caching (op de server) voor een verdere optimalisering van de uitvoersnelheid. Het stuurt indien nodig daarnaast de 304 header om bij de browser aan te geven dat het zijn lokale cache kan gebruiken. Het kijkt vantevoren daarvoor of het bestand is aangepast zodat je niet met versienummers hoeft te werken om wijzigingen effectief te maken (zelfs als het een future expiry date heeft).
Kortom: ideaal dus.
Maar deze manier (met het script) is volgens mij sowieso wel beter, omdat die apache module standaard niet aanwezig is. En met dit script heb je daar geen last van... nice :-)
Toevoeging op 01/08/2011 12:21:56:
Wat gebeurt er trouwens als een bepaalde browser de encoding feautures niet ondersteunt? Gaat het dan mis?
Volgens mij is het redelijk veilig om vanaf IE7 te gzippen.
Kunnen alle moderne browsers overigens wel gecomprimeerde data ontvangen?
Is het trouwens geen beter idee om in plaats van welke browser wel mag en welke niet (zoals ze dat in het script doen) gebruik te maken van deze functie:
http://php.net/manual/en/function.ob-gzhandler.php
Of gaat dat niet werken?
Ozzie PHP op 01/08/2011 15:08:29:
Begrijp ik goed dat dat script dan nooit iets zipt voor IE? Of gaat het alleen om versies < IE7?
O dat dacht ik eerst maar nu zie ik dat hij nog specifiek de versie controleert. Dus het gaat alleen om versies < IE7. Download anders het bestand even, het zit heel eenvoudig in elkaar.
Ozzie PHP op 01/08/2011 15:08:29:
Kunnen alle moderne browsers overigens wel gecomprimeerde data ontvangen?
In principe wel, maar het is altijd goed om te controleren of het ondersteund wordt.
Ozzie PHP op 01/08/2011 15:08:29:
Is het trouwens geen beter idee om in plaats van welke browser wel mag en welke niet (zoals ze dat in het script doen) gebruik te maken van deze functie:
http://php.net/manual/en/function.ob-gzhandler.php
Of gaat dat niet werken?
http://php.net/manual/en/function.ob-gzhandler.php
Of gaat dat niet werken?
Dat doen ze in het script dus niet (download het maar eens). De situatie is vrij ideaal: browsers geven aan welke vormen van encoding ze ondersteunen. Het script kijkt gewoon wat de browser zegt te ondersteunen en geeft indien nodig de voorkeur aan gzip. Alleen geven een aantal versies van IE aan dat ze gzip/deflate ondersteunen, terwijl daar bugs kunnen optreden. Dus dit script filtert deze eruit. Ideaal dus. Elke browser krijgt het optimale bestand aangeboden, of je er nu met Chrome, IE6, IE7, Firefox of zelfs Netscape 3.0 heen gaat.
Gewijzigd op 01/08/2011 15:46:05 door The Force
Als ik de omschrijving lees van ob-gzhandler dan staat er dit:
Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return its output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages
Met andere woorden deze functie lijkt dit allemaal al te regelen, dus vraag ik me af of het dan niet beter is om deze functie te gebruiken. Of zie ik het verkeerd nu?
Ozzie PHP op 01/08/2011 16:19:39:
Dankjewel voor de uitleg. Ik had het bestand al gedownload en bekeken, maar ik bedoelde dus... kun je in plaats van de manier waarop ze het in dit script doen, niet beter een standaard PHP functie gebruiken die daar voor gemaakt is.
Als ik de omschrijving lees van ob-gzhandler dan staat er dit:
Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return its output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages
Met andere woorden deze functie lijkt dit allemaal al te regelen, dus vraag ik me af of het dan niet beter is om deze functie te gebruiken. Of zie ik het verkeerd nu?
Als ik de omschrijving lees van ob-gzhandler dan staat er dit:
Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return its output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages
Met andere woorden deze functie lijkt dit allemaal al te regelen, dus vraag ik me af of het dan niet beter is om deze functie te gebruiken. Of zie ik het verkeerd nu?
Ja dat zie je verkeerd ;). Deze functie kijkt enkel naar wat de browser aangeeft te kunnen. Het filtert dus niet de versies van IE eruit die buggy zijn. Daarnaast moet je dan output buffering gebruiken.
De man die dit script gemaakt heeft heeft zich grondig verdiept in het hele gebeuren met cache (server en browser), encoding, eventuele problemen die browsers daar mee hebben en dergelijke onderwerpen. Jij kan zijn expertise gebruiken om betere websites te bouwen. Dat is het mooie met dergelijke opensource projecten. Als je alles zelf wilt doen of wil verbeteren dan ben je enkel bezig het jezelf lastig te maken. Hetzelfde geld met bijvoorbeeld frameworks. Die zijn ontwikkeld door een team van mensen die enkel als doel hebben een framework te maken die zo goed mogelijk werkt. Die kan je vervolgens geheel gratis gebruiken. Dus als tip voor de ontwikkeling van je CMS: omarm het opensource gebeuren. Een goede programmeur combineert de juiste dingen met elkaar zodat hij tijd heeft om innovatief te zijn.
Oké dat was een beetje offtopic.
Gewijzigd op 01/08/2011 17:38:32 door Ozzie PHP