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.
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 :)
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)
I use an external JavaScript library that is hosted on a CDN.
Some users report that when they first visit the pages that require this library, it takes a little while to load as well as to render stuff (the library renders LaTeX).
I wonder if I can optimize their experience by (pre-)loading this library on some other pages before they arrive at the pages that actually use it. This way, I hope the browser will cache the library early, so the rendering may happen faster later.
P.S. the library in question is MathJax.
Since you're interested in MathJax specifically, simply loading it won't buy you that much performance. (Though MathJax will be cached and if you use the MathJax CDN your users might already have cached it while visiting some other site.)
There are two reasons for why you probably won't see much of a performance increase.
First, MathJax loads most of its components dynamically. For example, the MathJax webfonts will only be loaded if no compatible font is installed on a user's system and they are also broken up into several pieces, to be loaded only when MathJax actually encounters a character. The same goes for other components. This also means that on a page without any mathematics, loading MathJax will not help you cache much.
That being said, the actual download of MathJax components can be optimized a bit by using one of the combined configuration files ending on -full, see the MathJax documentation.
However, it's the typesetting that's usually the real performance hit. MathJax output depends on your content as well as the user's combination of screen, browser, and OS. Both calculating the best fit as well as inserting & reflowing the content is an issue that has some fundamental limits (IE8 does a particularly bad job in standards mode).
PS: If you have hidden or dynamic content, you might want to look at the configuration option skipStartupTypeset: true; see the MathJax documentation.
[Disclaimer: I'm part of MathJax]
If you add a script tag calling the library at the end of your page (just before the html closing tag), everything else will load prior to it and the user can start using the page while the library is still loading.
EDIT: This allows you to "pre-load" the library on another page withtout slowing it down.
What are the real benefits (if any) to loading your JS at the bottom of the document, as opposed to the top. It seems there is a brief delay in page loading and JS dependent functionality.
I am using html5boilerplate for beginning all my templates, but am not really sure on how beneficial loading the JS at the bottom is.
Does it really make all that much of a difference, and if so, why?
If you include external js files at the bottom of your page, you give the priority of your HTTP requests to the visual display that will be presented to the client instead of to the logic of interaction or dynamics. I believe, if you do not use a content delivery network to deliver images to the client then you are only allowed to process a maximum of 2 HTTP requests at a time. You do not want to waste these requests on logic because we all know how impatient the end user is.
By loading js at then end of the file you can access the DOM(most of the time) without having to call a document.ready() function. You know that if the page render finally makes it to your javascript code that the necessary page elements have usually loaded already.
There are a few more reasons out there but these are the important ones that I try to remember when it feels so awkward to place all js at the bottom.
As scripts that are referred to are being downloaded, browsers typically won't download other files in parallel, thus slowing the page load.
refer: Best Practices for Speeding Up Your Web Site
A Google search will return a large number of results as to why you want to do so and what improvement you'll see. Check out some of these following links:
High Performance Web Sites: Rule 6 - Move Scripts to the Bottom
Rails Best Practices: Scripts at Bottom
Basically, the main reason for doing so is that you'll improve render times of your page. From the first article:
[I]t’s better to move scripts from the
top to as low in the page as possible.
One reason is to enable progressive
rendering, but another is to achieve
greater download parallelization.
depending on what is in the js. if only want it to 'go' when the page loads either surround your code by jquery's: $(function(){}) or place it at the bottom of the page
What is the real benefit of using external css and js in place of placing code directly in ... and in terms of page loading speed?
if we are controlling whole site from one header.php/aspx file? Is use of external files makes page loading faster?
My question is only related to page loading speed.
On a per-request basis (that is, looking at page load performance of JUST one page), speed-wise you actually take a small performance hit by separating the files. But when looking at performance, you get a performance boost when loading multiple pages that utilize the same JS or same CSS. In those cases, the content of the JS/CSS is only loaded once for all requests.
Although you didn't ask this as part of your question, it also helps code maintainability. If you make one change in your CSS and it gets loaded across multiple pages, if you embed the JS/CSS in the page then you have to make the same change across all of your pages.
External files can be cached, and have to be loaded only once even when referenced from multiple locations. This usually outweighs the performance hit caused by the one additional request when the resource is first loaded.
i know you asked about page load speed and from that standpoint id say the greatest benefit id say cacheing is a big advantage but i wouldn't break it into multiple external files (because like first answer said it takes time to make a request) but you also get a benefit from a SEO standpoint... crawlers will only index to a certain point in a page and keeping js and css out of the top lets them see content higher in the page
i just found this article where a guy did the tests
http://articles.sitepoint.com/article/indexing-limits-where-bots-stop
yes, the css and js files will be cached by the browser so they only get loaded once.