24

I don't have a benchmark but it seems to me SharePoint Online is getting slower.

This is a fresh new SPOnline Tenant, (News) images being pulled from a Picture Library

Is it me or is this just super slow?

Accessing REST endpoints is not much better:

The new kid on the block: a SPFx guru

And now a hip and happening MVP (from a competing company) tells my Client all the (Vanilla JS & Angular 1) Front-End dev I did in the past is oldfashioned and SPFx is going to be blazing fast...

Now I am not an MVP, so my knowlegde is limited (and my Client now thinks I know less than MVPs)

Questions:

I have to decide if I am going to rewrite "old" code to new SPFx style.. or if I can just do a SPFx wrapper around a 5000 line library.... because that 25 millisecond gain React does is nothing compared to seconds download

  • Is SharePoint Framework going to have influence on the download speed of assets?
    or access time to REST endpoints?

  • How can we speed up dowloading Assets and accessing Endpoints?
    Apart from all the usual package size and OData verbose/nometadata stuff

It is the very first request to sharepoint.com that is the biggest culprit:
(You have to wonder why the Chrome team used that green color and not red)

I know this is security, menu, etc. This is just a basic site, couple of News messages, 13 department subsites.
Besides 13 years SP, also having a WordPress background, this is just slow.

iSPEED iREST

  • I love your style :) – Sergei Sergeev Jan 31 '17 at 12:57
  • 12
    I'm quite confident you already know the answer (no framework will improve assets loading time), and you only want to be backed-up by the community on this! :) Also, I'm probably as "old-fashion" as you since I only see all these "new amazing frameworks" as all fibs and very complex plumbery to display "Hello world". – Evariste Jan 31 '17 at 13:02
  • OMG, this is getting Trumpish.. I now get direct (flame) email telling me TypeScript/React can create DOM elements faster than JavaScript can... – Danny '365CSI' Engelman Jan 31 '17 at 16:33
10

"tells my Client all the Front-End dev I did in the past is oldfashioned"

Depends on what you did and what he is talking about... in my perspective SharePoint is going client side just like its Windows operating system because of loading speeds. That being said the key here is to look at the trends in what is being picked up at a fast rate. The framework that has gained huge momentum over the past couple of years and hasn't slowed down is AngularJS 2 and MVC. React is good and is down to preference. So far Angular seems to be the best choice for adoption and you can just see it in the job market. Most ask for angularJS experience or knockoutJS.... by far jQuery simply still the best adopted but Angular is catching up. Doesn't matter what any MVP or master would say it's what the masses want to use will decide the trend and how easy it is to adopt as a dev language.

enter image description here

To the issue at hand. How are you loading the images.. problem with SharePoint Online like any website has to do with the ISP load, the assets on the page like your images your pulling from a list and the fact that you're more than likely on multi-tenant mode so the more tenant you have and how many clients are loaded onto the server at any given time will effect the performance. Going dedicated would be the solution but is very expensive so the solution would be to use other techniques to get the info you need.... have you tried JSOM instead of rest to query? also in code its best practice to load the page first and then query for data using rest to give a more realtime effect and feel.

Speeding up SharePoint for downloading assets is vast in the techniques like using smaller sizes to delay downloading and object cache:

https://support.office.com/en-us/article/Tune-SharePoint-Online-performance-f0522d4a-fbf4-41f9-854e-c9b59555091d?ui=en-US&rs=en-US&ad=US&fromAR=1

The fact you mention rest, I presume it's webpart or app on a page that is getting data from rest calls? Update your rest so it returns less data in a controlled manner if possible and index columns within the list or utilize SharePoint automatic index management feature.

Sorry to be vague but need to be a bit more specific on where the issue is occurring if it's overall or on specific pages/lists.

Just to make it clear in SharePoint Online and 2016 the rest services have improved and are likely to stay! If you want to know what happens in the backend well this happens:

enter image description here

Maybe this MVP is privy to upcoming tech from Microsoft that Microsoft hasn't noted in MSDN but to my knowledge rest or csom is the correct call with batch processing as one call regardless of what container I use be it in a webpart, iframe or SPFx webpart. SPFx still uses REST or Webhooks to get/post data.

As I noted that your issue is not what you're using but how you're using it. Yes SPFx will increase load time as it's not an iframe but you can run just like an approved add-in but this is purely the loading of the SPFx webpart that is used within the page (not how it gets the data). As an example running SPFx webpart vs add-in app side by side that both do nothing.... SPFx will win as it's purely clientside when run with. If you were to get data in both of them to render images that the call will still be the same using either csom or rest. So yes SPFx will be slightly fast as its container is JavaScript based so the initial loading is faster but getting the data is still the same and so is rendering unless you code it otherwise as noted earlier in my post.

Have you tried other browsers and at different times to load the page? as noted apart from above the only other thing you can do is go dedicated which Microsoft would love you to do.

Now you have posted an update, I can see it's not to do with your code but rather the server itself. As noted in my last comment at the end it has to do with server load and how many tenants are on the virtualised server at that given time. If you were to run the test again now has it improved or run it over the weekend has it improved? If it does than you can't do much about ttfb as that is back end and to do with the server. I would say get a better package, just what Microsoft wants. Also Angular2 has improved vastly over Angular1 and if it's such as massive issue with DOM updates than there are others just as good as react if not better than have just come out like Incremental DOM (yes another Google product). Businesses like AngularJS and Knockout but developers seem to adopt React but these days it's not much different unless the project is big and complex then it's important to choose the right one.

EDIT

as this is still widely read by the masses and voted on I thought i would update it.

I would assume the reason why the mvp has chosen react and suggesting react is that Microsoft has chosen it rightly so as its container based. That is why they have made the appfabric components available for you:

https://developer.microsoft.com/en-us/fabric#/components/

so seems that its Microsoft's preferred choice but you can still use multiple frameworks with each other.

I would be more concerned about learning TypeScript and how SPFx works. Then I would learn CDN and Azure. Once you have that you could make just about anything with any extension but even myself my preference has been React for its simplicity and speed. Other extensions are faster but little adoption which is key in trends:

king of the crops javascript

enter image description here

Just look at Emperor TypeScript in green! so to overtake javascript at these breakneck speeds once adopted properly!

enter image description here

  • I corrected it in my explanation. This is SPOnline. Coming from a (Gopher) Front-End background I have applied all the usual optimizations (including putting standard images Base64 encoded in HTML source files) My question is (because Clients listen to MVPs and now think I am the old geezer) ► Is SPFx going to increase these access times? – Danny '365CSI' Engelman Jan 31 '17 at 12:12
  • SPFx would improve speeds. Have you tried to run the rest call on its own to see how quick it loads in browser? SPFx with typescript coupled with angular or knockout seems to be getting traction and considering you can get an IDE for visual studios is a bonus. – Ali Jafer Jan 31 '17 at 12:31
  • 5
    I believe one aspect of the question is how is a simple jquery/javascript ajax call made in a script editor webpart different from a call you make using spfx webpart ? – Gautam Sheth Jan 31 '17 at 12:44
  • 3
    I have used SPFx, and contributed to PnPCoreJS. My question is: When an MVPs says SPFx is going to increase performance (to the same endpoints), is he talking poop or not? What Front-End technology is used has nothing to do with this. IMHO The only way that SPFx can be faster is IF it is going to call different endpoints (we know Microsoft traces everything by request-header; so it is theoretically possible to redirect incoming API calls to other servers/technologies.. actually I wouldn't be surprised at all if Microsoft did that for their own calls) – Danny '365CSI' Engelman Jan 31 '17 at 13:19
  • 1
    Would love to be able to Thumbs-Up your last sentence... Oh.. there are days when I long back to my good old Lotus Notes years.. at least that Distributed Cloud Stuff worked.... in 1997... – Danny '365CSI' Engelman Jan 31 '17 at 14:45
9

as you state, SPFX doesn't have some special way to call REST endpoints that is faster. The sphttpclient object makes a standard web call (and uses the standard browser request underneath). Depending on how the original solution was implemented (iframes anyone?) it can be faster, in the same way that a SEWP is faster than an iframe. At the end of the day though, it's all javascript. What can also be faster is that with 1st and 3rd parties using the same libraries, you don't need to download different implementations of what is effectively the same code (I'm sure that there are numerous implementation of refreshing your auth token when it expires).

Our hope would be that, once people are familiar with the tools, it will be faster to write robust, complex solutions (5000 lines of pure js is a lot. Anders Hejlsberg wrote TypeScript to tackle js development at scale).

The performance #s you have at the top (downloading images, making REST calls, etc.) are going to be the same no matter what framework you use. We're working on improving the speed of both raw file downloads (the image gallery) and REST calls (which should also improve aspx requests as well), and those improvements will help everyone. There are also features you mentioned in previous posts to do with the CDN integration, which can help things like image galleries (if you are OK with the security aspects) and future work around secure CDNs.

As far as the wrap vs. write conversation, it's going to depend heavily on what the original code looks like. If it is tightly coupled to the current DOM, depends on global window variables, etc. it's going to be rough going. However if it has a clean separation (for example, you pass in the DOM element you want to modify, you pass in the window variable to your functions, etc.) then it should be much simpler. Throwing away 5000 lines of tested, stable, documented and understood code seems extreme. I would look at how it could be incorporated.

  • 8
    Tnx Pat. Please, at the next inner-circle MVP party, make them read this and have them sign in blood that they understand. I am getting pretty sick of kids, half my age, telling me everything is better with React (not only in de Microsoft domain.. almost every Meetup glorifies React). We are (and have been for 24 years) stuck in the browser and all it does is HTML,, CSS and JavaScript and nothing more. Everything else is (syntactic) sugar. .. Very nice and sweet sometimes.. – Danny '365CSI' Engelman Jan 31 '17 at 18:20
5

Disc.: all below is my POV only.

Is SharePoint Framework going to have influence on the download speed of assets? or access time to REST endpoints?

I strongly believe no it's not. Absolutely no influence.
You said they can track request tag - yes they can, but from the other side they are saying that for SPFx you can use any js library you want, that means I'm not restricted to use SPFx pre-built httpclient, I can use fetch or just vanilla xmlhttprequest.
With custom http client they are not able to track request-id and are not able to "optimze" request. If they are really doing some optimization for SPFx requests, in that case I think they should say "hey guys, use only this one, becasue it's blazing fast. Don't even think about something other than pre-built httpclient". But in reality we can use any and that's official.

How can we speed up dowloading Assets and accessing Endpoints?

That's a good question. For me images are loaded fast on my empty dev tenant. I think you need to try to find the root cause. First of all make sure that's not a permissions or too many files problem. Create a new library and put only one single image and measure performance. Too many items or too many unique permissions can slow down requests. If this for the whole tenant... I would that's a reason to raise a support ticket.

  • 2
    See graphic above, the biggest delay is the very first request to sharepoint.com. If I take out all SP thingies and create a bare bones aspx file it goes down from ~800 to 150ms, now the only thing I loose then is the SuiteBar and Navigation... But lets not digress in this topic.. MVPs who say endpoints are going to be faster with SPFx are talking poop – Danny '365CSI' Engelman Jan 31 '17 at 14:24
0

I don't know if react is much faster then vanilla js. I do hear a lot about the virtual dom it uses which makes it fast...

I do believe that the sites will feel faster as it loades in smaller chuncks so the end user will experience it as faster. Also because there is no longer the need to perform postbacks on every action the overall feel of sharepoint will be more responsive and fast.

Another performance improvement thing that is coming to SharePoint is de ablity to have a library as CDN. Don't know the finer details but it will act as a caching mechnisme so there is no longer the need to perform the authentication stuff everytime, making the load of assets much faster.

Have a look at what MS team is doing to improve performance (last section is about CDN): https://techcommunity.microsoft.com/t5/Microsoft-Ignite-Content/BRK3026-Learn-how-to-build-a-fast-responsive-SharePoint-portal/td-p/10358

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.