What is the best practice for aggregating and compressing CSS files on a responsive site. When I select the Aggregate and Compress CSS files option in Drupal 7 under performance and look at the site on a mobile device it is using the style sheet from the main site not the specified one for that device. I am using AdaptiveTheme.
Your site performance wouldn't be slow down. It is somewhere other things rather than CSS minification. Online YUI Compressor minifies properly and rather than slowed down your page load speed, it enhances page speed.
Well according to the documentation
You need to turn on Production mode
Any additional changes you make you need to resave the theme (so that it can be rendered properly again)
All responsive themes are placed into one complete file
Also highly advisabled to install AT Tools as it has additional features that help you out with regards to this
Responsive Styles - Production mode
When in production mode all the responsive stylesheets are aggregated into one file and use embedded #media queries. AT Core will automatically aggregate the CSS from each of the development mode stylesheets and wrap it in the right media query. This reduces the number of HTTP requests from 5 to 1.
This file is always called: ThemeName.responsive.styles.css
By default will find this file at: ~/[public files]/adaptivetheme/[ThemeName]/ThemeName.responsive.styles.css
However you can choose where to save AT's generated files, for example you can save them directly to your theme or enter a custom directory path - see File Generation System.
NOTE: please see the section below titled "Relative Paths in Responsive Styles".
Ref: Referencing AdaptiveThemes documentation
Related
I'm building a static website hosting and would like to generate default web pages for my users and would like to use Hugo for this. Question is, what would be the best way to dynamically generate web pages for multiple users? This is my thought so far:
User fills up form for their website content e.g., photos, title, product descriptions, etc.
Pass to backend (I'm using Perl's Mojolicious) and create markdown files based on the provided information and save them in a designated folder created for this user
Run Hugo to build using those md files and move the public folder to user's root directory
This doesn't look right to me as there will be contention of multiple users to run Hugo and I'm thinking that it is much easier if I can just create the html files directly from backend instead of creating md files and then run Hugo to create the html files. Is there any better and smarter way?
If I am not mistaken, it seems you want to make a WordPress portal alike or something similar, going from Markdown plus theme down to HTMl/CSS/JavaScript content. The end-users edit the content in Markdown, choose the theme and the rest will be taken care of.
IMHO, there might be two ways:
(1) Using Hugo at the back-end and taking care of the destination folders and generated artifacts as well as mapping generated links to the front-end corresponding to your particular end-user's hosting. You can create a Hugo wrapper in which the input will be fed to Hugo and the generated pages will be in the public folder. In this way, you have to rely on an external tool (read Hugo) and wish for a long-term support version like many other systems (e.g. Ubuntu, Java, Windows).
(2) Creating a similar generator like Hugo or another (c.f. StaticGen for more generators on different languages). You may need the core of a Markdown based static site generator, for instance, a Markdown parser, link translators and generators, etc. With extra effort, you might have more control of every smaller component/library that you use, can configure the generated artifacts, their destinations, etc.
A side note: Markdown is a not-so-bad choice for content. Even WordPress have offered support for Markdown. Nonetheless, Markdown itself is not standardized but rather de facto. There are so many flavours. You might want to look up to or stick with a good one, for example, CommonMark.
I found the first web page loading time for CN1 Javascript Built taking too long, need about 2 minutes.
I attached the Chrome's network loading screen shot, found the classes.js is the most heavy page, possible to zip it?
Second, there is 2 theme files that downloaded sequentially, is it possible for them to load at the same time?
Kindly advice.
Normally I would answer that you can look at the performance section of the developer guide but the relevant sections there relate to reducing the theme.res size which seems pretty small in your case.
The largest portion in your code is the class files so I'm guessing that the best way to reduce them is to further reduce dependencies so the obfucator can remove more dead code. Keep in mind that the classes.js file is cached and can be deployed via CDN's such as cloudflair to improve download speeds. It can be served in a gzipped form as well which is a part of the CDN repertoire.
I'm developing an app that'll show a catalog of hundreds of products, each with a photo. In thinking how to deploy those images in Codename One, I found two options:
1) I can insert them in the resources file and fetch them with fetchResourceFile().getImage(). The downside is that, because they're so many, and because there's no folder system in the resources file gui, it'll make it hard to find icons and other images in the mix.
2) Copy them to the root folder and fetch them with Image.createImage(). I find this preferable because I can leverage the OS's applications to find/replace/rename them directly; but like before, it'll mix them up with other files that share the same requirement, like the resources file, xml files and others.
My question is, is there a better way of packaging them in a way that will keep them separate from other resources and keep things organized?
You can't rename or change anything about images that you place in the SRC directory since they will be packaged in the jar or .app bundle both of which are unmodifiable. There is a platform dependent size limit for bundles so if your app grows too much it just won't install in the various OS's.
The best way is to include a subset of the images in the resource file and then as the app is launched start downloading the rest in the background to avoid a big application overhead.
I'm a SP developer and also skilled in webdesign. My current task is to implement a responsive design along with a branding in a SP 2013 environment
Now I am in the situation to choose which one i would use to implement a responsive design in SP2013 and so I collected pro's and con's foreach technology.
What do you think ? Are there important aspects I'm missing ? Are there other solutions which are better suited for realizing this ? Any input is welcome ! :)
Device Channels
Yes I'm talking about Device Channels even when they are not mentioned in the question, because they can deliver the best performance and optimizability for the enduser and the client - in my opinion :)
Pro
individual designed HTML/CSS and JS foreach device
-- no need for hiding or removing incompatible elements
-- faster because you just load things you really need
-- faster because you will likely have less CSS/JS and HTML
-- faster because you can use optimized code foreach device
-- better you can better point out which channel has errors and changes dont affect the other channels
Con
individual designed HTML/CSS and JS foreach device
-- you have to append changes to each masterpage
-- more work to accomplish the same result (in general)
-- redundancy
bound to User Agent Strings
growing diversity of devices
-- may equals growing diversity of masterpages >> work
These are not all but my main points. Klick here to start your own research.
Bootstrap
Pro
mighty, easy to use framework
-- a lot of documentation
-- fast results
-- if you like it - all the Bootstrap styles
there are already projects using it so you may dont have to build it from scratch
-- http://responsivesharepoint.codeplex.com/
Con
Bootstrap is a huge framework and has 8000+ lines of code in the unminified CSS and JS files
-- 2 requests extra for ~ 130kb & 30kb
-- a lot of styles and script for your browser to handle
Bootstrap is not build for use in SharePoint
-- it's overwriting SharePoint styles which makes some features (ComposedLooks for ex.) less valuable
-- there are a lot of custom CSS needed to make it work seamless with SharePoint
SharePoint has it's own weird way to do things and that interferes with BootStrap
-- tons of CSS
-- tons of JS
-- tons of HTML Attributes
These are not all but my main points. Klick here to start your own research.
Media Queries
Pro
only necessary CSS
no JS if you dont wan't to
you can create your own layout
with response.js even in IE6 working
you can easily separate which features should be available in certain screen sizes
Con
several sets of CSS depending on the number of Breakpoints
every feature needs to be developed by yourself
it's not easy to write generic code that can process every SP2013 Page
-- it depends on the complexity of the content shown. I write about 150 lines of CSS that created a mobile view for publishing pages that contained the navigation and content, but no features like editing, etc.
-- if the client's want every feature on his smartphone, there is a hell lot of work and testing needed. (Plus who the hell wants to do that on their phone?)
Conclusion
I'm not sure yet (and it would be awesome to get a lot of feedback to my results), but i tend to use Media Queries. Why ? Well SharePoint has it's own way to handle desktop users and i wouldn't customize that build in functionality if not explicit ordered. On the other hand SharePoint doesn't provide a real UI for smartphones. I don't want to use BootStrap because it contains a lot of styling which will produce problems in branded environments. And I won't use Device Channels because of the downsides.
Use Botostrap. I work at a University (http://www.cmich.edu) and our entire website (internal and external) is built in SharePoint 2013 using this Framework, and I was the lead on its implementation. If you haven't used Bootstrap at all, it takes a little getting used to, especially in the SharePoint environment, but as far as I'm concerned, responsive design is the only way to go that's going to produce the best results. Check our University site out, if you have questions, let me know.
The home page for DotNetNuke 5.2 is around 252.6KB. It uses 15 JavaScripts and 8 CSS files. The number of resources DotNetNuke uses seems excessive to me. I am looking for best practices creating DotNetNuke skins that limit the JavaScript and CSS resources.
You can use the Unload CSS Skin Object to remove links to some of the CSS files loaded by the framework (like Default.css, portal.css & any module-specific CSS files). You can then move all of those styles into the skin (or portal stylesheet, whichever is your preference), so that there's only one stylesheet that gets loaded.
I don't know of any solutions for combining JavaScript resources or reducing the number of scripts that DNN requires.
From 6.1 onward, the Client Resource Management component is the solution for this. It automatically combines all your files, cleaning them up, removing comments, and minifying if desired.
http://www.dotnetnuke.com/Resources/Wiki/Page/Client-Resource-Management-API.aspx
It takes a little getting used to, but the control is quite nice. You can decide which order they'll go in, you can group the files in bunches if you don't want one big single file - maybe you want certain bunches of scripts together but not all.
One thing to remember is that when you're doing development (as noted by the comment below, which I've since edited this post), you should always use debug=true in the web.config, otherwise if you are using Resource Mgmt and change your source files, you'll constantly need to regenerate the combined files by going into Site Settings, Client Resource Management, and increment the version. It's kind of a protection to keep anything from altering your clients' browser caches without intent (that's the message box that pops up to let you know when you do it). I'm sure if you have a zillion users this might make a difference.
Part of that is just the dynamic nature of DNN - there are some good resources that R2i has published about combining javascript and CSS
One concrete suggestion is to combine all your skin and contianer css in one file and if you have full control of the site to combine the css from the modules you use into that same file.
I know with the addition of the Telerik controls there is some abilities to combine resource files
Another thing that helps is to combine graphics into a single file and use CSS (the sprite technique) to cut down number of files loaded and calls to the sever
Like it was stated above, it's the nature of the beast. Each module will have at least 1 css file included. You can check out PageBlaster from snapsis.com, I believe it will do what you are looking for.