#perfaudit

Performance Audit Of Web Applications By Professionals
Case Study

PerfAudit: DeviantArt.com

Hey folks! Today we have come up with the case study for DeviantArt.com, the largest online social network for artists and art enthusiasts, and a platform for emerging and established artists to exhibit, promote, and share their works with an enthusiastic, art-centric community.

It is among the top 100 of all trafficked websites on the Internet. They have over 32 million registered members and attract over 65 million unique visitors per month. Their members upload over 160,000 original art works every day, everything from painting and sculpture to digital art, pixel art, films, and anime.

Live auditing

How fast does deviantart.com load on average?

Very Very Slow around 46.382 seconds when we loaded(1.8 seconds on average), 66% of sites are faster (as per data from Alexa).

Network profiling

Desktop pagespeed score for DeviantArt is just 24, which specifies a tremendous scope for improvement. DeviantArt displays paintings, sculpture to digital art, pixel art, films, and anime i.e. it is a image heavy website.

Thus maximum compression, suitable resizing and caching of image resources should be their primary action, which is verified by PageSpeed’s recommendation which says:

Optimize the following images to reduce their size by 2.7MB (48% reduction).

2.7MB of size reduction just through compression and resizing of static images must be tackled on priority.

Resizing and Compression of images are among the redundant tasks that must be performed either in batch, or as soon as an image is uploaded by the user on DeviantArt.

Follow this blog post by Addy Osmani, describing the available Image Optimization Tools.

Reduce server response time

PageSpeed insights also suggests to reduce the server response time, which is currently more than 1.5 seconds.

Understanding the processing time of 1.5+ seconds taken by the server can be attributed to a heavy processing getting triggered on every request to Homepage. It can also be scaling issue, amounted by the traffic at dispense, thus a solution for reducing the server side response time can only be suggested appropriately after understanding the architecture of DeviantArt. Though the generic solutions used by businesses to resolve this issue are:

  • Caching the entire HTML generated for specific requests(especially for homepages) for X minutes, so as to completely eliminate any server side processing in that duration of time.
  • Adding Cache layers at multiple points where processing / retreival of data is involved via external services / dependencies.

Reduce First Pixel Render Time

First pixel render time as recorded by us is around 6.29 seconds, which is huge. Eliminating render-blocking JavaScript and CSS in the above fold content which currently includes 9 CSS files, will surely help to reduce the first pixel render time drastically. Furthermore, the critical CSS can then be calculated and added in the HEAD section, which is not present currently.

The first critical issue describes the reason for the increased first pixel render time, rendering is quite slow and it takes about 5.5 second to get the first glimpse of readable content, though the first pixel render time is about 3 seconds.

Mobile Specific Issues

Compression and Resizing of images is again highlighted in the page speed issues, which has already been discussed in the issues listed above.

Other necessary optimizations possible for DeviantArt.com:

  • Make fewer HTTP requests, use concatentation of static resources
  • Leverage browser caching of static resources with appropriate response headers.

Profiling Rendering Performance

The first thing we saw while browsing this website was huge jank while scrolling - much more than we have seen in our previous case studies. Profiling the page scroll in Chrome devtool timeline, we noticed the sticky header on the website. Come on…this got to be the most popular rendering issue on the web!

Bad paints

As in previous case studies, this can be simply fixed using the transform: translateZ(0) hack.

Animated GIFs

To verify that no more unnecessary paints were happening, we switched on the Show paint rectangles option in the Rendering tab. Here is something strange on their page:

Animated gifs

The green paint rectangle seen above basically shows up every second! Yes, even when you are not interacting with the page. But why? Looking closely revealed small animated GIFs in that green area. GIFs are animated, they need to be repainted for every frame, sure. But why such a big paint rectangle? This is again a result of union of damaged regions. If you notice, they are 4 GIFs in the 4 corners of the green rectangle. Yes, the paint rectangles of the four images got unioned and hence, a big paint rectangle.

Now we could promote every GIF to its own layer to avoid union of paint rectangles and that actually helps in lowering down the paint area as seen below:

Better paints

But we still saw few paint spikes here and there which were mainly due to Composite Layers event. There are around 20 such GIFs on this page and taking every GIF to its own layer is probably causing too much texture transfer from CPU to GPU as GIF need to painted with different texture every frame. We are not very clear on how this can be resolved further. But we guess its a tradeoff one needs to consider according to the scenario at hand. We would like to hear suggestions on what can be done to improve this further.

That is it for deviant.com from our side. Till next perf study!

Share

Comments


Subscribe
Subscribe
Audit Requests

Want us to audit your Website?

We'll audit the page load and rendering performance of your web application.
Share your contact and we'll get back to you very soon.