i have a website and i have multiple css style sheet for print, tv, screen, handheld etc...
i want to know which one of these method is better to use (performance, usability, etc...)
<link href="all.css" media="all" type="text/css" />
<link href="handheld.css" media="handheld" type="text/css" />
<link href="tv_print.css" media="tv, print" type="text/css" />
or
<style type="text/css">
#import url("all.css") all;
#import url("handheld.css") handheld;
#import url("tv_print.css") tv, print;
</style>
thank you
The first method (link) is the best.
The main reason is that there is a bug in IE 6,7 and 8 (not sure about 9 or higher) means that when you use #import in conjunction with link the files are loading in series rather than in parallel. This can slow things down a lot when using more than one style sheet.
Just using #import downloads in series, but the order isn't guaranteed, meaning that if there is a reset for instance, that may or may not be applied first.
This article has a good summary: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
Related
i'm trying to optimize this website: electronicsportsitalia-it and when i try to analyze it on Google PageSpeed the platforms says that there is a google font blocking the page rendering:
https://fonts.googleapis.com/css?family=Lato:300,400,700
The font firstly was loaded through php but then i inserted it directly in html code trying to load it with this code: <link rel=stylesheet id=avia-google-webfont href='//fonts.googleapis.com/css?family=Lato:300,400,700' type='text/css' media=all lazyload> -put also before the </body> tag- but it didn't worked.
So i tryed to load it with Web Font Loader and actually the website is runnging this script:
`
</script>
<script>
WebFont.load({
google: {
families: ['Lato']
}
});
</script>`
but always the same problem on PageSpeed.
Can someone help me?
You can preload any styles (including google fonts)
<link
rel="preload"
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
/>
<noscript>
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
rel="stylesheet"
type="text/css"
/>
</noscript>
You can read more on web.dev
UPDATE
Base on Lucas Vazquez comment I've also added &display=swap (which fixes this issue "Ensure text remains visible during webfont load")
You question boils down how to include less critical CSS asynchronously. I recommend to read this article.
Its similar to Claudiu's answer however, it is recommended in the article not to use preload, because of this:
First, browser support for preload is still not great, so a polyfill (such as the one loadCSS provides) is necessary if you want to rely on it to fetch and apply a stylesheet across browsers. More importantly though, preload fetches files very early, at the highest priority, potentially deprioritizing other important downloads, and that may be higher priority than you actually need for non-critical CSS
Here is the alternative:
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
media="print"
onload="this.media='all'"
/>
<noscript>
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
rel="stylesheet"
type="text/css"
/>
</noscript>
This is how it works. The attribute media=print will skip the css on page rendering. Once the page has loaded, it will load the print css. The onload JS event changes the media to all, now the font will be loaded and change the page rendering. Most importantly, the font will no longer render-block your page.
For the edge case, that a user has js disabled, the "noscript" tag will load the font directly.
You can take advantage of the onload attribute like this -
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:400,600&display=swap"
rel="stylesheet"
type="text/css"
media="print"
onload="this.media='all'"
/>
Set the media attribute to print at first, but change it to all when the download callback fires.
I noticed that Laravel added this tag to its html head output recently:
<link rel="preconnect" href="https://fonts.gstatic.com">
I copied it and added it before my font request, i.e:
<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Montserrat&display=swap" rel="stylesheet" id="google-fonts-css">
This simple tag took me from a Mobile Pagespeed score of 80 up to 95, but I can't be entirely sure that it was in fact the tag I have to thank for this score increase - PageSpeed is unpredicatable. I'm not sure if it's just a Chrome thing or a new standard.
In my case, I will generate my font using a font-face generator tool which is easier to use and less hassle but when I use google fonts, this is what I do.
You can use style element at the end of body, just before the closing </body> tag:
<style>
#import "//fonts.googleapis.com/css?family=Lato:300,400,700"
</style>
or you can refer to How to keep CSS from render-blocking my website?
The following font files must be loaded before this JS file: https://electronicsportsitalia.it/wp-content/plugins/google-analytics-for-wordpress/assets/js/frontend.min.js
https://fonts.gstatic.com/s/lato/v14/EsvMC5un3kjyUhB9ZEPPwg.woff2
https://fonts.gstatic.com/s/opensans/v15/DXI1ORHCpsQm3Vp6mXoaTegdm0LZdjqr5-oayXSOefg.woff2
https://fonts.googleapis.com/css?family=Lato
https://fonts.gstatic.com/s/roboto/v18/RxZJdnzeo3R5zSexge8UUVtXRa8TVwTICgirnJhmVJw.woff2
https://fonts.gstatic.com/s/lato/v14/EsvMC5un3kjyUhB9ZEPPwg.woff2
I'm rather new to this so its mostly (copy and paste) with a little YouTube and reading materials here and there.
Why have both? Please simplify you answer, don't go so technical.
<style type="text/css"> is when you want to have style rules embedded within the page.
<link rel="stylesheet" href="path/to/style.css" /> is when you have a separate stylesheet file that you want to reference in the current page - doing this means that clients don't have to download the CSS every time, which makes page-loads faster.
CSS has the #import directive, if you use <style>#import style.css;</style> then it's roughly equivalent to <link rel="stylesheet" href="style.css" /> (but with some minor differences: see Difference between #import and link in CSS ).
Method 1 (using <style type="text/css">)
Is simple way to declare CSS. But it should be used for small codes. When you want to overwrite an attribute of the main stylesheet.
Method 2 (using <link rel="stylesheet" href="path/to/style.css" />)
The first advantage of this method is that, we have a style in an external file. And that means that we can use it repeatedly. But this is not the end of the advantages. You can tell your browser to save the file in the cache. Which reduces page load time.
What is better?
In my opinion Method 2.
Using <style type="text/css"> is for CSS code in your HTML file and <link...> is for including an external CSS file.
The first case <style type="text/css"> is for including css definitions in your html file. The 2nd case puts the css definintions in style.css (or whatever file is the href). The 2nd case makes it easy to use the same css across multiple html files.
The first is used to insert css code directly in your html files, while the second is calling an external css file.
This question already has answers here:
Suggestions for debugging print stylesheets?
(13 answers)
Closed 5 years ago.
I have used (as usual) #media print rules to specify how the print of a web page should be different to the online version. This works quite well, but the test is really difficult. What I usually has to do are the following steps:
Create the different style for screen and print.
Start your page in the screen mode
Print the page e.g. to a PDF printer.
Look at the result.
Try to find the rules that behave wrong.
What I would like to do (but was not able to do it with any browser):
Create the different style for screen and print.
Start your page in the screen mode
Go into the preview print mode (e.g. for Opera, Firefox available)
Use the available tools like Firebug (Firefox) or Dragonfly (Opera) to inspect the DOM and the current styles.
Change the CSS on the fly, reload the page, and look at the result and the DOM again.
Is there any browser or combination of browser, plugin and process available to get similar results? If you have ideas how to change the organizations of the files, with the most minimal changes to get the wished result, you are welcome.
Chrome Developer Tools has this feature.
Open Chrome Developer Tools for the page you want to test.
Open the Drawer if not already open. (Press Esc.)
Open the Emulation tab.
Click Media in the left menu.
Check CSS media and select print from the select box
Source: https://developers.google.com/web/tools/chrome-devtools/iterate/device-mode/media-queries#preview-styles-for-more-media-types
The Firefox pluging called "Web Developer" ( https://addons.mozilla.org/en-US/firefox/addon/web-developer/) has a "Display CSS By Media Type" option.
Have you tried with Print Friendly Google Chrome extension.
Its a nice extension which adds a button and generates pdf of the web page on a click.
Hope that might be easier than your current process.
I have found a different solution to my problem inspired by Using Rails 3.1 assets pipeline to conditionally use certain css. Here is how it works:
Use in the main HTML file the following directives for stylesheets:
<link href="application.css" media="all" rel="stylesheet" type="text/css" />
<link href="screen.css" media="screen" rel="stylesheet" type="text/css" />
<link href="print.css" media="print" rel="stylesheet" type="text/css" />
isolate all rules in your stylesheets that are
appropriate for screen and print (Stylesheet: application.css)
appropriate only for screen (Stylesheet: screen.css)
appropriate only for print (Stylesheet: print.css)
During test of the print-out of your web page, switch the stylesheets in your main HTML file:
<link href="application.css" media="all" rel="stylesheet" type="text/css" />
<link href="screen.css" media="print" rel="stylesheet" type="text/css" />
<link href="print.css" media="screen" rel="stylesheet" type="text/css" />
Notice the switch in the second and third line for media="print|screen".
As the result, you are now able to call your main HTML file, and see how it will look if you print it out under normal conditions. All the tools you normally use (Firefox Firebug, Chrome Developer Tools, Opera DragonFly, ...) will work as normally, so you are able to check your DOM, see the boxes, change CSS on the fly and just reload your page then.
Works pretty well for me, if I will stumble over some drawbacks, I will come back and notate that as well.
If you specify your Print & Screen CSS rules in separate files, you can do this quite easily using the Chrome Developer tools. Load your page and open the Developer Tools. From the "Elements" view, edit the media="print" line so it reads media="all".
For example, if you link your style sheets like:
<link href="/static/global/css/theme.css" media="all" rel="stylesheet" type="text/css" />
<link href="/static/global/css/print.css" media="print" rel="stylesheet" type="text/css" />
Change:
<link href="/static/global/css/print.css" media="print" rel="stylesheet" type="text/css" />
to read:
<link href="/static/global/css/print.css" media="all" rel="stylesheet" type="text/css" />
You will now have the print styles applied to the copy in your browser window. You can navigate the styles and elements as you would with any other webpage.
Here is a practice that I have found helpful with styling for print when the print layout needs to be a modification of the generic styling.
Create a print style sheet that uses #media print { } to frame the print styles
Apply that style sheet last
While working on print styles, temporarily comment out the lines that frame your print styles
Use Firebug and Web Developer in you accustomed way
Uncomment the media bracketing
Something like:
/* #media print { */
#sidebar {display:none;}
/* } */
A page on my site has a link to a stylesheet for media="print".
<link rel="stylesheet" href=".../print.css" type="text/css" media="print" />
Most browsers correctly ignore this link when rendering for a screen, but IE7 includes the file and processes the style rules, rendering the page inappropriately for a screen display.
How does IE (and how do other browsers) recognize what the intended display is? Is there an HTML header (or absence of) that guides them? Can this be correctly with Javascript?
Use the #import at-rule instead to include the file only for print and bypass IE7:
<style type="text/css" media="print">
#import "print.css";
</style>
If that does not work, try the other alternatives on the media test page
i came across two type of using external style sheet in one way
<link href="CSS/div1.css" rel="stylesheet" type="text/css" />
<link href="CSS/div2.css" rel="stylesheet" type="text/css" />
<link href="CSS/div3.css" rel="stylesheet" type="text/css" />
importing all the style sheet like this
and the other one is using one stylesheet and importing other stylesheet within it
<link href="CSS/div1.css" rel="stylesheet" type="text/css" /> and inside this
#import url('../CSS/div2.css');
#import url('../CSS/div3.css');
.crazy
{
display:block;
background-color:Black;
color:White;
}
i read somewhere that the second approach is better so i built a demo and checked that one in firebug in the first case it is taking 16ms and also downloaded less byte of data but in the second approach it takes 109ms and downloaded more bytes of data so iam confused which approach is better.
the first one is the suggested one because it's fasters for the browser to render them More on Steve's site
Go with the first! Your test results are pretty clear!
Historically, #import has been used because it wasn't support by older versions of IE and Netscape, making it easy to hide more advanced CSS from those browsers. Nowadays that isn't so much of an issue, and other techniques are recommended when you need to target specific browsers with CSS.
As for your tests, whilst there are technical reasons why the second approach would be 'slower', I'd argue a simple look at Firebug can hardly be used as empirical evidence.
I always go for the first as W3C shows
http://www.w3schools.com/css/css_howto.asp