I am working on Meteor app(e-commerce site), became very large. It almost takes 9secs to view static part of homepage till then it only shows white/blank screen. After that it starts showing data from DB(mongoDB). The whole site with data takes ~24secs to come at client side. I think the whole bundle is too much huge and that is why it takes more time to download. And it is causing 9secs of white screen. Any solution guys. Thanks in advance!
Alraedy Tried:
1. Fast Render(Flowrouter subscriptions) package
2. Appcache package
3. Query Optimization/Indexing
4. Removed global subscriptions
5. Sending minimal data via pub/sub
6. this.unblock() for publications
7. Not saving files in DB instead saving url's
You are working on an e-commerce website and so you might have a huge admin module bundled with your website. You should consider building the admin module as a separate Meteor app sharing the same Mongo DB collections with the e-commerce website. You can reduce the size of you app considerably using this approach. You can find more details here
You should also be really careful about your subscriptions and use pagination on the server side publications, subscribing to only what data is actually required
For starters, try to remove unused packages which aren't used anymore by any frontend code. Check your entire package.json and all imports.
Reduce the size of all you subscriptions, you probably have tons of them with entire or too big documents, which is easy while developing, but an overkill in production. Try to limit the fields and the amount of loaded objects to what you visualise for the user.
Don't wait for all subscriptions to finsih loading before showing something, load the website and it's design already, but only show a 'loading' icon on the parts that do require data to be shown dynamically.
Make sure your javascript is minified before it's published, this saves a lot of bandwidth.
After implementing these your load times should have decreased.
Providing a detailed network analytic from the debugger of your browser might also help to notcie problems.
Related
I've been reading about how nuxt can generate a static site when a client makes a request to view the website. We are planning to build a headless cms to migrate the database with the data the website needs. This data will only be changed when you save it in the headless cms.
My question is since this data will only change when it is changed in the headless cms. Isn't it possible to just generate the site when it is modified from the headless cms, and then serve that site to the client? To reduce server costs.
Is it possible to do this with nuxt? Or are there any possibilities to do this?
We are planning on using Firebase as a backend.
There's nothing explicitly preventing Nuxt from being rebuilt each time you change an item in your DB. The part that matters is how you tell your app to rebuild itself.
By far the simplest way is using some sort of "build hook". See Netlifys docs here for a quick overview of what they are. However, this only really works if you're using a headless CMS that can send hooks on save, and a build provider that can trigger builds using those hooks.
You will absolutely save on server costs using this sort of method, but beware: if you have a lot of user generated content triggering builds, your build cost can easily outweigh the server costs. You also need to be aware that builds generally take a few minutes, so you won't see instant changes on your site.
The other option you have is foregoing static site generation in favour of SSR, which can dynamically load and render your content, completely avoiding the need to build every time a new DB change is made. This is what I'd consider the best alternative if you do indeed have a lot of user generated content.
It's hard to give any further advice without knowing the specifics of the CMS or build provider though.
I am trying to build and app that sync the posts from wordpress ( data is highly dynamic and can cross 100-500 mb ) to ionic app which uses sqlite. At the same time download all assets to local. I developed an working code that does this. But I have problems to keep things in sync like check for changed posts, assets, etc. Also I have problem to keep track of deleted posts and stuff.
I am looking for alternates say like a library or some other alternate concepts that can help me keep that data in sync add, delete, update as it happens in server (need not be realtime).
Please do provide me some suggestions or ideas that I can try
My company uses SilverStripe v3.1.21, along with the Subsite module to display and administer a number of clients' websites that sell products. This results in close to 200 subsites and a page count in the tens of thousands. The websites are very slow to load and tools such as Google's PageSpeed tell us page speeds are poor. We've already done step like combining and minimising the JS and compressing resources such as imaging, which gave some improvements, however the pages remain slow. The system was handed to us in this state and further hardware upgrades are not on the table as an option, nor are gaining additional resources for redevelopment.
We've taken a look at the static publish module (https://github.com/silverstripe/silverstripe-staticpublisher) and found that when we generating static pages the pages become fast and get a good score on the various tools, however the process to regenerate all of these pages takes over 14 hours, which is unacceptable given these products are updated from an external source daily. We also find that the regeneration process is a memory hog, as the module builds all of the pages in memory before dumping to file, causing the process to crash. We've had to alter the process to go subsite-by-subsite just to make it run.
We then took a look at the static publishing queue module (https://github.com/silverstripe/silverstripe-staticpublishqueue), which seemed to address our issues by having it queue pages as needed for regeneration, making it much more responsive to changes. However, the module seems to be very buggy and often crashes when generating pages.
Has anyone had experience using these modules (or similar) with larger sites and may be able to provide any pointers or ideas on how to implement static publishing successfully?
We are using staticpublishqueue currently on several sites. The only problem we've had with it is crashing due to long builds and poor locking. Or to be precise it doesn't actually crash but keeps spawning more and more instances until the server becomes unresponsible.
I think we have a fix for this in our fork. At least we haven't had any problems after using the modified locking. You could try installing the fork instead of the official version. If this fixes things for you maybe we should make a pull request :)
First of: We only use staticpublishqueue, I don't have any experience in regards to the sub site module. So I can't speak for your exact combination.
We are using staticpublishqueue on a huge site. Setup: We have multiple servers running the SilverStripe Website. They share a MySQL Database and use Redis as a session store.
One great thing about staticpublishqueue: you can run it in parallel. So the servers all run an instance of staticpublishqueue and publish into a shared folder, which is then synced to a nginx load balancer in front of the actual webservers. Works quite nice, but it does not scale indefinitely. At some point the staticpublishqueue instances start to pick the same record to render and waste resources. I think about 6 is the max for us.
Couple of things we learned regarding staticpublishqueue:
do not run to many instances at the same time (see above)
make sure it has enough ram
make sure it runs as the same user as the website
the record look it uses is not compatible with a MariaDB Galera Cluster
If possible switch to SilverStripe 3.6.x and PHP7. The performance gain is huge.
We are migrating away from staticpublishqueue to Cloudflare (or maybe another CDN). Why? Because if a page that is requested has not been rendered yet the server will render it for each request individually and then throw it away. Until the que does a separate render for the cache. Total waste of resources, especially if you purge your cache after a sitewide layout change or something.
I am new to react-native, and I am going to develop an application by using third-party library called react-native-maps. Currently, everything just working find with online map as this third-party library is used google map. But my problem is went I move to offline mode it would be caused a problem for my application.
My question is there any possible way to make google maps downloaded/cached when the application is load with the specific bound area of a country?
Thank you in advance.
As far as I am aware there is not a way to use the react-native provided MapView to cache the map data. At this time the only offline react-native module that supports offline mapping is react-native-mapbox-gl. I have used it in one of my projects and it is fairly simple to get up and running. The biggest issue with this project is it is still very pre v1.0 in terms of bugs. For basic cases it gets the job done.
Another project I have found has a lot of great features and has a snapshot function that I think could be used to mimic an offline map. I have not tried this but I am evaluating it at this time. react-native-maps
It would function as such:
The app can set aside a cache of a maximum size.
As the app requests tiles, these are cached to local storage.
There is an interface on the map object that enables you to cache a particular tile in the map at a particular zoom level.
The app periodically scans the cache and deletes items in LRU order until it gets under the maximum cache size.
Let me know if the maintainers would accept a pull request like this and I can work on it.
I'm developing a mobile site where startup time is a critical issue.
Currently meteor apps load the templates for every single page in the whole app,
and it seems there are no plans to change this before 1.0 meaning there's an initial startup hit. Overall the experience from then on is really snappy, but i'm trying to optimize the first part - esp. on mobile (asia) 3G networks.
So what techniques are people using to reduce the apparent startup time?
Because of the "full stack" nature of meteor i'm not sure how best to approach this.
For example having a separate bootstrapping/preloader page that loads the meteor app in the background (iframe?), then redirects to meteor URL when ready?
Or combining meteor with static site generated pages and disabling DDP for the first few pages?
Any techniques appreciated!
One quick fix you might look at for repeat visitors is Meteor's appcache package. With appcache added:
Once a user has visited a Meteor application for the first time and
the application has been cached, on subsequent visits the web page
loads faster because the browser can load the application out of the
cache without contacting the server first.
According to the specs it is available for most of the major mobile browsers. Of course, it will not help with the initial site visit.
As mentioned by emgee.. fastrender is absolutely worth a look.
This issue has been addresses in Meteor 1.5 by using dynamic imports. See here.