Swagger-ui: Very slow loading times

[replaysMike]

I commented on this in an older issue, but I'm going to open a new one for performance issues.

I've got 45 api endpoints and am running swagger-ui under Swashbuckle (.Net) latest version. It currently uses swagger 2.1.3.

Before I started messing around it was taking over 4 minutes to display the endpoints UI. I went in and set the highlightSizeThreshold to 1, and finally just commended out the highlight-7-3 lib altogether. I did get a speed increase of about 50%, but a 2 minute load time is still very unacceptable.

Are you aware of what is causing the severe performance problems, and have an ideas to solve it? This isn't a huge API yet, but it will become one and I'm concerned about any attempt to support swagger at this rate.

I confirmed the backend is serving the requests in under a second, and the schema is around 1MB.

[fehguy]

Hi, the best way to help with this is to share the spec so we can profile it.

[replaysMike]

sure thing... here it is. I prettyfied it just for readability, but it's minified in the response.

[replaysMike]

I tried myself to profile it, but it just locks up the chrome tab.

[fehguy]

Thanks. we're looking into this now, it may take a bit to sort out the root cause (and yes, I can reproduce it).

[collaborator99]

There seems to be a huge slowdown from rendering in version 2.1.0 to 2.1.1.

With a Swagger "spec" with 19 operations, from the moment "fetching resource list" message appears to the operations list appearing, it went from almost instant (1 second) in version 2.1.0 to about 23 seconds! in 2.1.1.

[fehguy]

As the support for remote references has been added, the slow down _usually_ occurs when something goes wrong in fetching them (i.e. a 404 or inability to resolve a remote reference). The _code_ for rendering a spec has not changed enough to cause what you're seeing.

@collaborator99 do you use remote references? If you have a spec to share, it will help.

[replaysMike]

It's probably something small as it usually is, if I was familiar with the code base I'd be more help. I'll try to dig in myself this week.

[simonmurdock]

Also suffering from very slow performance on a very fast machine. For now I have attached my chrome timeline which you should be able to load into your timeline to get a full breakdown of what's going on. About 60% of my API is actually added right now and taking 15 seconds or thereabouts.

swaggerTimelineRawData-20160209T085821.zip

I can also provide my swagger json privately if needed.

Also found this - https://github.com/oconics/swagger-ui/commit/e5bf68fd502ca4bb083e2339bceb0f6e0473fb73 seems like it would defer all the rendering and fix our issues.

Update:

I cloned the latest version and loaded my test json into that, and I get a call stack exceeded where it gets stuck in a loop everywhere between createSchemaXML and createObjectXML
Attached the chrome time line data:

callStackOverflowTimelineRawData-20160209T202231.zip

[fehguy]

Try setting the highlight threshold lower when initializing swagger-ui:

highlightSizeThreshold: 100

We're currently working on some performance issues around this right now.

[simonmurdock]

@fehguy ran latest version again with highlightSizeThreshold: 1 and still the same issue, call stack exceeded after around three items are shown on the main screen:

Pattern does look a little different though. Unfortunately I don't know a whole lot about backbone views or I'd be of more use. Could I ask why XML is even involved? if its json in? Just for the dropdowns to choose the response view?

[webron]

@simonmurdock - if you can share your swagger.json with us it would be a huge help for investigating it further.

[simonmurdock]

Hi @webron I've emailed it

[simonmurdock]

Any updates? @webron

I'd be happy to try them out

[webron]

@bodnia? :)

[bodnia]

@webron it wasn't merged into master yet

[bodnia]

PR for this issue is https://github.com/swagger-api/swagger-ui/pull/1956

[replaysMike]

I'll check out this PR however if you note my initial post, I had disabled highlight completely for my tests. It does indeed slow down the load time by a lot, however it is still painfully slow even without highlight. We're talking minutes of load time here for what is a fairly small API.

[fehguy]

Sure thing @replaysMike. There are multiple fixes going on, one was highlight which can now be configured away to be disabled completely. Another with references (https://github.com/swagger-api/swagger-js/pull/710, not yet merged into the UI). I'm hoping those two make a big difference, they will at the very least help us isolate things.

[simonmurdock]

The issue is that everything in signature.js is incredibly slow and is all being processed up-front. It should be deferred until you click that particular path/route. I think these accounted for 50% of the issue.

Those calls being:
getModelSignature
createJSONSample
getParameterModelSignature
createParameterJSONSample
createSchemaXML
createXMLSample
getPrimitiveSignature

I've since started developing my own UI to parse swagger API json files, and do roughly what Swagger-UI does. Admittedly it's not doing any of the model stuff yours is, but it's deferring everything and loading the same json as my screenshots above in < 600ms. Should be possible to get swagger-UI that fast.

[MisterWil]

Are there any updates on this? Seems that this as well as #1804 are related. Like @simonmurdock above, I was also having extremely slow performance on a much smaller API and the master got stuck in a createSchemaXML loop.

[simonmurdock]

I've just abandoned swagger completely.

[ponelat]

That's very sad

[Helmsdown]

Just ran into this. I can provide my swagger spec privately.

I was running the dist of swagger-ui:2.1.4. I pulled the dist from master and its much better!

+1 releasing a new version of swagger-ui

[webron]

@Helmsdown - we're close to releasing a new version. If the performance of master is not enough, please share the spec. You know how to reach us ;)

[fehguy]

Swagger-ui just received an update which dramatically speeds up loading times. Please try master, which uses swagger-js 2.1.17.

[replaysMike]

Will be reviewing this today. Would love to be able to go back to using Swagger-UI.

[fehguy]

Please do share your findings

[michaelrepucci]

I just pulled the latest swagger-ui from dist on master, and while it's better, I still have painfully slow performance on a REST API with 50 read-only (GET) endpoints. The minimized swagger.json is 94.4 KB and, itself, loads very quickly. But both Firefox and Chrome complain of unresponsive scripts when loading it through the swagger ui. I'm completely new to swagger so mostly wondering if this is a limitation of swagger itself, or related to my REST API.

[webron]

@michaelrepucci - thanks, that's great. Not great that it gets stuck, but it's it's rather that you provided the spec - that helps us a lot analyzing what's causing these issues and tackling them one by one. I can confirm that this is indeed painfully slow with the current master.

[fehguy]

Looks like an issue with XML rendering, I'm getting a max call stack exceeded.

[gwynjudd]

I'm seeing very slow page loading times - we are using swagger-ui 2.1.4 from swashbuckle. Out swagger definition is around 6Mb in size so it's pretty big? It took around 90 seconds to render in the client

[gwynjudd]

I tried master branch - I found that rendering time seemed to be much improved in that I can see the UI will all of the controller names fill in somewhat faster. However, the page is completely unresponsive for some time after (a few minutes) and I see the chrome "this page is unresponsive" message appear several times before I can interact with it.

[gwynjudd]

Please let me know if you would like to get a swagger spec file from me

[webron]

@gwynjudd - yeah, that's the best way to help us solve performance issues, much appreciated.

[simonmurdock]

I also emailed my json 5 months ago.

[webron]

@simonmurdock - I'm afraid I can't find your spec.

We're working on a major update to swagger-ui and collecting specs that raise issues in the current version, so we can make sure to address those before pushing it out.

[simonmurdock]

sent again

[webron]

Got it, thanks. We'll add to our use cases.

[webron]

@simonmurdock from quickly looking at it (with the current version of swagger-ui), it looks like the issue is similar to @michaelrepucci's. The XML rendering takes too long. Removing the application/xml from the spec makes the rendering significantly faster. Obviously, this is not a solution, just helping us isolate the issue.

[icaro56]

I use the last swagger ui version. After I click on Explore, the ui stay loading and crash on Chrome.

[webron]

@icaro56 - just like with everyone else, we can't do much without a spec to reproduce the issue.

[icaro56]

What is a spec? I sent to you the swagger.json. I think swagger ui is slow because the swagger.json is big, 100KB.

Em Quinta-feira, 18 de Agosto de 2016 17:55, Ron <[email protected]> escreveu:

@icaro56 - just like with everyone else, we can't do much without a spec to reproduce the issue.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[webron]

Did you put it in a different ticket? It's not here...

[webron]

You can't attach files with email, you have to do it through github's interface.

[icaro56]

edited file.

It was the incomplete file

[simonmurdock]

yes see https://github.com/swagger-api/swagger-ui/issues/1919#issuecomment-187456236

[icaro56]

@simonmurdock I like very much swagger documentation. I was using Enunciate doc. Are there another lib doc similar to swagger?

[webron]

@icaro56 just tried loading your spec in the latest version in both Firefox and Chrome - loads quickly and doesn't crash. Are you sure you're trying the current latest?

[icaro56]

Yes. In top from swagger-ui.js is

/**

• swagger-ui - Swagger UI is a dependency-free collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API
• @version v2.2.0
• @link http://swagger.io
• @license Apache-2.0
  */

If you do not pass the apikey is fast, but after you inform the api key all services will are available. I think send you only swagger.json with get services.

Sorry, now with all services
swagger.json.txt

[webron]

Thanks! Now I'm able to reproduce it. We'll use it in our testing as well.

[gwynjudd]

Hello,

I have pasted an anonymised version of my spec file here:

https://gist.github.com/gwynjudd/23c09d5a99463fddc0938f3ff8f3c64e

It is around 7Mb in size, and it takes several minutes when loading into chrome on my PC before the UI becomes responsive again.

[webron]

Thanks @gwynjudd. It's a huge spec, definitely takes a long time to load. Since it's hard to navigate through and check it manually - quick questions - do all tags have exactly the same set of operations with only one specific part of the path being different?

[cabbonizio]

There's a huge number of re-usability and condensation opportunities in that spec @webron. That is kind of equivalent to me having a separate URI for each product in my corporations catalog which is nearly 100K products. Apologies if I'm missing something here.

[webron]

@cabbonizio I'm not sure about the context of your message. If it's about @gwynjudd's spec, then there's potentially a way to minimize the spec making it smaller in general, regardless of the UI.

[gwynjudd]

@webron yes that is true at the moment, but that may change as we develop our API further and expose more functionality to the entities. @cabbonizio it is more like having a separate URI for each table in a database - we wouldn't have a separate URI for each product, but we would have a separate URI for (say) the products table. We can potentially filter some of them out, but there are likely to be hundreds that would need to be exposed for some use or other

[webron]

@gwynjudd Putting the current performance issue aside, you can really speed things up by making a few simple changes to your spec (I don't know if it's generated or handwritten). You can condense the operations that only have the different entity by making the entity name a path parameter, with an enum providing the options for the different entity names (again, all that assumes they are indeed identical). You can apply multiple tags per each entity if needed. It will render the same way in the UI, but the file itself will be _substantially_ smaller, making network faster and parsing as well. The downside is that all operations under all the tags will still show all the options for the enum, not just the one applied to the tag - not sure if that's acceptable for you.

In the future, if you need to apply special operations for entities, you can do the same by applying only the relevant tags and the relevant enum values for those specific operations.

[gwynjudd]

@webron It's generated from metadata - I are using Web API and swashbuckle to do all of that hard work. Can you expand on how to make the entity name into an enum? I might have to do some research into seeing if swashbuckle is flexible enough to make that possible. What is a "tag" in this context?

[webron]

@gwynjudd - got it. Not sure how much control Swashbuckle provides you, but you can its author about it, he's a great guy. In any case, it's fairly simple, just like any other parameter type. So assuming you have the path/v1/{entity}/ops then you'd define the entity parameter as:

        - in: path
          name: entity
          description: Entity type
          required: true
          type: string
          enum:
            - Entity1
            - Entity2
            - Entity3

That effectively says that these are the only 3 values that will be accepted.

The tags are are organizational tool to group operations. A single operation can actually have multiple tags, putting a single operation in multiple groups. If you look in swagger-ui, it uses the tags to group the top-level operations - in your case it's the entity names.

[gwynjudd]

@webron thanks for that, after spending literally 2 minutes looking it looks like I might be able to implement an operation filter along with some kind of rework of how the controllers are generated.

Instead of having one operation for each entity type (what I do now), I would have only 1 operation for the whole thing. Then in the path /v1/folder/{controller}/, the controller parameter would have to be an enumerated type as you defined above, instead of being the name of the controller definition in Web API.

Swashbuckle generates the first tag for each operation:

Each operation can be assigned one or more tags which are then used by consumers for various reasons. For example, the swagger-ui groups operations according to the first tag of each operation. By default, this will be the controller name but you can use this method to override with any value.

By the looks of that, I would then have to add one tag for each entity name to the operation? Then get swagger-ui to group by those tags?

[webron]

@gwynjudd that is correct. Technically you don't _have_ to use multiple tags, it depends on what you'd want to achieve (and only you can decide that). In swagger-ui, tags will affect the grouping - so the same operation will appear for each tag (entity) that you define. This is not strictly needed as it's indeed the same operation, but it's more of a documentation choice.

For code-generation, tags can be used to organize operations into classes. Again, strictly speaking, if the entities have _the same_ operations and do not use input/output that's specific to those entities, you don't necessarily need that.

[Zapnologica]

Any answer / solution to this? I am experiencing a similar issue with reasonably small API. However mine takes more than 15-20 minutes to show up. I have asked a SO question about it. http://stackoverflow.com/questions/39220272/swagger-ui-hangs-on-fetching-resource-list-please-wait

[PeterBrende]

I am having severe performance issues when adding relationships between objects. We use Nhibernate, and have many parent-child relationships between the entities used in our Web API OData services. I tried removing all relationships (Swagger UI is very quick). One by one, I started adding back relationships. The performance degraded very quickly until it got to the point where it just processes for several minutes before dying (I believe because of memory). I have attached the spec.
SwaggerSpec.txt

[gwynjudd]

@webron after more investigation, I found that this approach wasn't going to work. If you recall, we initially thought that my schema consisted of a great many tags with all of the same operations. It turns out that after further development, the operations for each entity type either return or take parameters of different types. This meant that the idea of factoring out the operations and associating them with tags wasn't going to work. Do you have any further ideas for improving performance? For now, I am filtering the operations and entity types so that the API document size doesn't become too massive.

[webron]

@gwynjudd - would be hard to say without seeing a (current) example of the spec. Are you able to share that?

[gwynjudd]

@webron I'll see if it becomes high priority for me or not. Currently I am jumping around between a number of projects.

[webron]

@gwynjudd no worries, ping me when you can.

[wauk]

domaindrivendev/Swashbuckle#891
I think this is the issue and everyone is logging the issue in the wrong place

[michaelrepucci]

@wauk I don't fully understand the difference between Swashbuckle and Swagger-UI, but unless Swashbuckle is a dependency of Swagger-UI that is completely transparent to the use of Swagger-UI, I don't think domaindrivendev/Swashbuckle#891 is my problem.

[webron]

@wauk not all the issues raised here are related to Swashbuckle.

@michaelrepucci - Swashbuckle is responsible for generated the Swagger/OpenAPI spec documenting the API. swagger-ui (this project) is the visual renderer of a spec in a human-friendly format. Swashbuckle embeds swagger-ui in it to help its users get a nice UI, but they projects are not directly related.

[wauk]

They are related in the aspect that Swashbuckle serves the resources for the swagger-ui interface if you integrated using Swashbuckle and I agree that its not responsible for all the issues here but most of the people using Swashbuckle should experience some sort of slowness especially when some latency is added to a request to fetch a resource for the swagger-ui

[michaelrepucci]

I'm still confused whether I'm using Swashbuckle. What @webron said makes me think I am, because something Swagger related is generating the swagger.json for me. Here's what I do.

I put a copy of the swagger-ui code that I pulled from this repo directly into my Java EE web resources, then annotated my REST facades with Swagger annotations. It almost seems like magic that the swagger.json is created from those annotations - I provided this previously - and the UI displays this swagger.json correctly when I open the swagger-ui index.html, just very slowly.

Was Swashbuckle involved in this process at any point? If so, where?

[webron]

@michaelrepucci Swashbuckle is a .NET integration that exposes the swagger.json from the code - so... unlikely that you use it. For Java, it depends on which REST framework you use as there are different libraries for different frameworks.

[michaelrepucci]

@webron We're using JAX-RS as implemented by RESTEasy on Wildfly 10.

[webron]

@michaelrepucci then you're probably using swagger-core

[andrenpt]

If the API has more than a certain amount of methods swagger-ui just times-out.
If required I can provide in private the json file.

Thanks

[webron]

@andrenpt please do, email is in my profile.

[michaelelleby]

It was fixed in this commit which is included in 5.5.1 (5.5.2 is latest public nuget version)

[replaysMike]

Confirmed this is still an issue. UI times out and crashes the tab with out of memory issue. Schema is only 340kb in size and the majority of the size is with model definitions. I haven't tried to build an object graph out of it, so I don't know for sure if there are any recursion issues (it's unlikely but within the realm of possibility). If you are still looking at this issue, I can provide the schema file.

[webron]

@replaysMike - please do, it'd be helpful.

[replaysMike]

Attached is the swagger schema that causes the UI to barf.

api_v1.zip

[webron]

Great, thanks! I'll test it shortly.

[replaysMike]

any luck with the testing? I'm getting close to switching to a custom implementation, we're pretty much out of luck with this library unless there is a fixable issue with the schema.

[webron]

@replaysMike we're actually in the process of a major update to the tool, which will include a lot of performance improvements as well. Testing your spec, it _loads_ okay, but we can still improve the performance in some aspects to it.

[robertcsakany]

I have same problem with the attached swagger spec - impossible to get response from UI. Its a simple example application. It is generated from CXF. I know this is relatively large, but as a matter of fact I dont think a REST api endpoin't operation counts have to be less then ten. The microservice world only just a part of a real world, our application have several endpint operations. Maybe my spec is not optimal, maybe I have to forget tags - If you say so I can optimize. I've tried some of them, but none of them helped.

If there is no chance that the Swagger UI frontend will be performant I thin about to make some static HTML generation.

Is ther eany chance this type of specs will be supported?

swagger_car.zip

[replaysMike]

@webron I think we can close this thread. I was able to resolve all the issues purely at the schema generation side with Swashbuckle. There were multiple issues, which I suspect other users are also encountering (though I think it would be good to detect and prevent these conditions in the UI, as it seems to be related to following circular $ref's).

To summarize, this is how I fixed my issue:

• Our API was referencing/returning Entity Framework models in the API, and this causes Swashbuckle to include them (and follow all references) which bloats the size and introduces all sorts of cross-model references. Fixing this issue solved a majority of the problems encountered with swagger validation and swagger ui.

• Turning off fully namespaced definitions in Swashbuckle reduced the overall size of the output. Had to resolve some conflicting model names to fix the need for this.

• Removing models that had parent/child relationships. It seemed in some cases this was not as much of a problem.

• We were also using YamlDotNet to convert Swashbuckle's json formatted schema to YAML. They have an implementation detail which forces the Swagger version to be a number, not a quoted string value which causes a validation error. I submitted a patch to them to fix this issue, but they may choose not to implement it. It's a little weird the swagger spec requires this to be a quoted number. None the less, I removed the reliance entirely and we now validate the json formatted schema instead.

After resolving this, swagger UI loads in under a second and it's a fairly large API.

[webron]

@replaysMike wow, thanks for the update. It's amazing how tuning can make such huge impacts at times. Hopefully, others will find this useful as well.

If you don't mind, I'll keep this issue open because other hitched a ride on it and brought up similar yet different issues all related to performance. We're getting close to releasing a major update that will address a lot of issues, including performance, and I'd like to use the tickets to manage what we're trying to solve.

If you feel strongly about it, we can still close the issue and open a new one instead.

[replaysMike]

absolutely, no this is an epic thread with a lot going on. I'll look forward to the upcoming updates and will test what I can with the new releases.

[dimitertodorov]

Running into a similar issue. In my case I am using grape-swagger to generate my swagger automatically.

EDIT: I should add that we do have a lot of circular dependencies in the entities we are returning. This is by design. And, we do not expose nesting beyond 2 levels by design in our API. But we still want the relationships to be documented in the swagger.
Also, by removing the circular relationships the UI loads immediately. I guess I might just offer 2 different sets of swagger until this is fixed, one for swagger-ui and one for general use.

todorovdi_nmdb_swagger.zip

[yyy717yyy]

Just run into the similar issue. It seems that the problem is due to the definition array type. I defined input field as an array. But did not specify the actual item. There is no error in swagger editor. But it caused the hang problem in swagger UI.

definitions:
  Logger:
    type: object
    required:
    - loggerBasicInfo
    - input
    - output
    properties:
      loggerBasicInfo:
        $ref: '#/definitions/LoggerBasicInfo'
      input:
        type: array
      output:
        type: array

[webron]

@yyy717yyy you can't have type array with no items.

[webron]

Everyone, we have released 3.X Please give it a try and let us know of any performance issues.

[michaelrepucci]

Thanks for the update. But forgive me for being incompetent. I can't get this to work. With 2.X I simply included the contents of /dist in my Java EE WAR, and the annotation-generated swagger.json loaded (albeit slowly). With 3.X including the contents of /dist displays an empty page.

If, instead, I open /public/index.html on my desktop (outside of the deployed application), and point it to my swagger.json, I get the following "Failed to load spec" error: {"schemaValidationMessages":[{"level":"error","message":"Can't read from file http://127.0.0.1:8080/NeuroReadback/rest/swagger.json"}]}

My swagger.json is the same as I posted here before, as our API is unchanged. Is there something I'm missing? I did speed read the documentation.

[webron]

@michaelrepucci - can you check your browser's console logs for additional errors?

[michaelrepucci]

See screenshots below of contents deployed in app and Firefox console error.

[webron]

Is that with the index.html from public? you shouldn't use the one in dist.

[michaelrepucci]

Maybe you could explain to me how I'm supposed to use swagger-ui 3.X. It's not clear to me from the documentation. I have a Java EE project that is packaged into a WAR. With swagger-ui 2.X, I simply copied the contents of the swagger-ui /dist folder into the web root of my WAR, and it worked (albeit slowly). With swagger-ui 3.X, I did the same thing and got what you see above. What should I do instead?

[webron]

It's slightly more complicated - we'd need to write documentation for that (though I'm hoping for a simpler change). In the meantime, would suggest running it locally and just point it to your spec instead.

[michaelrepucci]

Oh, that's unfortunate, as we prefer to serve the docs with the application. But I now see why I got the "Failed to load spec" error that I mentioned above when I ran it locally: the console indicates that it was a CORS restriction, which is of course described thoroughly in the documentation. Would have been nice to see that reason in the "Failed to load spec" error message.

[michaelrepucci]

After enabling CORS, I did test the locally run swagger-ui, and it is perfect in terms of responsiveness, no lag. Is there an approach I can use to try to deploy this in my Java EE application?

[michaelrepucci]

Just noticed that, oddly, even with CORS enabled, the swagger-ui still shows me that same error ({"schemaValidationMessages":[{"level":"error","message":"Can't read from file http://127.0.0.1:8080/NeuroReadback/rest/swagger.json"}]}) at the bottom-right of the page. The swagger docs look correct though, except that on my dev environment the app is on port 8080 while the "Try it out" button seems to expect port 80.

[webjoel]

I have an API that contains more than 100 paths, after loading in swagger ui and clicking on the endpoint takes a lot time to open, without even showing a "loading", this I have not yet mapped the responses of the path.

Is there any way to improve performance? Lazy loading / rendering? My swagger.json has 128 KB.

Version of Swagger UI: 3.1.4.

Until this is resolved I'm using ReDoc.

[ponelat]

We need to optimize the amount of re-renders. This is definitely doable, its just work that needs to be done, such that after loading ( ie: after the resolver, yaml, etc has run ) - then the UI should be reasonably fast on opening and collapsing an endpoint.

A possible reason it isn't, is likely due to the number of containers ( components tied to global state ) that are re-rendered as a result of toggling the layout.shown state.

[wahyu-pratomo]

My solved solutions (Using C# .Net in visual studio 2015):
on your code, check the upper part of every controller that needs to be accessed from swagger, please add comments below:
/// <summary> /// /// </summary> /// <param name="fromDate"></param> /// <param name="toDate"></param> /// <param name="transactionType"></param> /// <param name="options"></param> /// <param name="mini"></param> /// <returns></returns>

then between the controller and the comments, put the swagger access as follows:
[VersionedRoute("your-versioned-route")] [Authorize(Roles = "your roles")] [ResponseType(typeof(return type ))] [SwaggerResponse(HttpStatusCode.OK, Type = typeof(return type))] [HttpPost] //access method [ActionName("yourControllerActionName")]

NB: don't forget to make sure the return type provided by the controller is the same as the return type you provide to swagger.

hope it can helps

[gsviteri]

Hi, I am still having performance issue in a relatively small spec file (16 tags + 107kb).
Running an swagger old version the API loading + rendering time was nice and fast.
Due to new specification combined with the redesign of our website, we decided to update SwaggerUI and after updating to tag:v2.2.10 the loading time goes up to 38seconds.
3 days ago a new version has been released but sadly for me it is even worse in the sense that it freezes Chrome and I can't get any result, after a minute or so, it renders the page but still very clanky.
I have no problem sharing my spec with the developers, but I can't share it here. How do I sent it to you ?

This is how I am creating, all with default values. ValidatorURL does not really make any difference.

const ui = SwaggerUIBundle({
            url: window.location.origin + deployPath + "/v2/api-docs",
            dom_id: '#swagger-ui',
            deepLinking: true,
            presets: [
                SwaggerUIBundle.presets.apis,
                SwaggerUIStandalonePreset
            ],
            plugins: [
                SwaggerUIBundle.plugins.DownloadUrl
            ],
            layout: "StandaloneLayout",
            validatorUrl: null,
            tagsSorter: "alpha",
            docExpansion: "none"
        });

        window.ui = ui;

Thanks for you help
Br

[webron]

Thanks everyone for the feedback. Each API document that we get helps us with evaluating the different issues. As you can imagine, performance tuning is an ongoing process and we slowly make improvements for it. There's are a few major changes in the works that would benefit performance and other parts of the app - but those take time.

For those of you who can't share the definitions publicly, you can send them to @shockey or myself - our emails are found in the profiles.

[iplayfast]

https://github.com/swagger-api/swagger-editor/issues/1541 has example json file that crashes it. Used this code for 2 days, and it appears to be useless. Signed up for hub and it crashes that as well.

[nijinillath]

Hi @webron , same issue with the page unresponsive while loading swagger UI due to json size (750 KB), the swagger json is code generated using swagger-jersey2-jaxrs. I have send you the Json in email. Thanks in advance.

[pavelgordon]

@nijinillath try to collapse 'models' section. After this swagger UI will become responsive and fast again(at least the REST API part).

[nijinillath]

Thanks @Freemahn for the response, but using docExpansion: "none" also the UI page unresponsive.

[nijinillath]

Hi Team, did you get a chance to re-check on the UI page unresponsive issue due to the size of json ?
Is there any new option to hide the models from the UI ?

[webron]

We regularly investigate and provide small performance improvements over time. This ticket encompasses a range of such improvement. We can't say which improvement will fix whose issue, so it's best to keep checking with newer releases.

[shockey]

FYI: if the Models section is your performance bottleneck, the most recent release (3.4.4) contains improvements that are likely to improve your experience.

[nijinillath]

Thanks Team, appreciate the response.. Will check on the newer releases. As of now "SwaggerUI-Angular" worked for my load.

[webron]

Time for an update on this long thread. We've recently pushed some updates to the UI that should present with increased performance. They are mostly focused on lazy-loading, but not only. This means that if you start your swagger-ui with collapsed entries, it would load fairly fast, and the additional parts will load as they are expanded.

We encourage you to give a try to the latest version and see if it helps your case. We'd be happy to further investigate performance issues that persist. Please keep us posted.

[msankhala]

I am using the swagger hub and my API spec contains 1000 lines and it has become extremely slow. Even though I have collapsed all of my schema and a few paths but It is still slow.

[heldersepu]

@msankhala Can you share your spec?
Have you tried reducing the spec (maybe try with less paths) see if something stands out as the main issue?

[zekeriyakoca]

I faced the same issue after adding [ResponseType] attribute to my endpoints. Some of the endpoints was returning complex model class and this was causing the problem in my case. I removed this attribute for these endpoints and it's solved. ResponseType was not mandatory for my project and I skipped this feature, but if you need it, you can try to find a solution to restrict model serializing dept or you can replace your returning model not including circular references.

[heldersepu]

@zekeriyakoca what you mentioned [ResponseType] attribute is not a swagger-ui feature, a quick search on the code returns nothing:
https://github.com/swagger-api/swagger-ui/search?q=ResponseType&type=Code

best you can do is attach your spec here so the team can look into it

[zekeriyakoca]

@zekeriyakoca what you mentioned [ResponseType] attribute is not a swagger-ui feature, a quick search on the code returns nothing:
https://github.com/swagger-api/swagger-ui/search?q=ResponseType&type=Code

best you can do is attach your spec here so the team can look into it
[ResponseType] asp.net attribute used by ApiExplorer to know what type a method returns. Swagger should be using this attribute to documenting the return type.

DbsDocument cannot be serializable because of circular dependency. This code cause the swagger index page to be loaded in 20-30 secs and when I try to expand the request in swager ui panel, it's frozen.

If the team implement a feature to restrict the serialization depth, this may be useful for some developers. If already exist, I would be glad to hear.

[heldersepu]

@zekeriyakoca that screenshot looks like C# maybe you are using swashbuckle, but that is not directly related to this project...
and no, at the moment, there is nothing to restrict the serialization depth, once someone clicks on the model it will expand all the way

I opened this: https://github.com/swagger-api/swagger-ui/issues/4280 a while ago, the idea was to only load/expand as needed maybe 2 levels deep at a time, (I imagine this is very very low priority) that is why no one has taken interest in fixing it.

In my experience, large or complex models are inherited from bad practices and they can be refactored to reduce complexity. Yes we can create a theoretical spec with lot of nesting and that will blow any web UI, I did some numbers a while back here: https://github.com/swagger-api/swagger-ui/issues/4411#issuecomment-380168870
but ultimately it's our responsibility as developers to simplify the APIs we create