I'm working on a project where I would like to preload a couple of large videos so I started reading up on timing in network performance and resource prioritization.
I found that when I looked at the Priority column of my network tab in the chrome dev tools, the video priority levels were "low" according to the browser. Normally this would be fine, but we're working on a web VR experience so the videos (or at least the first one) is the foundation of the view.
It seemed like I could use the link tag's type="preload" attribute to raise the priority level of the first video. I tried adding a link tag into a small proof of concept and referenced one of our videos:
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="preload" as="video" type="video/mp4" href="videos/cardboard.mp4" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0">
<link rel="stylesheet" href="css/main.css">
</head>
<body>
<video src="videos/cardboard.mp4" autoplay width="200" style="border:1px solid green"></video>
<p class="start-button">Start</p>
</body>
</html>
When I review the network tab in the dev tools the video's priority level still shows as "Low", but the video started loading at the same time that the "Highest" priority resource (the css) was loaded:
When I comment out the preload link it does seem like the video's load timing is queued until after the CSS is finished:
So it seems like the preload is working, but I'm not sure if the preload is working and chrome isn't updating the Priority value, or if the load time is different because without the preload link tag the css is referenced before the video tag.
i.e. Am I doing it right?!
<link rel="preload"> does not change Chrome's internal "priority" for downloading an asset, it simply instructs Chrome when to start the download.
The resource is loaded with the same priority as it would otherwise, but now the browser knows about it ahead of time, allowing for the download to start earlier.
A stylesheet or font will still be considered Highest priority, and a video will still be considered low priority. But Chrome will start downloading an asset immediately when it encounters the <link rel="preload"> tag.
Note that <link rel="preload"> is a compulsory instruction to the
browser; unlike the other resource hints we’ll be talking about, it’s
something the browser must do, rather than merely an optional hint.
Source: https://developers.google.com/web/fundamentals/performance/resource-prioritization
Related
Whenever I make an index.html file and write Anything inside it then open it in browser, I see a Favicon that I have never seen before. I want to know why is that Favicon showing and is there any way to stop it?, I didn't even add a html tag for a Favicon but It's still showing.
CODE:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>This is a title</title>
</head>
<body>
<h1>TEST</h1>
</body>
</html>
Favicon
Image of Favicon
First of all try to be sure that your project do not have favicon. Try to open www.[mysite].com/favicon.ico. If there is none pass to step two.
Wrong favicon could be taken automatically from your browsers cache. Try to hard reload your page (for mac it is shift+cmnd+r)
If favicon still shows and you do not want to show any favicon just pass empty href for it inside your header tag
<link rel="shortcut icon" href="data:image/x-icon;," type="image/x-icon">
The major browsers look into the root folders after a "favicon.ico", you can find more info on it here (another Stackoverflow thread)
Sometimes, a webpage automatically makes an automatic favicon request on page load.
To prevent this add following to head of your HTML tag.
<link rel="icon" href="data:,">
I'm trying to build a simple single HTML page that can be launched when offline (on Android, if that matters).
I'm using the Web App Manifest to give the app a name for adding to the home screen and display fullscreen with no browser chrome. This much works.
<!DOCTYPE html>
<html>
<head>
<link rel="manifest" href="mf.webmanifest">
<meta name="mobile-web-app-capable" content="yes">
</head>
...
</html>
This does not appear to be cached when offline. Separately, I can make a page which is cached offline using the application cache:
<!DOCTYPE html>
<html manifest="mf.appcache">
<head>
<meta name="mobile-web-app-capable" content="yes">
</head>
...
</html>
However, when I try to combine these two (so I can have an offline-cached page that launches fullscreen), the Web App Manifest is ignored and I only get the offline behaviour as in the second example.
What I ultimately want is a single page that can be added to the home screen, that opens full screen with no browser/OS chrome at all, and is cached for use offline. A solution that works just on Android using Chrome 65 is acceptable.
That's an interesting dilemma! I wonder if you would have better luck using
<link rel="manifest" href="/manifest.json"> as described by Google. Here's a link to their recommendations for the Web App Manifest.
The Web App Capable meta tag is primarily for full screen capabilities. If you want caching specifically, I think using the http-equiv="cache-control" header tag and its directives is closer to what you're trying to accomplish. Especially since Service workers aren't globally supported yet. I found a decent explanation on HTML caching here on stack: "How to set HTTP headers for cache-control."
Edit: another user has pointed out that Chrome will not honor this tag if a display is set up in the manifest file
The Service Workers feature provides the same capabilities as the deprecated Application Cache.
MDN has an article on Using Service Workers which I found very helpful in implementing what I needed to replace the Application Cache.
I got an empty website up and running online. Basic html5 page with a style link and a script link. It looks like this:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Taco Bell at midnight</title>
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="css/styles.css" />
<script src="js/scripts.js" type="text/javascript"></script>
</head>
<body>
</body>
</html>
The src's are accurate, I have a folder in the same directory as the html page with the name css and js. When I try to visit them, it shows them as blank. However, when I drag the files out to the same directory as the parent, and update the href, it shows them with the content. Does anyone have an idea as to why this is happening?
It seems relevant to add I just purchased the domain today from GoDaddy, and am using x10hosting for free hosting.
UPDATE: The styles.css still appears in my home directory (in chrome, not cpanel) after being moved, and ctrl+f5'ing, and it now also appears in the folder css/styles.css as well???
UPDATE2: Now it appears as though the files are just updating really slowly? I see the changes in codeanywhere/cpanel immediately, but chrome takes like half an hour to get the changes, regardless of clearing my history/cache and ctrl+f5'ing.
x10hosting (free version, I haven't tested paid version) cache is really bad, this seems to be a server issue, sometimes it keeps showing files that you deleted hours ago, sometimes it won't show files that didn't exist beforem, you might need to wait for hours.
On pages containing multiple SoundCloud iframes, a random subset of those iframes appear invisible in both Chrome and Firefox, and instead of containing the normal SoundCloud content they contain the following HTML. The iframes affected often change with each page load, and youtube iframes on the same page are unaffected. Does anyone know the cause and/or a workaround?
UPDATE: On further examination, this is standard SoundCloud content, except div id="widget" is empty, and a manual iframe reload on an individual iframe forces it visible. Is this maybe a situation where the iframe is first loaded, then the div content is fetched with an XHR, and on a page where the browser is laboring over numerous loads on a congested network some XHR's silently time out? If so SoundCloud, could you increase your XHR timeout?
UPDATE 2: I tested this some more on 2 separate machines on the same LAN, and it looks like it might be a problem with the current version of the standard Flash plugin (11.5.502.110 on winXP--installed by auto-update Nov.9, about when this started, and 11.2.202 on Ubuntu 12.04--installed today, Nov. 27). The following information should make it reproducible. I get 100% consistent failures in Firefox on both machines, and I can toggle the failures on and off in Chrome (on both machines) by enabling the standard plugin vs. Chrome's own PepperFlash plugin. There are 100% no failures with PepperFlash, but the current version of the PepperFlash player is unusable because of impossibly choppy audio.
<html lang="en">
<head>
<meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1, user-scalable=no">
<title>SoundCloud Widget</title>
<base target="_blank">
<link rel="stylesheet" href="/player/assets/widget-22748325.css">
<script src="/player/assets/widget-ab572693.js"></script>
<script>
require(["lib/support", "lib/flash-widget"], function(support, flashWidget) {if (support.newWidget) { require(["application"], function(A) {A.start("207ad5d2")}) } else { $(flashWidget.start); }});
</script>
</head>
<body class=" hasGoogleVoiceExt">
<div id="widget" style="height: 100%;"></div>
<div id="sm2-container" class="high_performance swf_error" style="z-index: 10000;"><embed name="sm2movie" id="sm2movie" src="/player/assets/swf-8bc33658/soundmanager2_flash9.swf" quality="high" allowscriptaccess="always" bgcolor="#ffffff" pluginspage="www.macromedia.com/go/getflashplayer" title="JS/Flash audio component (SoundManager 2)" type="application/x-shockwave-flash" wmode="transparent" haspriority="true"></div>
</body>
</html>
I just had a look at this again after giving Adobe a couple of months to get their act together, and the problem is now gone in Chrome and Firefox on XP with version 11.5.502.149 of the Flash player. I haven't checked Ubuntu, but presumably they pushed the change out there too.
We are developing a site which makes heavy use of <base href> (which is typical for TYPO3 sites). The site is developed in a sub directory and will later be relocated to the top directory so we can not easily remove <base href>.
Our client told us that sometimes when she browses the new pages she gets the page content without layout applied. We debugged this: It happens only in IE9. Looking at the logs we find that when the error happens, IE9 tries to load CSS, JS and all images consequently from the wrong location: relative to the current URL, not relative to the BASE HREF... Further inspection of the logs show us that IE8 users are also affected, including some dumb web spiders (no problem for us with the latter ones, who cares?).
We already know about IE8 speculative downloader / lookahead parser: http://blogs.msdn.com/b/ieinternals/archive/2009/07/27/bugs-in-the-ie8-lookahead-downloader.aspx
I'm sure we are NOT facing bugs described THERE: All page elements (including first header element) are loaded from the wrong location. This bug describe that only second and later elements from the page header are affected. We can prove this by watching the access logs when the problem occurs.
A simple reload fixes the issue, comparing the page source code with the bug occurring and without it occurring shows absolutely no difference. Only IE is affected, all other browsers are fine.
The <base href> tag is the first in the <head> tag. We tried every possible solution, nothing helped. Seems to be an IE bug.
Anyone else experiencing this and found a work around? We have several other sites using <base href> where we cannot reproduce such behavior in our test systems - so something is probably triggering or working around this bug. But I analyzed the logs of these sites and can see that some visitors using IE8 even there experience that bug.
As requested in the comments, here's an obfuscated example of my html head:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<base href="http://client.site/cms/" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!--
This website is powered by TYPO3 - inspiring people to share!
TYPO3 is a free open source Content Management Framework initially created by Kasper Skaarhoj and licensed under GNU/GPL.
TYPO3 is copyright 1998-2011 of Kasper Skaarhoj. Extensions are copyright of their respective owners.
Information and contribution at http://typo3.com/ and http://typo3.org/
-->
<meta name="generator" content="TYPO3 4.5 CMS" />
<link rel="stylesheet" type="text/css" href="typo3temp/stylesheet_fad97d0aa7.css?1312295592" media="all" />
<link rel="stylesheet" type="text/css" href="fileadmin/css/styles.css?1319535102" media="screen" title="Standardstyles" />
<link rel="stylesheet" type="text/css" href="fileadmin/js/fancybox/jquery.fancybox-1.3.4.css?1310653643" media="all" />
<link rel="stylesheet" type="text/css" href="fileadmin/js/jqtransformplugin/jqtransform.css?1312810052" media="all" />
<script src="fileadmin/js/jquery-1.6.2.min.js?1310979164" type="text/javascript"></script>
<script src="fileadmin/js/jqtransformplugin/jquery.jqtransform.js?1312460310" type="text/javascript"></script>
<script src="typo3temp/javascript_93553eae97.js?1312462864" type="text/javascript"></script>
<link href="fileadmin/css/print.css" rel="stylesheet" media="print" type="text/css" />
<script src="/tools/formmailer.js" type="text/javascript" charset="utf-8"></script><title>Some title for the page</title>
</head>
We found it: Internet Explorer does all sorts of funny things when the HTML file returned from the server contains a UTF-8 BOM. We still consider this a IE bug but at least we found a work around.
Background info: During initial page generation some PHP files where included which are not included for successive requests (because most generated content is cached now and these files do not need to be run). Some of such included PHP files included a UTF-8 BOM. Because the BOM comes before the opening PHP tag, it is streamed out to the output of PHP.
We figured it out by comparing outputs in fiddler and the file sizes differed by 3, 6 or 9 bytes when the error occured. Running a diff over the outputs showed the BOM header, comparing in most Windows editors didn't show it because these editors know about a BOM. So the problem was hidden. Thank you IE for 2.5 days of useless work!
If you ever run into such a problem again, consider removing the base tag with config.baseURL > and render all links with an absolute URL:
Either use config.absRefPrefix = http://www.example.org/mysubfolder/ (most save variant) or use config.absRefPrefix = /.
i suspect you're not using an absolute path in the tag. IE is allowed to ignore your tag since its not specified correctly. See http://www.w3schools.com/tags/tag_base.asp