I'm trying to improve the page speed (and SEO) performance of my React app at https://bravos.co. You can see the results of the page speed test here: https://developers.google.com/speed/pagespeed/insights/?url=bravos.co
I'm stuck at 64/100 on mobile and 46/100 on desktop.
I've improved a number of things, but there's a lot that I'm just stuck on, and seems to be difficult to improve give it is a React app:
Eliminate render-blocking JavaScript and CSS in above-the-fold
content (this is mainly the bundle.js, which I can't eliminate given that it's the whole app)
Optimize CSS Delivery (This is relatively minor, but I'm still not sure how to do it in React)
Enable compression (I can gzip some things here, still looking for an easy way to gzip and deploy a random javascript file)
Leverage browser caching (this I can't figure out how to do in React, particularly since .htaccess doesn't seem to be used)
Any advice or thoughts here would be massively appreciated.
Related
I have an admittedly weird question to ask. We are in the process of migrating an existing application over to react. Due to some limitations of the legacy code we are dealing with, the majority of our users are on IE11 in IE10 compatibility mode. We are running into an issue with fairly large doms where the rest of the non react application has experienced maybe a 20% rendering time increase with react not actually rendering anything on the page (though it is still loaded in memory). This doesn't quite make sense to me since i thought that react only keeps track of its own trees. Is there anything else that react might be doing globally that might cause these types of performance problems? I've dug through performance session traces in IE and nothing really jumps out at me as being executed on the react side. Ideally we'd have smaller doms I realize, but we're dealing with some legacy code and that's not an immediate option.
So far, I have been using prerender.io to make my angularjs websites seo friendly. I have worked okay when it comes to urls with hashbangs (website.com/#!).
Currently, I am making my websites go to html5mode, which doesn't contain hashbangs on url and looks a way prettier. However, even since I went to html5 url, prerender.io doesn't work properly.
Also, I came up with a Google article that claims their new technology allow the engine render Javascript framework websites automatically (https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html). However, as I use 'Fetch as Google' tool in Google Search Console. It renders very poorly and my title and meta description spit angularjs syntax ({{seo.tile}} or {{seo.desc}}), which are not rendered.
I am quite lost where I should start and fix the problems I came across with. I tried to get away from prerender.io cause I don't think we necessarily need it anymore.
Sorry for my poorly organized post and questions. Let me try to clear and tie the questions below.
1) Do we still need to teach the Google bot about the angularjs?
2) What is the most stable and best practice for AngularJS+ExpressJS SEO? I don't wanna try unstable and easily crashable method for this.
Thank you very much for your time.
EDIT
At the time of writing this article, I didn't know about using javascript compiler such as babel. I will say here make sure use webpack or gulp to compile your ES6 codes into stable ones so that your codes can be written as you expect it to be and works well with any 3rd party tools or pacakges.
It's the era of ES6!!!
Finally, I solved my problem and for future reference and others who struggling with the sample problem I had gone through, let me leave what I found.
First of all, the very reason why I was tremendously confused was that even if I take html snapshot with phantomjs, I saw still bare angular syntax like {{seo.title}} and . Very awkwardly the reason was that I was using ES6 syntax across my angularjs module. Since phantomjs wasn't fully adopted with ES6 syntax, it failed to interpret angularjs module and just spat html with unconpiled angularjs... From this, I came up with a unexpected conclusion that it's not a good time to implement ES6 for production.
Secondly, I would not count on what Google confidently announced that their bots can handle the websites with dynamic javascript frameworks like angularjs. Even if phantomjs works, 'Fetch as Google' tool doesn't give me a good result. Some times (actually very often) it resulted in just empty html file. Since still Ajax crawling is supported as a 'fall back', but more stable method, I would count it rather than counting on their very unstable smart bots.
In conclusion, DON'T BE EARLY ADOPTOR especially if you are making business out of it!! For angularJS SEO, (1) follow the Ajax calling guideline even if considered to be deprecated, (2) Don't use ES6 syntax for serious programming stuff.
I have a lot of experience with the LAMP stack. I’m about to build out a new site that will be basically a directory, profiles, subscriptions, q&a etc etc. All of it needs to be indexed by Google. I’ve spent the last couple of weeks learning Meteor + React and I’m absolutely in love. It seems like I’d be able to create this new site really quickly with it.
I'm concerned about the initial load and the SEO concerns though. I see there are some workarounds with other packages to make indexing better, but will load time always be an issue?
I don't mind if there are workarounds, I would just hate to build out this large site using meteor just to find out that the initial load will always be slow. Which would wreck conversions (and SEO at the same time). Am I trying to fit a square peg in a round hole?
What jinja2 can achieve, the same can be achieved with Angular.js. My question is- are there any advantages of replacing jinja2 with angular.js completely ?
I think most problems came from the same obvious difference: Jinja2 is server-side, Angular is client-side, this makes they really different.
SEO. Google don't understand Angular magics. It is just a heavy Javascript code and Google can't understand it fine. Sure, you have some workarounds to show your important text to Google, but to solve it you'll have to render some things server-side, going back to Jinja2 or some hack to render things to improve your SEO. (it is not important if you don't care about Google searches)
Performance Server-side rendering is way faster than Javascript rendering. I'm talking about your average user, maybe with an outdated Internet Explorer and a crappy internet connection. With Angular, you have to wait at least some Javascript assets to be loaded before the page is usable. Users notice this and we know a slow site will hit your conversions. Check this Twitter article about "time for first tweet": https://blog.twitter.com/2012/improving-performance-on-twittercom
Compatibility. Yes, they claim the framework supports all common browsers, but have full documentation about hacks to make it work for IE7. Depends of your audience.
Maturity. Jinja2 is really stable, has a pretty API and is deployed with almost all Flask websites. Angular is still evolving and sometimes things just change a lot.
Inexperience. You can't just replace Angular with Jinja2. When you try it, you will understand they are different and you must not work the same way with both. You will make a lot of mistakes before you make things right, just like with any new awesome tool you use.
Of course you can claim against all my arguments based on your specific needs, this is just some things you must understand before you go to Angular.
That said, I'm using Angular in several projects, mostly for single page apps. This is an awesome use case for Angular. In all these projects, I still use Jinja2 to some rendering, so this is not a complete replacement.
UPDATE:
Some updates almost two years after my initial response.
Google is better understanding dynamic rendering, but I still don't trust it.
I don't think the client-side rendering is a thing. Only realtime data is rendered client side, but the base HTML is generated server side.
Angular dropped IE7/IE8 support. It is definitelly a good thing for the web, but unfortunately I still must support these browsers in some cases.
Angular 2 is on the way, changing everything you know about current versions. I don't remember any major Jinja2 change.
Why is replacement your objective? Use the power of both Jinja and other server side frameworks together with the power of client side frameworks.
The benefits of using both:
less and easy code
better performance
more easy to maintain
and much more. You have a choice.
Choosing for one or the other will make your work frustrating and complex.
I'm wondering if anyone has found a solution to this problem. Is there a way to get the best of both worlds:
build a page-based site, with permanent links, accessibility, SEO, and graceful fallback / progressive enhancement (basically all the best practices of web development)
and, for those with javascript, a responsive front-end experience with ajax loading of content, no page refreshes while navigating the underlying site pages, minimal redundant downloading of scripts/content/css/etc. (all the benefits of a client-side framework like AngularJs or Ember.js)
I see a few major sites are able to manage this (gmail, stackoverflow), and I see that Jeff's new site builds a bare-bones version of the site in a noscript tag.
Is the solution to the hybrid page-based/single-page app to build two versions of the site, send both, and let the client decide which it can show? (is this what gmail does?)
Or is the problem that AngularJS et al. are simply not designed to allow for graceful degradation?
It hurts my DRY brains to think that #1 is the answer.
(The reason I am focusing on AngularJs is that I like its support for html templating, declarative style, and its attempts to fix js scoping. Ember and other frameworks are excellent too; maybe one of them would be a better fit for a hybrid site?)
This questions is a bit of a nuanced one because the answer is "it depends". For example you mentioned Gmail, there isn't any reasons whatsoever that an application like Gmail would need to be indexed for SEO, though depending on what you want or need to support you may want to ensure you can support not having Javascript.
However even the "no-javascript" argument is getting tired and weak these days, at least for the class of "web applications". If I want to use a Windows application I need Windows, if I want to use a javascript powered web application it isn't unreasonable to assume that I'm going to need a browser that isn't crippled to use it.
However back to your question I can only speak to AngularJS because I'm the most familiar with it. For the most part it does allow you to support a progressive enhancement approach, though don't expect to use things like URL routing if this is what you want to support. What you can do is use AngularJS controllers, bindings and directives similar to how you might use jQuery as a way of enhancing the interactions and behaviours of the page.
Just keep in mind this approach will seriously limit what you can do with Angular (or Ember for that matter) and it may start to be debatable what you are getting from this approach that you couldn't easily do with jQuery alone.
The alternative these days is to do what sites like Twitter are doing. That is basically serve fully rendered HTML from the server for any view on the initial load and then use Javascript for subsequent loading and enhanced UI behaviour. This is very effective (though perhaps quite challenging to implement) if you really need to support browsing with and without Javascript and has the added benefit of improve the rendering/load times for the first request. Again "it depends" because it depends a lot on how your site actually works if it is possible to use this. You have to design for it, and it isn't going to be trivial or easy.
Update:
For what it's worth we are taking the Year of Moo approach and rendering the pages that need SEO using PhantomJS and sticking the cached initial state of them somewhere to serve them up. We have a rake task we run on deployments to update this. Again this is just the initial state but it helps get around the issue for now.
Things are always changing though and I'm sure I will have changed my mind on this approach in a year or so.
Have you read Google's Making AJAX Applications Crawlable. You can have JavaScript single page app and crawlable content.
If you stick with angular, there is interesting article: Turns out it is possible to have your AngularJS application indexed