Is there an alternative to meteor's spiderable package that caches the phantomjs-rendered pages? I have a site with over 50,000 pages. If I use spiderable then not only are the page load times higher than they should be -- which affects search engine performance -- it also bogs down my machine.
I'm OK forking the spiderable package and adding a caching function to it, but if there is an alternative then I'd like to hear about it. I don't want to use the server-side handlebars package, and also Arunoda's great new ssr package is not quite for me, because it would still require a good amount of reworking on my app.
If your pages don't change often, you could put a caching reverse proxy like Varnish in front of your Meteor app. This should relieve a lot of strain on the app itself.
I went ahead and created a cached version of the spiderable package.
https://atmospherejs.com/chfritz/spiderable
Related
People often suggest CDNs for public library. The one I read today goes like this:
It's recommended that production applications utilize CDNs for common
libraries like AngularJS
https://learn.microsoft.com/en-us/aspnet/core/client-side/angular
Why it is recommended so?
One thing I can think of is, since the content comes from different domain, the browser specific limit for number of connections to a domain will not be a bottle-neck for loading scripts if multiple such libraries are being used. However, this can be solved by combining scripts.
Do you know any other benefits?
The answer you provided yourself is in-fact a good reason as to why you should use a CDN. Another reason which you overlooked and is dependent on how the CDN is structured is that, if the library gets updated, anyone using the CDN version will get the newest version with no hassle(obviously this wont work if you are referencing a file which has a version number directly i.e. jquery-1.3.2.js).
If we have more number of packages in the Meteor Application, Is it going to effect the application speed ? (Like the server side operations and loading time).
-Thanks
I think it just needs a little more time to load all the packages and start your app.
But if you manage your publications and subscriptions properly, and don't load unnecessary data when you don't need it, you should be good.
I'm trying to better understand user experience by seeing what users are doing on the site. There are various tools out there that will work to track the clickstream, and record pageviews, generating heatmaps etc.
However, they don't seem to work with meteor. Since meteor is not even using ajax - it's data over sockets - and I think the tools do not support this newfangled magic.
I was wondering if anyone has found a remote recording/click tracking tool that works with meteor?
For example:
- http://www.luckyorange.com
who have a note here about hooking into the browsers XMLHttpRequest.prototype.open but that's not gonna work with meteor and more socket level protocols, it seems.
mouseflow.com also just recorded a white screen.
crazyegg.com doesn't even support ajax.
There are some other mobile specific tools like:
- http://www.uxrecorder.com/
but that would require native SDKs. First off I just want to put this up for the web.
There's one company https://lookback.io/explore who actually develop their desktop site in meteor, but they are mobile/iOS only :(
it's quite time consuming to try these out so it would be good to know anyone else's experience, eg:
http://www.getapp.com/alternatives/mouseflow-application
How are people doing remote usability testing of meteor sites?
Mouseflow does work with Meteor, though you might need to enable some extra features in the Mouseflow dashboard. The most notable would be the enhanced tracking mode, Session Support, which is necessary to track Meteor pages.
Additionally, it might be necessary to block some scripts from being loaded in playback, but that is something the Mouseflow crew can easily do from their end, if you contact them through the support links.
Disclaimer: I work for Mouseflow
After trying all the tools, I found inspectlet
http://www.inspectlet.com/
and had no problems integrating that with meteor. It's a new tool and seems to be designed from the start with Single Page apps in mind. Overall their tool is quite minimal but does the job really well and seems to work flawlessly with meteor. They're also a startup and were very responsive on other questions.
I created a small wrapper meteor package around Inspectlet and other a few other useful metrics toolkits, if anyone is interested I'll publish it to atmosphere (let me know here).
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.
I've implemented a view in Drupal, with 'Ajax' option enabled.
How could I increase the speed of this website ?
it is a bit too slow... is this a normal speed for drupal ? (to open an article, load the content, filter the content...)
Update:
1) Also, saving the view settings from the back-end seems to be very slow
2) Filters (the first 2 are exposed, so they are not applied)
Search: Search Terms required [Exposed]
Taxonomy: Term exposed [Exposed]
Node: Type = Project
3) The links with titles with special fonts are not working (sorry, I haven't fixed this bug yet)
Caching my friend.
Try Boost module, it gives a great "results vs effort" ratio.
If you're still having issues with performance, move on to Varnish.
Your ultimate source for Drupal optimization should be: http://2bits.com
Drupal is taking 9 seconds to answer for me on this page. That is unreasonably slow for Drupal under most circumstances.
Use the devel module to find out if it is the database or something else that is the problem. Enable the Drupal cache, if not already enabled and also enable js/css aggregation.
If only this view is the problem, then the generated query is probably horribly inefficent. You should analyze it and maybe override it with a better query and/or set some appropriate indexes on the involved tables.
If possible, install APC (php opcode cache) on the server, that helps with php speed.
Memcached can help a lot, but installing that is a bit more involved.
As already mentioned Boost gives an extremely high improvement if you have an infrequently updated site. It won't help for registered users, only for anonymous ones.