I'm Trying to make a simple web browser in node-webkit, to polyfill features that Chromium doesn't support yet (time element, etc). I have had success in listening for the iframe.onload event and then appending a script tag with the polyfills, but this still means that features that I've polyfilled won't be detected by Modernizr or other feature detention.
I've tried loading the page using the http node module, appending a script tag and then turning the page source into a data URI for the frame but data uris essentially turn external pages into static html with no scripting, which renders many web pages unusable.
Also, loading a page through node's http module is proving extremely slow compared to loading through an iframe.
So, is there any other way? Ideally I run a script in the iframe before any other scripts are run.
Yes, I am using nwfaketop and nwdisable on the iframe.
The 'document-start' event should be helpful. See https://github.com/rogerwang/node-webkit/wiki/Window#document-start
See also Window.eval() in https://github.com/rogerwang/node-webkit/wiki/Window#windowevalframe-script
Related
A colleague showed me Lighthouse on the Chrome browser. I have a single page application (SPA), and I'm able to run it against the base URL of my application.
However, all subsequent screens are rendered by client-side JavaScript without a change to the URL in the browser.
How can I test the rest of my site?
The only way is to switch project to server side rendering, like Angular Universal
update: found this issue https://github.com/GoogleChrome/lighthouse/issues/5187
If you can't switch your project to server side rendering as Alexey Semerenko said, you can consider using another testing tool like Sitespeed.io which allows you to define user actions as a script to browse every pages of your application.
After your test you will gather the same kind of metrics.
currently the project i am working on is using cache:1.1.1 plugin with grails 2.2.4. but for some reason its not working and in browser under the network tab i get status 200 instead of 304 every time i reload the page.
I have tried different plugin versions but in vain.
i don't want any special functions to be cached. I just need my assets, so that the loading time speeds up.
compile ":cache:1.1.1",
I have read about the ehcache somewhere but don't know whether it'll work or not.
The cache plugin doesn't have anything to do with assets - for that you should look at the asset-pipeline plugin and its addon plugins.
The cache plugin caches method call results (typically service methods) and GSP page fragments, and should be used when the method will return the same result given the same inputs (or the GSP section will generate the same output) and is time-consuming or resource-intensive to compute, so caching those values and not recomputing the values every time can save a lot of server load. It doesn't do anything by default; you need to add annotations to methods that should be cached, and wrap the sections of GSPs that should be cached in a taglib call. See the documentation for more info.
I've a Ajax .net website which follows this structure :
Control (ascx) : TopMenu, LeftPanel, RightPanel, Footer, all are very simple controls and don't require any connection to database or server side code !
One div body (ajax)
Everytime the website starts, the 4 controls load first, then comes the Ajax body. The performance is pretty good in development environment.
But when i uploaded the precompiled site to the host, it always take quiet long for starting up, after the first load, the performance is good
What i can't understand is : as far as i know, the four ascx control will be rendered first, that means the page will be loaded to the client, after that is the ajax content. So what's causing the performance on start up ?
P/s :
i did set the key compilation=false in web.config
i compiled the site using Publish tool in VS 2010 (Release mode and not allow updatatable ... )
i have no images on the site, it's a very simple site
i've checked similar topics, and event posted a question not so long ago about
this, but still without success
my site: http://iketqua.net
From your site and running the Network Analysis on google chrome what is blocking the render of your site is a huge delay for make a lot of calculations on page load, there is a lot of time that takes to start get data.
Also the google analytic script, must be placed on bottom of your page, together with other external scripts for google plus, facebook like etc.
Also there are 2 fonts on this css, that can not be load, and this takes almost 3 seconds delay.
http://iketqua.net/Styles/Fonts/MyriadPro/font.css
(source: planethost.gr)
If you are referring to the very first request after deployment to production. I don't think there's anything you can do about it. ASP.NET first request will always be slow, even if it is a pre-compiled site because the server still needs to load resources on the server-side.
But, if you are talking about first load from the client-side perspective, by just running Chrome Developer Tools I can see that your site's home page is quite heavy (44 requests, ~4 seconds to load) which explains why the first load takes some time and sub-sequent requests are quicker...mainly, because most of those 44 requests get cached by the browser. Now, in your dev environment it happens quickly because there is no significant network latency or connection hops, once you move to production the network lantency and connection hops plays a big role in performance...that's why many sites use CDNs.
Suggestions
Make your site lighter. There's many things you can avoid. For example:
This background image (http://iketqua.net/img/header_bg.png) is useless because it is a plain color which you can easily achieve that using css. That'll translate to one request less
Bundling and minification tools to minify and merge style sheets and js files
Optimize your css. Take the time to review your css and clean it. I can't believe that such a simple page can be requesting 9 css files...probably most of them are coming from open source frameworks (jQuery UI, DatePick, etc)
I lack permissions to post this as a comment, but if it's fine in the development environment, it may be something as simple as ability of the host or the connection to the host.
After the first load, the performance is good
I'd be inclined to think this is due to the site being cached.
For maintainability reasons, I want to database drive my javascript, in that I only want to send the javascript which is needed based on the users options.
So, is it faster/less resource heavy to have links in the database pointing to javascript files, then using response.writefile to embed those files into the clientside page, or is it faster/less resource heavy to stick the javascript script straight into the database, and response.write it onto the screen as and when needed?
So, is it faster/less resource heavy to have links in the database pointing to javascript files
Usually yes.
External Javascript files can be cached by the browser, and will be loaded only once. Javascript code injected into the HTML page needs to be loaded every time, which increases bandwidth and loading times.
Also, having JavaScript code in a static file (instead of a dynamic one that fetches the code from the database on every request) is bound to be the fastest and least resource-intensive solution.
Don't use Response.Write.
Be aware that if you send the entire JS file once, the client will / should cache it so it doesn't have to be sent again.
DB lookups for every page just to get the relevant JS will be slow.
By only sending the links to the javascript to the client a seperate HTTP request will have to be created in order to go and get each file.
If you embed only the required javascript directly into the page when needed this prevents this. Look at jQuery, thats got a load of javascript available to the client that isn't being used.
Less HTTP requests generally results in a faster website so I would go with embedding the code directly.
Edit:
I disagree with the caching answers above. If you ensure only the smallest amount of javascript that is required is embedded then my answer should be faster. This page will be cached too!
What are some of the disadvantages of using an external JS file over including the JS as a part of the ASPX page?
I need to make an architectural decision and heard from coworkers that external JS does not play nice sometimes.
The only downside that I am aware of is the extra HTTP request needed. That downside goes away as soon as the Javascript is used by two pages or the page is reloaded by the same user.
One con is that the browser can't cache the JS if it's in the page. If you reference it externally the browser will cache that file and not re-download it every time you hit a page. With it embedded it'll just add to the file-size of every page.
Also maintainability is something to keep in mind. If it's common JS it'll be a bit more of a pain to make a change when you need to update X number of HTML files' script blocks instead of one JS file.
Personally I've never run into an issue with external files vs embedded. The only time I have JS in the HTML itself is when I have something to bind on document load specifically for that page.
Caching is both a pro and potentially a con, if you are not handling it properly.
The pro is obvious, as it will improve page loading on every page load past the first one.
The con is that when you release new code, it may still be cached by the user's browser, so they may not get the update. This can easily be solved by changing the name on your js file. We automatically version our js with the file's timestamp, and then make sure that points to the create file in the web request through configuration on our web server (mod_rewrite, Apache).
Ask them to define "play nice". Aside from better logical organization, external js files don't have to be transmitted when already cached.
We use YUI compressor to automatically minify and combine external scripts into one when doing production/staging builds.
The only disadvantage I know is that another request must be made to the server in order to retrieve the external JS file. As was said before me you can use tools like YUI compressor to minimize the effects of this.
The advantage however would be that you can keep all of your JS code in a separate more maintainable format.
Another huge advantage to external javascript is the ability to check your syntax with Jslint. That, added to the ability to minify, combine and cache external scripts, makes internal javascript seem like a poor choice.