I am looking for a way to speed up my website by loading content that is not required to display the main DOM afterwards.
My webpage is loading 2.8MB of ressources where 879kB are actually transferred. (gzip)
I am aware of the possibility of loading only the required components, but if I do so, I'll have the same problem after a user clicks any link to another component.
Basically what I want to do is loading my main component and displaying the DOM immediately.
After DOM is loaded, I want to load the other components as usual.
Is there a NPM package that does this?
If not, how can I realise my desire?
Use lazy loading modules to load them only if needed. It will greatly decrease bundle size:
https://angular.io/guide/lazy-loading-ngmodules
Application should be split to separate modules and routing is modified not to load them eagerly
What you are describing sounds like server side rendering. You should check out Angular Universal.
https://angular.io/guide/universal
Related
I want to write an application using NestJS. But coming from PHP, I am very much used to the SSR approach of rendering views for the client. Now, by using JavaScript, I could technically ask the server to not completely navigate a page, but just load the <body> element of the sent output, and then embed that into - and overwriting - the current view. By what I can tell, initially, this would work as I would just app.$mount(...) on the initially sent HTML and have Vue hydrate off that.
But what if I want to implement this across multiple pages?
The idea is, that by using SSR, I get to keep basically all SEO related features and can reduce the initially loaded JavaScript by taking advantage of WebPack's lazy-loading feature. But when a user navigates from page A (initially loaded) to page B (subsequent load), I would like to just replace/update the current content and then load the bundle apropriate to that page and hydrate.
Is that possible, and if, how?
So far, I know I would have to unload the currently used bundle to remove all references to events and objects from memory, and then load the new bundle in, which I can then use to hydrate the received view. And this does not take into account that a menu bar might not need to be treated separately, since it will only have to have the current location updated with a .current class appended to the relevant menu item. I might be wrong here, but that is why I ask :)
I am using Vue and Webpack in a large project and I am looking to optimize the loading of some components. I am already lazy loading my pages but I wonder if I can take a step further and dynamically load subcomponents inside those pages.
I want to load a subcomponent ("my-modal" in the exemple below) after the main component (the page) is rendered (to speed up the load time of the page). This sub-component is relatively heavy and means to be frequently open, but is hidden by default (its a modal). So my strategy is to load it right after the page is loaded but not with the page, so the page can load faster.
I came across vue's Async Components but I am not sure if it can help, does-it ?
Here is an exemple of what I was doing with an old school "static" import :
// page.vue
<script>
import myModal from "#/components/my-modal";
export default {
components: {
myModal,
},
}
</script>
Here is an exemple of how I am dynamically importing my sub-component (aka "async components") :
// page.vue
<script>
export default {
components: {
myModal: () => import("#/components/my-modal"),
},
}
</script>
I am registering my component locally (local registration), but I am not sure if its the best way, maybe its another question...
Importing dynamically will generate a new file, and this new file will only be downloaded when the user goes to that specific page, not when the user goes to /.
That increases load speed and decreases the bytes that the user has to download at the moment one access your site.
For all intents and purposes...probably not.
With today's modern devices, browsers, and Internet access, that component would have to be pretty significant in order to provide a speedup overall to page load. If it's just markup and code, I'd have a hard time believing that one component would even come close to approaching say, 700Kb in size (especially if minified and compressed). In all but the worst Internet connectivity, the browser is going to handle this with no problem at all, especially if the component is include in the main bundle for the site.
However, if your component does some heavy computational work upon arrival, then maybe there would be a speedup to loading it async (as the browser can "get on with" loading the page while waiting for the modal to arrive).
However however, most browsers only allow a number of XHR requests running to a single domain at a time (I think Chrome is 4 by default). Lazy loading a file would mean the requests made by the page itself take priority, but having more files to load over multiple requests rather than lumped into one may be overall slower.
However however however, browsers are excellent at caching these requests, so subsequent visits to your site probably wouldn't have this problem to consider.
Lazy loading modules really provides a speedup when you are able to lazy load entire sections of your site only when the user needs to access them, like on routes.
The final however, though, is that it's good practice to not burden browsers and mobile devices with needless bloat, and while lazy loading that module may not have a noticeable speed difference, it may overall be a decent idea depending on your needs and when you load it. If a visitor never needs to view the modal, and you load the modal when it's needed...there's a lot to consider, as that may cause a delayed UI but be better for an overall greater percent of your users.
If you're trying to make your site more accessible to those with poor Internet, and you know the modal will be used frequently, it'd be probably better to load it with the page because it's part of page functionality.
So i stumble on this component called lazyload.
What does it do and advantage and disadvantage of using it ??
Just curious about it because i watch some of john papa's videos and he keep mentioning it.
They idea of lazy load is that you only load something when you need it.
For example: at startup of your application you might not need a library to validate your form fields. (you only need it when someone actualy fills in a form and submits it).
Lazy loading makes sure its only loaded when needed.
The Plus:
Reduced start/load times & size.
Packages/data that are not used by the current user, will not be loaded.
Minus:
You have to have more seperate packages you can't minify and bundle them together.
More request to the server (because you can't bundle them).
could have a load on first use experience, the first time user does something the application needs to load some extra stuff.
conclusion & advice
So consider the size and the lifecycle of your application. If the application is small and you package all in one. probably the simplest approach would be to package everything in one. it's a bit of a longer load time, but after that the javascript gets cached in the browser anyways so it doesn't matter after first load.
Reasons you want to lazy load:
You want to be able to update seperate parts of the applications (thus not bundle it)
Application becoming problematically big. you want to cut it up in smaller parts.
You don't bundle your javascript files (great example here before angular was requirejs).
You have a lot of different types of users using the system each with completely different set of scripts.
Every page uses completely different set of javascript. (not likely when you use angular)
Javascript frameworks like AnguarJs, BackboneJs, Emberjs that use to develop Single Page Applicaitons(SPA's) load lots of js files. Since these files cannot be unloaded can a application go into a situation that cause memory issues because of these js files because SPA's usually doesn't refresh the page.
For an example if application have multiple modules( eg : payroll, attendance,.. of a ERP ) SPA load js files specific to that module to browser when it get loaded. But when navigated to different module without refreshing the page previously loaded js files remain in memory. Imagining application has lots of modules like this is it possible in a certain time these js files cause memory problem ( not enough memory or corruption) ?
Keep in mind that you don't need to use a framework to create a SPA. It is true that at times Angular, React and other frameworks do create bloated code, but they also provide many useful functionality. So depending on the project you may or may not use them.
You can also load your code as modules, and load the modules when needed and unload them when you don't need them. So there is more to SPA's than just using a framework.
Things to remember before developing a Single Page Application
Try to use minified versions of JS and css files
Never use Single page approach if you are developing a large
application because when all html is renderd in single page then the
web application get heavier
I know that best practice for including javascript is having all code in a separate .js file and allowing browsers to cache that file.
But when we begin to use many jquery plugins which have their own .js, and our functions depend on them, wouldn't it be better to load dynamically only the js function and the required .js for the current page?
Wouldn't that be faster, in a page, if I only need one function to load dynamically embedding it in html with the script tag instead of loading the whole js with the js plugins?
In other words, aren't there any cases in which there are better practices than keeping our whole javascript code in a separate .js?
It would seem at first glance that this would be a good idea, but in fact it would actually make matters worse. For example, if one page needs plugins 1, 2 and 3, then a file would be build server side with those plugins in it. Now, the browser goes to another page that needs plugins 2 and 4. This would cause another file to be built, this new file would be different from the first one, but it would also contain the code for plugin 2 so the same code ends up getting downloaded twice, bypassing the version that the browser already has.
You are best off leaving the caching to the browser, rather than trying to second-guess it. However, there are options to improve things.
Top of the list is using a CDN. If the plugins you are using are fairly popular ones, then the chances are that they are being hosted with a CDN. If you link to the CDN-hosted plugins, then any visitors who are hitting your site for the first time and who have also happened to have hit another site that's also using the same plugins from the same CDN, the plugins will already be cached.
There are, of course, other things you can to to speed your javascript up. Best practice includes placing all your script include tags as close to the bottom of the document as possible, so as to not hold up page rendering. You should also look into lazy initialization. This involves, for any stuff that needs significant setup to work, attaching a minimalist event handler that when triggered removes itself and sets up the real event handler.
One problem with having separate js files is that will cause more HTTP requests.
Yahoo have a good best practices guide on speeding up your site: http://developer.yahoo.com/performance/rules.html
I believe Google's closure library has something for combining javascript files and dependencies, but I havn't looked to much into it yet. So don't quote me on it: http://code.google.com/closure/library/docs/calcdeps.html
Also there is a tool called jingo http://code.google.com/p/jingo/ but again, I havn't used it yet.
I keep separate files for each plug-in and page during development, but during production I merge-and-minify all my JavaScript files into a single JS file loaded uniformly throughout the site. My main layout file in my web framework (Sinatra) uses the deployment mode to automatically either generate script tags for all JS files (in order, based on a manifest file) or perform the minification and include a single querystring-timestamped script inclusion.
Every page is given a body tag with a unique id, e.g. <body id="contact">.
For those scripts that need to be specific to a particular page, I either modify the selectors to be prefixed by the body:
$('body#contact form#contact').submit(...);
or (more typically) I have the onload handlers for that page bail early:
jQuery(function($){
if (!$('body#contact').length) return;
// Do things specific to the contact page here.
});
Yes, including code (or even a plug-in) that may only be needed by one page of the site is inefficient if the user never visits that page. On the other hand, after the initial load the entire site's JS is ready to roll from the cache.
The network latency is the main problem.You can get a very responsive page if you reduce the http calls to one.
It means all the JS, CSS are bundled into the HTML page.And if your can forget IE6/7 you can put the images as data:image/png;base64
When we release a new version of our web app, a shell script minify and bundle everything into a single html page.
Then there is a second call for the data, and we render all the HTML client-side using a JS template library: PURE
Ensure the page is cached and gzipped. There is probably a limit in size to consider.We try to stay under 400kb unzipped, and load secondary resources later when needed.
You can also try a service like http://www.blaze.io. It automatically peforms most front end optimization tactics and also couples in a CDN.
There currently in private beta but its worth submitting your website to.
I would recommend you join common bits of functionality into individual javascript module files and load them only in the pages they are being used using RequireJS / head.js or a similar dependency management tool.
An example where you are using lighbox popups, contact forms, tracking, and image sliders in different parts of the website would be to separate these into 4 modules and load them only where needed. That way you optimize caching and make sure your site has no unnecessary flab.
As a general rule its always best to have less files than more, its also important to work on the timing of each JS file, as some are needed BEFORE the page completes loading and some AFTER (ie, when user clicks something)
See a lot more tips in the article: 25 Techniques for Javascript Performance Optimization.
Including a section on managing Javascript file dependencies.
Cheers, hope this is useful.