Currently my website's build time looks like
I do not understand why all of my routes have very similar load time, even when their content differs?
I am trying to understand the concepts mentioned in this article and this one.
My gut says that I need to understand how bundling works and why it came into existence webpack intro source and then tackle the problem.
Am I on the right track?
All of this is to increase the performance of my website.
Do I need to use dynamic imports, lazy loading, etc. How do I plan my actions? Is there a roadmap to follow? Lighthouse report confused me.
Related
The Chrome Dev Tools JavaScript and CSS Coverage Drawer is pretty neat, except for one thing... It would be nice if it could be left on, and not reinitiate its analysis between pages.
I would like to be able to analyze an entire site, a subset of pages, or a set of websites, and find what is unused amongst them.
I get that it would mean browsing entire projects and using every feature (or setting up tests) to be thorough/precise, but that's not as tedious as what I have to do entirely without such a utility/feature. (And it doesn't seem like you would need to be meticulous to obtain usable or initial observations from a sub-thorough audit. The DevTools utility doesn't facilitate automated tests on its own either.)
The codebase at issue is huge (1.9mb uncompressed on the front end), and (possibly) contributed to by many developers who may or may not have left relics, legacy code, or abandoned dependencies. There is possibly also code that is only relevant in parts of projects, which could reveal opportunities for reducing dependency scope.
Is there a way to begin to crack into code use without a laborious manual deep dive?
It was one of the first things that came to mind when learned about the Google's coverage utility, and I assumed it would be capable of analyzing multiple pages collectively, but it doesn't.
Is there anything else that does this? Does any utility exist that can search an entire site or multiple pages and find unused JS and CSS?
Side note: The CSS is in SASS. For that and other reasons I may need to manually analyze the results and improve the code, which is trivial comparatively, so I'm not looking for a feature to automate code improvements. It's a similar situation with the JS which is minified.
This is not a request for a recommendation on poduct/software. It is asking if task X is possible, which is technically answerable with a yes or no.
UPDATE: It does seem like there are utilities for CSS, but still nothing found for JS.
For Static Analysis:
Try unusedcss.com to analyse unused CSS code across the entire website. More - Helium CSS
Try deadfile which is a simple util to find deadcode and unused files in any JavaScript project.
For Dead-code Removal:
Try purgecss to remove unused CSS code from your project.
Try Google's closure compiler which parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.
That being said, detecting unused code is a hard problem to solve, because there are countless ways to invoke a given piece of code. Hence, these tools wisely and with your best judgement.
Imagine you are developing a big-scale nuxt app that has 100 routes. what is the best solution for managing routes (not micro-frontend) in this app?
What do you mean by this?
or should add all of them in pages directory?`
Here, we're talking about pages only, right? So /user/id, /post/id and so on?
If it's the case, you could have a /_entity/id or even a /_entity/_slug for more flexibility (with _entity being either user or post etc...).
If you have a lot of various pages like /about, /our-team, /careers and so on, I guess that those will need their own SEO, content and are totally legit.
I don't really see why this would be an issue at all. It will be properly organized, scalable and will not have too much abstraction neither (which is important IMO).
You could also export some of those pages into .md files thanks to nuxt/content and import them into the pages. Like the Nuxt documentation is doing.
If you really need to simplify those, yeah you could make the whole templates dynamic and generate the markup on fly. This could introduce some huge complexity that may not be needed IMO.
Also, layouts, slots and render functions can be a solution too I guess.
I'm not sure if micro-frontends (sounds like a buzz word for me) are actually several instances on Nuxt one next to another (sounds like a terrible idea if hosted under the same domain) or just "component-ization" of your non monolithic fullstack app (pretty much how we build websites for few years already).
But for me, if a project do have 100 pages, it is totally fine.
Of course, having some hardcoded /blog/post/1, /blog/post/2 is bad (lol) but a large app could be totally fine. It may create some issues regarding the build time and so on, but this is another subject and relies more of the way you do generate the project.
So yeah, if your interviewer wanted to go deeper than those approaches, you would need more details from him to exactly know what are the challenges and what could be used.
TLDR: as far as I know, no frameworks aim to reduce the number of pages because this is not an issue by itself. 10k Nuxt pages will not make your /about one slower by any means (if it does, the issue is elsewhere).
I am creating an extension for the first time and I saw some extensions on github like this one and noticed that he coded his extension using a boilerplate. To be honest, I didn't even knew that you could use boilerplates (a friend told me), it's my first time reading about it.
I wonder if I should clone some github repository and copy paste my files and work in it. I see that there are some boilerplates that give cross-browser support for your extension.
I am a little bit confused as I don't know if this is the right way to do it. Right now I don't need something huge for my extension because it's a simple one and I'm learning how things work (kind of new to webdev). I might want to add some google analytics to my extension later.
Would you advise me to use some boilerplate? To me it looks tidy but I can't understand most of the stuff that's happening around, would be difficult to modify some files.
Also, most of the boilerplates are for react, is there one that is like the most basic one for vanillaJS... like how can I find the one that is used in the repo link on top of the post?
I'm working on the first production release of a large site developed in PHP (Phalcon), MySQL & JQuery. It's not API based although there will be an API available for some things. The slightly dated stack is due to the fact that the project was first prototyped years ago and for reasons I won't bore you with, it's taken years to get to the production development stage.
I realise that hard page reloads are so last year, but they also make sense in an application of this scale when navigating to a different section that serves a different purpose. As it works at the moment, once you get to a section, it pretty much behaves like a single page app using hashed URLs and ajax to change the content in one or more containers etc. especially where SEO is not an issue. This is all currently done with JQuery which is starting to get a bit messy and unmaintainable. There's also features such as notifications in the nav bar etc that appear on every page on the site, again updated and displayed via ajax.
My expertise is in PHP. The same can not be said for Javascript! But it's clear that JQuery alone is not enough. I need a JS framework to handle templating/binding, local routing to a reasonable depth and http etc. with an MV..? structure to better organise the JS side of things and keep it maintainable. I greatly disliked Angular 1 and quit learning it as soon as I found out that Angular 2 was about to come along with major breaking changes. I tried Angular 2 beta and although better, it just doesn't float my boat. I had previously stumbled upon Aurelia alpha and although I didn't have a chance to play with it, watching the vids and reading about it, it seemed like a very nice bit of gear - nice syntax, designed for the present and the future and so on. Now at version 1 beta there's more documentation and resources available to learn it, and I feel fairly comfortable jumping aboard early and using it in this project.
I'm pretty much aware of what Aurelia can do, and I have a lot to learn. However, my big stumbling block at the moment is figuring out how to structure it and incorporate it into this project.
Integration
Each section of the site will need different Aurelia apps
Multiple Aurelia apps may be needed per page
Some Aurelia apps will be required on all pages
I found an article by Patrick Walters which seemed to explain how this could be done by naming the app when you call it on the element;
<body aurelia-app="main" start="app">
Then setting up a shared main.js with;
aurelia.start().then(a => {
let start = a.host.attributes.start.value;
a.setRoot(start);
});
That seemed to make sense so I tried it, but placing the call in a div instead of the body. That doesn't work as host can not be resolved to anything (my IDE told me that before I even ran it). We don't need hostname/port info here, so I presume the author means to replace host with the element? But how exactly?
Any further advice on integration like this would be much appreciated.
I have seen answers to similar questions on SO, but they do not seem to reuse main.js but duplicate it instead which doesn't seem right.
Structure
I played around with moving files with src to subdirectories to split things up into some clear structure. The only way I could get that to work was to add a named path for each in the config e.g. "welcome*": "dist/welcome/welcome*",. Is that the best/only way?
I don't think there is a right answer for your question. Only you are capable to decide which strategy fits better in your situation. As far as I can see, you can achieve this strategy with Aurelia. However, I'm not sure about the reusage of main.js.
You can load an aurelia app inside an specific tag using:
aurelia.start().then(() => aurelia.setRoot('my-root', document.getElementById('some-element'));
If you want to load more than one app in the same page, you'd need 2 main.js files. This thread Multiple Aurelia apps on one page has a very useful example of two apps in the same page.
In my understanding, apps that share the same page should have one project structure, it means only one config.js, src folder, dist folder, etc. Apps that do not share the same page should have a different project structure, with a different config.js, src folder, dist folder (a different Aurelia version if necessary). That guarantees the independence of one app to another, preventing breaking changes.
Of course, that is only my opinion. You can wait for the aurelia guys for further instructions, they are always around.
Hope this helps!
I have been developing phonegap applications that need to make updates oftenly. The problem is pushing a new ipa to iTune Store take too long. So, I uploaded the application source codes(minified javascript) to my server and download it from application and "eval" the minified js files. But i feel using eval has limitations and also not the right way. So, can someone tell me the right way to accomplish this.
thank you so much.
I'd love to have something like this as well. You're already ahead of me w/your eval() approach - but I'd have the same concerns as you there. Here's what I'm aware is out there on this topic - hope this helps?
IdeaPress(?)
I just recently caught wind of this one - not sure how feasible but it claims to do exactly what we'd like. I have to say the main site looks a bit flaky but I will definitly be checking this out to see if it's feasible or not.
HockeyApp?
HockeyApp (possibly dead-end now). I thought there used to be a pretty clear solution for PhoneGap devs to integrate the HockeyApp API/feature set with their mobile apps but a recent Google search on this is turning up much less than I would think - so maybe it's a dead end now? http://goo.gl/GQOv5o
org.apache.cordova.file
This requires more work and I haven't pushed far enough yet to see if it truly could be a means of updating the app post-app-store-deployment. But based on what I've read if you're just updating code for your WebView you shouldn't have to worry about App Store rejection or anything. Related tutorial
Testflight App Testing (Apple)
I haven't gotten to play w/this yet but sounds like it could be promising for at least the beta/testing phase of development. I, like you, need a solution for end-users, not app testers, but I'll still be looking into this soon as it might replace me having to maintain my own over-the-air app installs for the best/testing periods.