What can cause the start render to be delayed even after the load event has fired?
Look at this webpagetest result
This is most probably a bug. For the moment, the iPhone instance on WebPageTest is quite recent and the author is still improving it:
The iOS support is just becoming stable though it's still under VERY active development so don't be surprised if there are a few rough edges (and a lot more limitations than the android testing).
- Patrick Meenan, 09-09-2015
The android tests are much more reliable.
If you check the page you tested without javascript (F1 > Disable Javascript in Chrome DevTools), you can see that most images are lazy-loaded, which mean they are loaded via a JS script checking if the images are in the viewport. As you can see, without JS the load time line is well after all assets loaded.
Also for other assets, like JS, you can add an async or defer attribute to de-synchronize your scripts loads.
Finally, some scripts can be even deliberately loaded after the load event using an attachment on the window load event to write <script> tags in the body when it's triggered as loadJS do for example.
You should read that by the way to better understand how rendering and events timing work.
Related
As of now, we can launch a flutter web app as a single file that will load at once hence taking a lot of time and bandwidth to load which is not ideal, is there any way to load only a single page at a time, not the whole web app. By this I mean, load a widget at a time.
Any suggestions will be appreciated.
after spending a lot of hours trying to solve this situation, I found a solution to speed up the first load of the app.
I saw that my main.dart.js was being downloaded and then, after that, the main.dart.js was triggering the download of the canvaskit.wasm file, this means that my app was starting on a cascade mode, avoiding downloading both files in parallel.
So my solution, after many many many attempts is based on adding only 2 lines of code to the index.html file (.../project_folder/web/index.html).
Inside the <head>...</head> tag insert this two lines:
<script src="https://unpkg.com/canvaskit-wasm#0.33.0/bin/canvaskit.js"></script>
<link rel="preload" href="https://unpkg.com/canvaskit-wasm#0.33.0/bin/canvaskit.wasm" as="fetch" crossOrigin="anonymous">
I know hardcoding these URLs it's not a good practice, but, you will only need to change them if you update Flutter. I'm using Flutter 2.10.1 that uses CanvasKit 0.30.0, and when you build the web app, the generated main.dart.js has a hardcoded URL inside.
If you are going to add those 2 lines to your index.html file, I recommend you to build the web app, and open the main.dart.js file and search for "canvaskit-wasm", there you will find which is the URL you should use (something like "https://unpkg.com/canvaskit-wasm#0.33.0/bin/").
It's giving me a good improvement for the initial loading time! So, hope it works for you too!
Yes, you can load the Flutter web library, only when it is called using Deferred/Lazily loading. Here I copy/paste from Dart documentation:
Lazily loading a library
Deferred loading (also called lazy loading) allows a web app to load a
library on demand, if and when the library is needed. Here are some
cases when you might use deferred loading:
To reduce a web app’s initial startup time.
To perform A/B testing—trying out alternative implementations of an algorithm, for example.
To load rarely used functionality, such as optional screens and dialogs.
And here an article related to this topic.
I love React, it has quickly become my favorite development tool. It is a fantastic library that creates the kind of flexibility I've always dreamed about.
That said, I'm having a very hard time getting Facebook login to work with React in production.
I have tried all of the following methods. In all three cases, I implemented the examples exactly as shown in the code using the simplest possible technique:
https://github.com/seeden/react-facebook
https://github.com/keppelen/react-facebook-login
http://jslancer.com/blog/2017/11/27/facebook-google-login-react/
Everything works great in development. :)
When I create the production build using create-react-app and push it live, it breaks and reports: Error: Facebook is not initialized or Uncaught TypeError: Cannot read property 'login' of undefined where undefined is FB.
Basically it seems like the Facebook javascript SDK is not loaded or initialized.
The first two links above are for existing component libraries, but the third is a custom implementation that places the Facebook initialization code in the index.html file and creates an event listener. The results are the same in all three examples.
It is as if something about the create-react-app compression method is obfuscating the variables to the point that Facebook can no longer work, or at least is not available to the react code. This includes all calls to window.FB as recommended in many tutorials.
I've been working at this for a couple of weeks now (off and on) and am now turning to the hive mind. Anyone have any ideas on how to get Facebook to actually work with Facebook's own code library (React)? It seems so painfully odd that it causes this much trouble and I have been unable to find a clear solution that works in production.
Most of the debugging steps are already mentioned in the comments section.
Here are the steps laid down:
1) Check the network tab in your browser's console and see if the request to load FB's SDK is successful or not
2) Most common culprit is some extension like Ad-Blocker blocking such async requests which loads JS on your web page. Disable it or try it incognito mode
3) Other common mistake I have seen is forgetting to use the FB.init({ // config }); function - which is the actual call which initializes the fb sdk and makes available the FB variable globally.
I want to call Prism.highlightElement or Prism.highlightAll after doing some other javascript processing on my code blocks. I can somewhat control the moment that Prism processes by where I place the <script src="prism.js"></script> but I don't see a way to disable automated processing.
Super kludgy answer:
Even though I asked for the development, not minified, version of prism.js when I download, what I got is kind of minified. Anyway, I found this bit of code:
var a=document.getElementsByTagName("script")
and changed it to this:
var a=document.getElementsByTagName("scriptxx")
So, nothing gets highlighted now, until I explicitly call Prism.highlightAll().
I develop a FB app using Flash using wmode="direct" (for 3D graphics).
In Internet Explorer, every time I popup any FB dialog (e.g Purchase Credits dialog), the flash disappears and when the dialog is closed, the flash does not re-appear...
I tried to set the visibility after dialog is closed:
http://developers.facebook.com/docs/appsonfacebook/tutorial/ (under "Special Considerations for Adobe Flash developers"), but it didn't work.
I've also tried the use FB.Init hideFlashCallback:
http://developers.facebook.com/blog/post/555/ (under "Detecting visibility of Flash objects in Canvas apps"), but it doesn't seem to call the callback function...
Any one had the same issue and manage to make it work?
Any other suggestions?
P.S - I use swfobject to embed the SWF file.
Thank a lot!
Roei
UPDATE: I removed the appId param from the FB JS url:
<script type="text/javascript" src="http://connect.facebook.net/en_US/all.js#appId=XXXX&xfbml=1"></script>
and now the hideFlashCallback is executed, but still - the flash does not re-appear...
I've updated the section Special Considerations for Adobe Flash developers because the code snippet was a bit out-of-date.
The new snippet should give you an idea of how to use the hideFlashCallback, whose semantics have changed since that now out-of-date blog post, in that the function now takes a flash element as an argument. (Unfortunately, we haven't redocumented it yet, but will soon). One thing to note is that the callback does not currently work on IE8, but will after a fix gets pushed next Tuesday.
That said, it should work without that callback. It may be caused by a javascript fatal that stops script execution before the re-showing happens. Look in your javascript console to see if you see any errors.
Otherwise, if you can give me the canvas URL for your application, I can look into it.
Did you try it with other wmodes? what you can try is actually remove the div where you write your flash to, add it with innerHTML and run the swfobject.embed again
I've encountered what seems like a chicken & egg problem, and have what I think is a logical solution. However, it occurred to me that others must have encountered something similar, so I figured I'd float it out there for the masses.
The situation is that I want to use dojo's addOnLoad function to queue up a number of callbacks which should be executed after the DOM has completed rendering on the client side. So what I'm doing is as follows:
<html>
<head>
<script type="text/javascript" src="dojo.xd.js"></script>
...
</head>
<body>
...
<script type="text/javascript">
dojo.addOnLoad( ... );
dojo.addOnLoad( ... );
...
</script>
</body>
</html>
Now, the issue is that I seem to be calling dojo.addOnLoad before the entire Dojo library has been downloaded the browser. This makes sense in a way, because the inline SCRIPT contents should be executed before the entire DOM is loaded (and the normal body onload callback is triggered).
My question is this - is my approach sound, or would it make more sense to register a normal/standard body onload JavaScript callback to call a function, which does the same work that each of the dojo.addOnLoads is doing in the SCRIPT block. Of course, this begs the question, why would you ever then use dojo.addOnLoad if you're not guaranteed that the Dojo library will be loaded prior to using the library?
Hopefully this situation makes sense to someone other than me. Seems like someone else may have encountered this situation.
Thoughts?
Best Regards,
Adam Rice
You're doing it correctly. External Javascript files are loaded and executed synchronously in order, so by the time it reaches your dojo.addOnLoad( ... ); Dojo has loaded. Use dojo.addOnLoad instead of window.onload for two reasons:
it fires earlier, because it utilizes DOMContentLoaded
it handles asynchronous loading of dojo.require by postponing the execution until all required scripts have been read
Explained in DojoCampus as (dojo.addOnLoad):
dojo.addOnLoad is a fundamental aspect
of using Dojo. Passing addOnLoad a
function will register the function to
run when the Dom is ready. This
differs slightly from document.ready
and body.onload in that addOnLoad
waits until all dojo.require() (and
their recursive dependencies) have
loaded before firing.
This might have nothing to do with your problem, but ive just had a case where I had the same symptoms. For me everything worked fine for Firefox, Chrome etc, but not IE8.
I was getting what looked like dojo not being loaded, an error in IE8 saying that dojo was undefined (but not all the time) and i could strip everything down to just style sheets and importing dojo and still get the error.
I was running a local google app engine development server. This looks to be based on pythons SimpleHTTPServer which in turn uses SocketServer.BaseServer. This has BaseServer.request_queue_size which defaults to 5 - i couldn't find anything in app engine which overrode this value so i guess the development google app engine server has an upper limit of 5 connections.
Using regedit and going to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
“MaxConnectionsPerServer”=dword:00000010
“MaxConnectionsPer1_0Server”=dword:0000010
This shows that IE was going to try and open up to 10 simultaneous connections. I edited these two keys and made them 2 and restarted the computer, the problem went away.