Hi everybody,
reducing requests is one of the first (and in most times) very powerful
way to reduce the first loading-time. At one of our last jobs, that
saved 1 second (!).
But: As long as i see, all CSS-files are already rendered through a
smarty-function. Right? Why not having as many css-files as needed, and
collect them, if shop runs in productive-mode, into one file. That could
then be minimized and chached - et voilá.
I planned that as a module (but didn't sartet yet), but would be happy,
if you could implement that.
Regards
Joscha Krug
---
//-----
marmalade.de
Joscha Krug
Leibnizstraße 25
39104 Magdeburg
tel.: +49 (0) 391 559 22 104
fax: +49 (0) 391 559 22 106
www.marmalade.de
[email protected]
On Thu, 16 Jun 2011 20:08:14 +0200, Frank Zunderer wrote:
Hi Dainius,
first i want to say i agree with most that was said before,
especially about the sheer amount of css. I think the main goal is
flexibility and clarity. So to me the idea of having separate files
for different elements sounds good. For example, a javascript driven
Element should have its own js and also css, like the superfish menu,
so if you decide to use your own solution it can easily be removed.
Right now it's all buried in elements.css and gui.js. Also the files
should be split by groups of pages, like one for detail and one for
checkout. This would make it easier to take some pages/elements and
use them in a different context or different layouts, or to remove
certain elements. I also like the idea of loading these files during
runtime, as it would make even clearer which files are used by a
certain page.
About one file vs many files performance: as css-files are only
requested once and then cached, it sounds good to distribute this
task
among pages to reduce the loading size of the start page. If files
are
compiled into one, this file would have to contain everything again
in
order to be cached. So I agree that the performance gain of not
loading unnecessary elements would outweigh the loss due to having
several files. Also it would be easier to deliver minimized layouts
that do not make use of many of the possible elements, like a start
page that only contains a menu and a single slider, and in fact only
needs a few lines of css.
Regards, Grüße aus München,
Frank Zunderer
VON: [email protected]
[mailto:[email protected]] IM AUFTRAG VON
Dainius Bigelis
GESENDET: Donnerstag, 16. Juni 2011 15:44
AN: [email protected]
BETREFF: [oxid-dev-general] Split CSS files to smaller ones
Hi,
Currently we are working to improve the code and structure of CSS
files.
Just we are not sure about one idea, that we want to implement, so we
would like to ask you about your opinion regarding that.
Currently (in eShop 4.5.0 verson) we have ~10 css files, where one of
these (elements) have ~4000 lines of code.
Making any change in that and maintain it became really difficult for
developers.
So we thought that would be good to split this file to the smaller
ones (according the type of elements) and change the structure of
other files.
As a result of that would be 3-5 files according to the type of page
(details page, list, checkout, main page…). These files would do
nothing, just include the smaller css files for elements, which are
really used used in this particular page.
The advantage of such structure:
- Much more easy development/changes and maintenance;
- Scalability of pages, as elements which are not needed in this page
would not be loaded (i.e. elements used only in checkout would not be
loaded in details page).
Disadvantage:
- There are some ideas, that loading more files may reduce the
performance. But we think that such effect may be noticed only during
the first load of the page and then it is cached. But considering
what
we have now - it parses all the long (4k lines) file even of some big
part of this is not needed in the page.
Also, one of solutions to work with smaller files and deliver one
file as result - is to use the dedicated tools for compiling the css
files into one during deployment.
So - please tell your ideas about this concept or any arguments for
one or other solution.
Best regards,
Dainius Bigelis
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
