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

FireBrick Custom CSS (view source)

Revision as of 03:48, 6 September 2017

879 bytes added ,  6 September 2017
→‎Performance degradation with external websites: Minor rewording in places; additional guidance regarding availability and caching lifetimes.
m (→‎Using CSS @import: wording clarified)
(→‎Performance degradation with external websites: Minor rewording in places; additional guidance regarding availability and caching lifetimes.)
Tags: Mobile edit Mobile web edit
== 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.▼
 
▲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 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 that willto 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. SetMake longsure timeoutsthat foruser cacheabilityagents ofare allnot CSSforbidden filesfrom andcaching makedownloaded sureCSS thatfiles, theand Firebrickset islong notcache forbiddenvalidity fromtimes cachingfor theall downloadedCSS CSSfiles. 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 ==
CecilWard
252

edits

Retrieved from ‘http://support.aa.net.uk/Special:MobileDiff/12596’