Friday, June 9, 2017

A different paradigm to bump up your site performance

You might have seen ample number of blogs, information and other resources out there that talk about the same topic.  But, I will try and make this in steps, so you have step-by-step guide all in here and you will surely spend less time scraping this data from 10 other places.
At the end, I will also list references on where I gathered all this from, so, you can refer and read more if you are an enthusiastic reader.

Have you heard about Google page speed extension?  If you did not, it is fine and I will not say you were living in a cave, in this functional desire world, I wonder why performance is always addressed at the very end of the tunnel in software life cycle.  I would go ahead and say a simple performance test plan should be part of every step of implementation.   It could be simple, but invasive.  It would help mitigate surprises which usually take time to resolve.

There are tons of tools out there as well to measure performance, but, I got hooked on to Google page speeds extension as it is easy to visualize and Google does do a good job of providing links to problems that were uncovered which would provide good insight to multiple solutions to the problem on hand.

Let us get this started -

1. First do not expect anything,  don't assume that your site is great or worst in terms of performance.  Just download the extension of your favorite choice, I like the Google Page Speeds extension, but, you could run anything
2. Address to one's Google put's more weight on and are in red.  I think that would be the critical one's for sure.  I did the following and saw immediate boost on numbers

Images and Images (Scaling and Optimization)

Firstly ensure you are scaling images on server side (Using Glass params) instead of depending on content authors to upload files of certain dimensions.  Though we tried to enforce this through documentation and collaboration, we still saw lapse.
Best way to battle this is use Glass params, then, regardless of whether recommended size is respected or not, your browser will not spend ton of time sizing and re-sizing images to fit your FEE needs(css)
Get the params based on FEE recommendations, the best thing to do is set width and let height be auto.
Example :@RenderImage(carouselSlide, m => m.Carousel_Image, new { @class = "carousel__image", w = 684, width = 684 }, true, outputHeightWidth: true)
Please re-upload all imagery that is not respecting the dimensions.  This is important for performance and critical 
Also, ensure good/web optimized imagery is loaded on to media library.  If tool complains that some images could do better in terms of performance, please re-upload the culprits.  Should be quick and the tool offers a download option on each of the offensive currently uploaded image.  Go to sitecore editor and do simple attach/detach.  You are done. 
Make sure all your site specific css/js is minified and only those minified versions are accessed in your HTML or view code


Ensure web server has compression enabled.  This is a simple check of a checkbox available on IIS under compression for a specific site(Ensure static compression is checked).  Sometimes, if installation is not done correctly even if you checkbox this it might not work.  Please ensure this works by looking at Network request and content-encoding attribute is being set as 'gzip'.  You can check in fiddler or on Google chrome by toggling the column display to show this response header.  If you dont see gzip, please check with support once you ensure you have enabled the IIS settings properly and things seem off.  This is v important for performance and must be ensured is working 
Enable cache control on static resources on web.config to ensure you enable this after talking to your FEE team on what would be a good max age time.  It could vary based on multiple things and should be verified with your team.


After these steps, please follow sitecore performance tuning guide no less than Bible(link in references), go over all content delivery preferences and ensure you set all of them correctly.  When in question about something please check with your support team.

That is it, you just made your sitecore instance super efficient.  The tuning guide should also cover caching best practices which should bump up good performance benefit second load on wards.

Happy Sitecoring!!

Few Good References

https://developers.google.com/speed/pagespeed/insights/
https://sdn.sitecore.net/upload/sitecore7/70/cms_tuning_guide_sc70-72-usletter.pdf
https://chrome.google.com/webstore/detail/google-pagespeed-insights/edbkhhpodjkbgenodomhfoldapghpddk?hl=en
https://developers.google.com/speed/docs/insights/EnableCompression




Friday, June 2, 2017

Deeper dive in to Coveo Advanced Expressions

In our implementation we stumbled upon looking at what Coveo calls 'aq' bunch of times.  It is simply because of complexity involved on our implementation where we had to bend Coveo a little to achieve what the business needs are.

First up, let us first understand a little what is aq, dq and cq per Coveo.  They have beautiful documentation that iterates what these are.
https://developers.coveo.com/display/public/SearchREST/Query+Parameters

So, every time a query is fired by Coveo rendering because of coveo components you have on the page.   All these query parameters based on what is applicable is generated by Coveo, you can see this on Network tab in your browser when you take a look at Request headers and parameters.  If what coveo generates satisfies your business goals, you are good to call it a day.  But, what if it is not enough, you have to then modify and tweak to achieve what is needed.

When it comes to modifying the aq generated gracefully it becomes a challenge specifically if you are having issues with what Coveo does inherently while computing 'aq' for a rendering/request
One such case happened recently, where we needed a disjunction to be applied at a specific piece of generated 'aq'.  We obviously could not get away with disjunctive expressions, I talked about this in my previous blog if you are curious.

https://deepthikatta.blogspot.com/2016/11/coveo-facet-slider-across-two-fields.html


The reason why this approach would not work in this case is because the way disjunctive expression works and is interpreted by Coveo in final query is aq OR dq which means in result set you will find all items that match your filters appended by Coveo in aq OR that match your expression that you added on dq.

But, what if you want this disjunction to applied only on a particular facet or custom advanced expression.  How can we do this? is it possible?

Like always, everything is possible. :)  In our case, it is little more complex because we also did not want what Coveo typically injects as a piece of aq on a Facet Slider for example because we would fall in to same problem which we began to solve if we don't do this.   So, to achieve this, we did two steps.

1.  OR where you need - In event called buildingQuery, access the args and append the advanced expression that you need including a specific OR condition you care about.  Some thing like
 Coveo.$('#@Model.Id')
        .on("buildingQuery", function(e, args) {
            let mySlider = Coveo.$('#mySlider')
              if (mySlider != undefined) {
              let optionsOfComponent = mySlider.coveo().getSliderBoundaryForQuery()
               if (optionsOfComponent != undefined && optionsOfComponent[0] != undefined && optionsOfComponent[1] != undefined) {
                let fieldOneQuery= '@(Model.ToCoveoFieldName("field one")) >=' + optionsOfComponent[0] + ' AND @(Model.ToCoveoFieldName("field one")) <=' + optionsOfComponent[1]
                let fieldtwoQuery= '@(Model.ToCoveoFieldName("field two")) >=' + optionsOfComponent[0] + ' AND @(Model.ToCoveoFieldName("field two")) <=' + optionsOfComponent[1]
                args.queryBuilder.advancedExpression.add('((' + fieldOneQuery+ ') OR (' + fieldtwoQuery+ '))')
              }
      }

         })
2. Remove the advanced expression added by Coveo -  Reverse engineered the string that Coveo would append on the facet slider per configuration and removed it using helper provided under Expression Builder.
https://developers.coveo.com/display/public/JsSearch/ExpressionBuilder

Some thing like -
 .on("doneBuildingQuery", function(e, args)  {
   //reverse engineer the value you would like to remove and ensure you have proper checks on coveo      components or facets before you access the values
    let  expressionToRemove  = '@(Model.ToCoveoFieldName("your slider         field"))=='+optionsOfComponent[0]+'..'+optionsOfComponent[1]
    args.queryBuilder.advancedExpression.remove(expressionToRemove)
   })

That is it, we got what we needed when took a peek at Network tab and request parameters and the results matched to business goal.   One less thing to worry about.  We are launching this thing soon, totally psyched!