Preloading same resource in 2 different HTML pages - html

I have 2 separate HTML files, one just serving the homepage and another one serving the other routes of the application.
There is a CSS file, let's say common.css, which is needed for both the HTMLs.
If I have preloaded like,
<link rel="preload" as="style" href="/css/common.css" onload="this.rel='stylesheet'" />
In home page HTML, will it still be available in HTTP cache for my other routes navigation? Or do I have to preload common.css again in second HTML file.
I am new to using resource hints..

If preload is essential for both the renderings use preload twice. If the stylesheet is already loaded in the browsercache the browser will use it. If the stylesheet for one reason or the other is flushed it will preload it again. The most important thing is that you use the same path for both the calls.
Oh, and do not forget to tell the browser to store your sheet e.g. in apache or via the meta tag.
You could try to make a few test pages and look at the behaviour of the browser cache.

Related

Why the requests in Chrome Debugger still queueing as the HTTP2 Protocol has been enabled?

As I have enabled the HTTP2 protocol of IIS, but the requests of the main javascript files were still queueing. According to the explanation of queueing by Chrome, I really don't know what cause this.
You can check at here: https://app.youjustgo.com/zh/
Queueing:
HTTP/2 means that more assets can be downloaded at once - not that they will be.
Browsers have various heuristics as to what to download and when.
For example, if an image is needed by a CSS file, then that image cannot be requested until the CSS file is downloaded and processed for example (ignoring preload). So in this case the CSS and the image will not download in parallel despite HTTP/2 allowing this.
Another issues is that <script> tags can change the content of the page, so unless it is explicitly marked as async (or defer) it is "render blocking". This means any JavaScript further down the page will not be run until the <script> tag is run. Now a browser could scan ahead and download the future scripts and just not run them until it needs to, if it wants, with the slight risk that it's a wasted download if the scripts subsequently are not actually needed. That's up to the browser and maybe Chrome decides it's not worth while to do this.
Looking at your specific site, your home page looks to be made up of basically only script tags. You could investigate the use of async or defer to allow more downloads to happen in parallel, but if you want the real performance improvement, you probably should go back to the basics of coding HTML, with CSS, and then enhancing it with JavaScript, rather than coding it all with JavaScript.
I'm also not sure of what the point of your preloading of your CSS is?
<link rel='preload' href='https://api.tiles.mapbox.com/mapbox-gl-js/v0.37.0/mapbox-gl.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel='preload' href='https://api.mapbox.com/mapbox-gl-js/plugins/mapbox-gl-directions/v3.0.2/mapbox-gl-directions.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="https://npmcdn.com/angular2-toaster#2.0.0/toaster.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick-theme.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
Preload is intended for assets that are not immediately apparent to the browser (like the image example above) to allow it to start downloading earlier. Here you are using it to preload CSS. The only advantage is it will not be render blocking and then you use the onload function to display it. However CSS normally is render blocking for a reason - otherwise your content looks unstyled. And because it is preloaded it's requested as high priority (which the CSS would have been requested as anyway), so not sure what advantage this is giving you to be honest. Very confused...

Image prefetching using <link> tag

I have seen sites using tag to load images eg;
<link href='images.jpg' rel='somthing' type='something'>
what relevance does this have while designing a website?
What aspect of website does it help optimize( i am thinking it's used for optimization. Right me if i am wrong). Can someone explain this to me?
Some people use this for image/css/page prefetching. You can read about it here.
Basically, once a page is finished loading the browser will see these link tags and if the rel attribute is "next" or "prefetch" then the browser will start downloading whatever the href attribute points to and store it in the cache so that it will load very fast if the user clicks on it.
This method can be used to prefetch anything including images, style sheets, different web pages, etc. As long as the url used in the <link> matches the url used to normally load the resource, it will load that resource from the cache.
For example, if your page had this link Page 2 and you wanted to prefetch it, you would add this to your page <link rel="next" href="page2.html">.
Finally, this method of prefetching is preferred over the javascript methods because this type of prefetching is standards compliant, is handled by the browser, and can be disabled by the user if they have metered bandwidth or other connection limitations.
While a page loads, blocking scripts can interrupt, forcing other scripts to wait. rel=preload in a link element becomes a declarative fetch primitive that initiates an early fetch and separates fetching from resource execution.
<link rel="preload" href="/style/other.css" as="style">
<link rel="preload" href="/assets/font.woff2" as="font">
<link rel="preload" href="/img/header.png" as="image">
ref. https://w3c.github.io/preload/
take note that preload is PREliminary

Is putting your favicon.ico file in a non-root path a bad idea?

When and how do browsers request the favicon.ico file? Do they always check for it in root, or do they read the content of the webpage first to see if the page specifies the location?
I have my favicon.ico path in /images
There is the following tag in each of my pages:
<link rel="shortcut icon" href="images/favicon.ico">
When I load the page in my browser, it seems to work (I can see the file), but I don't know whether they are making bad requests to my root folder first (where the file doesn't exist), and are later making a request to the link.
I want to minimze 404's and wasted bandwidth, by the browser making incorrect calls to my site.
EDIT: I'm looking for some insight into how browsers work, and request this file, so my site structure is efficient.
Remember that not all requests to your site are for HTML pages! Requests for non-HTML content, like bare image files (e.g, viewing http://example.com/image.jpeg directly in the browser), cannot see a <link> tag. Therefore, they must fall back to searching for the shortcut icon in the standard location at /favicon.ico.
This still doesn't mean that this needs to be the canonical location, though! You can still keep it in /images/favicon.ico if you want - just make sure that a redirect is in place from /favicon.ico to wherever your preferred location is.

Any problems with favicons in a subfolder?

Could there be any problems moving favicons and apple touch icons to a subfolder?
Like:
<link rel="shortcut icon" href="/images/favicons/favicon.ico">
<link rel="apple-touch-icon" href="/images/favicons/apple-touch-icon.png">
Yes, some browsers start downloading /favicon.ico at the same time they start downloading HTML document. If there's no file you'll get an extra 404 in your server log and the browser will have to make an extra HTTP request when it recognizes the icon is elsewhere.
A quote from Yahoo's Best Practices for Speeding Up Your Web Site:
The favicon.ico is an image that stays
in the root of your server. It's a
necessary evil because even if you
don't care about it the browser will
still request it, so it's better not
to respond with a 404 Not Found. Also
since it's on the same server, cookies
are sent every time it's requested.
This image also interferes with the
download sequence, for example in IE
when you request extra components in
the onload, the favicon will be
downloaded before these extra
components.
The only problem could be that your relative link is not under the root domain, so that
HOST / YourPath /images/favicon.ico
can be found difficult.
If that would be the case then you would need to include a base href tag in your document and then this would be solved.
p.s. here is the parser i'm writing now to auto download favicons, find yourself in the flow: http://plugins.trac.wordpress.org/browser/wp-favicons/trunk/includes/class-http.php

How to prevent the browser from asking for the favicon?

Is there some directive I could use in my HTML to tell the browser not to ask for the favicon?
Add this line.
<link rel="icon" href="data:,">
This assigns an empty data URL to the favicon’s element which specifies the location of the external resource. This trick stops the user’s browser from sending an automatic HTTP request for the favicon.
This has some more details
No, I don't think there is. From Wikipedia:
Most web browsers do not require any HTML to retrieve a favicon that conforms to the de facto file name and type (favicon.ico) located in the web site's root. If no favicon link is detected upon HTML page load completion and no previous site visits are recorded in the browser's history, a favicon.ico is requested automatically.[8]
The only thing you could do is explicitly point the browser to a different location (that for example could return a 204 no content)
<link rel="shortcut icon" href="http://www.example.com/my_empty_resource" />
You could try pointing the <link> at a data URL. As commented below, IE will not like this, though.
Example (from 11011.net):
<link rel="icon" type="image/gif" href="data:image/gif;base64,R0lGODlhEAAQAIAAAAAAAAAAACH5BAkAAAEALAAAAAAQABAAAAIgjI+py+0PEQiT1lkNpppnz4HfdoEH2W1nCJRfBMfyfBQAOw==" />
Edited to reflect Pekka's concern regarding IE.
If you are not using HTML and its auto generated by Flask or some frameworks you can always add a dummy route in the app to just return dummy text to fix this issue.
Eg for Python Flask Application.
#app.route('/favicon.ico')
def favicon():
return 'dummy', 200