I have a page which i would like to use as offline fallback.
The problem is, that in this page i have a ~10 of js/css resources and ~20 images.
It's silly to point each one in precache array by hand.
Also, it's hard to maintain - all resource changes in html template will be affect sw.js.
Is there a option to precache .html page with all resources (js/css/png) ?
No.
You would most likely want to have your build scripts include the static assets in the precache array in your SW. Not by hand.
I have been using Google's method for some time now and has never failed me. SW toolbox didn't give me the results I wanted.
Related
I'm using Vue CLI PWA workbox plugin mode.
My app has more than 1000 assets, and precaching them results in very bad performance. Please, check it out:
https://nikudu.com/
Is there a way to precache files more specificly?
For example, precache files by URL.
On url x/y only precache files 1,5,6 and on url x/v precache files 7,8,2.
I have worked with PWAs and Angular, so no experience with Vue. That said, I would suggest to pre-cache only your shell app (hence the minimum static assets/js that you want to present to the user, when accessing the app offline).
For the other images you can use a lazy approach and cache the images only after they have been requested once (but I do not know if this goes against your requirements).
From this point you could even expand your logic to define, which are the most used routes and preload only those images in the background, once the user lands on the app.
If you are interested, I wrote an article about Service Workers and caching strategies independent from Angular, therefore you can use the same concepts in your app too.
I am creating a mobile singlepage web app using jquery mobile. The webapp includes a number of javascript files and a number of css files. I have written a deploy script that concatenates and minifies js and css files, and now I am wondering whether I should inline the concatenated js and css directly in the HTML file - please note that I am talking about a singlepage app here (I know that this would be a bad idea in a traditional web 1.0 app with dynamically generated HTML). I am also using appcache/manifest file to cache the singlepage app so that subsequent access to the web app will be served from the cache, so it is the initial load time that is my primary concern.
When I inline everything (jquery, jquery mobile etc.), my 7kb HTML file increases to 350kb (100kb zipped) but now everything can be loaded in a single request.
But am I missing some other benefits such as parallel downloading of js files - and would it therefore be better to not inline the css and js, but instead just concatenate all js and css to a single js file and a single css file and then fetch each of them in separate requests?
Are there any limits regarding file size that I should be aware of? Maybe caching in network routers works better with smaller file sizes or whatever?
So my question boils down to whether it is a good idea to inline everything when making singlepage mobile web apps?
The answer to how much should be concatenated and how much should be inlined varies depending on a number of conditions. The final answer is you should do A/B testing and find what works best for you. From what you describe I recommend you definitely NOT inline 350K of CSS & JS. If you do this then any change to the HTML or JS or CSS requires downloading the entire payload. Instead, compartmentalize those changes and forced updates by keeping HTML, JS, & CSS as separate requests. You could do dynamic | inlining to make the first response fast but leverage (app or localStorage) cache for subsequent requests, but that's going to get complicated when coupled with app cache (because the HTML doc is saved to app cache). Otherwise, just keep them separate, save each resource to app cache, and update individual resources as needed.
I would not recommend inlining everything into the html if your webapp could be accessed from different urls with different querystring.
Example :
http://webapp.com/?fb_token=fdsf
http://webapp.com/?referer=bla
http://webapp.com/?tracker=toto
Each of those will add a master copy in the appcache (you can veryfy it by looking at chrome://appcache-internals/ in chrome). You then risk to reach the quota limit for appcache in term of cache. Furthermore on appcache update, the browser goes through its appcache entry list and ask a fresh copy of it.
A good compromise that i am following for mobile device & appcache , is to keep the html tiny and then have one big css (containing base 64 inlined images) and one js file.
FYI, there is currently a quota limit on the size on the sum of all your listed resources in appcache in the order from 5MB to 25MB (25 being the new iOS6 limit)
-seb
I have a caching plugin that creates static html pages from my php/mysql driven site.
On the homepage I've a listing of content <ul><li>content</li></ul>
I've a drop-wdown (select), that loads different set of content.
Obviously this isn't playing well with caching plugin.
I'm don't have website yet, I'm in the thinking phase and I'm trying to understand what problems I might face... could you help me with this little part I explained above?
Not 100% sure what you mean; but you should be able to stop browser caching by adding a random GET variable into the URL. Like time() for example; your browser should see it as a different page.
I have built a test website using nopCommerce open source , Everything is working fine , i need to know , why my website loading time is greater than 6 sec , the homepage works fine but the categories when clicked takes like 6-10 secs. how can i check the http request and calls to db so that i can track which function is taking a long times.
Test website is test website
Thanks
Things I would try in that order:
MvcMiniProfiler.
Analyze my code for possible performance bottlenecks using a .NET profiler.
Finally submit bugs to the nopCommerce support if the previous approaches didn't yield anything fruitful that would put my code into cause.
In between I might also checkout with my hosting provider whether he is not the cause of the slowness.
As a quick and dirty check, you can add the time it takes to generate the response as a column in the IIS logs - that will give you some idea as to whether the server is being slow to serve the pages or you need to do some front-end optimisation work.
On the front end side the first thing you need to do it merge all the CSS files for a theme into one to save on roundtrips - the browser can't render the page until it's got the CSS
All the .js files you have in the head will also block the page, can you merge them and load them later?
The performance of imagegen.ashx looks on the slow side - do you need to generate the banners on the fly or could they be pre-generated?
If the back-end side of generating the page is slow, there are some scripts around the web to show which queries are using the most CPU, making the most IO ops etc.
Below is a list of things you can improve,
1.Combine your js.
There are a few things you can use, for example, jsMin, you can read this [post] http://encosia.com/automatically-minify-and-combine-javascript-in-visual-studio/. However, jsmin doesn't seem to compress the combined js.
Another option is [jmerge] http://demo.lateralcode.com/jmerge/ It kinda does it after the fact, in the sense that you need to have the site ready to cobine them with jmerge since it only take a http link.
The best one I'v known so far is bundling and minification feature of MVC4. It's part of MVC4, however, you can get a Nuget package for you MVC 3 app.
Word of advice: bundling every js of yours is not necessarily a good idea, it even backfires someimtes, since you will end up with a big js that browser will have to download sequentially, instead of downloading several smaller ones. (you might want to look into head.js to make js download parallel) So the trick here is to keep the balance. I end up have a jquery from google CDN and bundled the rest of my js into one.
2.Put js at the bottom of the page so the browser doesnt have to load the js first before it starts to render the page. But you need to be careful with this one though, since normally you will have jquery functions doing stuff upon document.ready() at the header of the page, I adviese you moving that to the bottom of the page as well, if possible.
If you move the js reference and scirpt block in you layout page to the bottom, then you will most likely run into problem with nested js reference and js script blocks in your individual view. No worries, then you need to look into using #section (probably suitable for a discussion in an other thread) in your view and render it in your layout page, so that the referenced and script block inside your view get rendered at the bottom of the page at run time.
2.Use CDN
Pretty straight forward.
3.Combine CSS
Combine them into one, with the same tool you use for combining js, but you need to reference it at the page header, instead of the bottom.
4.Enable static content cache, something like this in your web config file
It won't help with first time load, but definitely will make it a lot faster for returning user.
5.Enable url compression
Time to first load
This is one of the metrics used by webpagetest.org. But dont bang your head against this one too much, as it basically says how fast your web server can serve the content. So probably not much you can do here form the software end.
Hope that would help!
NopCommerce is deadly slow, and the developers doesn't look in to the performance issue seriously. I have seen lot of performance related forums left unanswered. So best luck.
I am using HTML5 offline storage. The goal is to make the whole site available offline. So intuitively, no server requests means all the pages need to be on the client. The only way I know of to accomplish such a task is to make the site into one page then show hide portions with jquery when the user "navigates". Is there a better way?
The html 5 offline spec allows multiple pages to be saved offline so you don't need to put all your content onto one page.
EDIT: link to spec http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
Be careful that your jquery does not still point to the cloud. You'll need to save the relevant .js files locally.
N.B. If your whole site can be generated and saved as individual .html files then all you need to do is to save these files in the correct (relative) directory structure.