Jump to content

This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!

FireBrick Custom CSS: Difference between revisions

← Older editNewer edit →
Content deleted Content added
CecilWard (talk | contribs)
252 edits
m →Using CSS @import: wording clarified
CecilWard (talk | contribs)
252 edits
→Performance degradation with external websites: Minor rewording in places; additional guidance regarding availability and caching lifetimes.
Tags: Mobile edit Mobile web edit
Line 99: Line 99:
== Performance degradation with external websites ==
== Performance degradation with external websites ==


If your custom CSS is located on an external web server, try to ensure that the web server of your choice is well-configured and has excellent availability in order to avoid the possibility of introducing unpleasant delays in the responsiveness of the Firebrick's web UI. (Perhaps consider testing what effect unavailability has on the behaviour of your Firebrick's UI - your Firebrick firmware release could exhibit a delay in response before a timeout if the link to the web server is broken, and as regards visual appearance if the custom CSS can not be fetched, then it could use previously cached CSS or defaults.)
⚫
To avoid introducing delays in the responsiveness of the Firebrick's web UI, choose a well-configured web server. If you are the web master of your chosen server, review the cache-friendliness settings. (Topics: 'cacheability', 'cache-control', 'ETags'.) Getting cacheability settings wrong could in theory at least mean that your Firebrick might possibly be compelled to refetch the custom CSS repeatedly. A number of excellent web-based tools are available that will check and diagnose cacheability issues of a website. If you are using the Apache web server, see the <code>https.conf</code> or <code>.htaccess</code> documentation relating to cache control options. Set long timeouts for cacheability of all CSS files and make sure that the Firebrick is not forbidden from caching the downloaded CSS. Using inappropriate short cache lifetimes, even zero, or disabling caching altogether is a fairly common and heinous practice.

⚫
If you are the web master of your chosen server, review the web server’s cache-friendliness settings. (Topics: 'cacheability', 'cache-control', 'ETags'.) Getting cacheability settings wrong could in theory at least mean that your Firebrick might possibly be compelled to refetch the custom CSS repeatedly. A number of excellent web-based tools are available to check and diagnose cacheability issues of a website. If you are using the Apache web server, see the <code>https.conf</code> or <code>.htaccess</code> documentation relating to cache control options. Make sure that user agents are not forbidden from caching downloaded CSS files, and set long cache validity times for all CSS files. Using inappropriate short cache lifetimes, even zero, or disabling caching altogether is a fairly common and heinous practice. Cache validity times should be set specifically according to each kind of file extension (<code>.css</code>) and MIME type requested (<code>text/css</code>), and should be as long as possible. The maximum validity time value is the maximum delay you feel is acceptable before a Firebrick shows the effects of a change when you change the css file on the web server.


== Security implications ==
== Security implications ==
Retrieved from "http://support.aa.net.uk/FireBrick_Custom_CSS"