How-To: Tips for Performance Optimization for Content & Commerce Sites

29 Jul

Statistics from a fairly recent Comscore report show that mobile usage now represents 65 percent of all digital media time. Nonetheless mobile data plans still come with a steep price tag and are limited in data volume. At the same time modern web design for the last couple of years has been focussing on establishing a story telling approach, building brand worlds and delivering real life experiences online. This relies on an enormous amount of pictures, videos, sounds and graphics. Delivering as much high quality content as possible with the least of amount of data therefore seems to be more important than ever. Google has reacted early on by figuring in page load times as one of their many ranking factors.

Our front-end developer Marcin Krzemiński has taken the time and compiled some interesting statistics regarding file sizes and delivery times. He also shows in detail how the front-end team has optimized the performance of our Symfony based shop. They are also interesting for content sites using eZ Platform/eZ Enterprise.

Intro

As web developers we are responsible for delivering content fast, keeping in mind the balance between speed and quality of all the assets including text. As of June 2016 an average page size is 2.4 mB (2486 kB) which is quite a lot considering considering the above mentioned 65% digital media time and the still expensive mobile data plans.

  • HTML – 58 kB
  • CSS – 76 kB
  • Scripts – 402 kB
  • Fonts – 74 kB
  • Videos – 302 kB
  • Other – 11 kB
  • Images – 1522 kB (1.5MB!)

Source: http://httparchive.org/interesting.php?a=All&l=Jun%201%202016

Comparison of asset sizes over the last years

Jun 2015 – 2087 kB / http://httparchive.org/interesting.php?a=All&l=Jun%201%202015

  • HTML – 55 kB
  • CSS – 63 kB
  • Scripts – 334 kB
  • Fonts – 98 kB
  • Video – 208 kB
  • Other – 4 kB
  • Images – 1312 kB

Jun 2014 – 1783 kB / http://httparchive.org/interesting.php?a=All&l=Jun%201%202014

  • HTML – 56 kB
  • CSS – 51 kB
  • Scripts – 287 kB
  • Fonts – 62 kB
  • Other – 123 kB
  • Images – 1128 kb
all assets size in last 3 years

Average Page Size

assets size in last 3 years

Here’s a chart with last 3 years compared. As you can see every year amount of data per asset type is growing. No matter if it’s CSS, JavaScript and especially images. Look how big number is taken by images.

assets-size

Comparing those stats we can clearly see that as developers we write more CSS, JavaScript but the biggest numbers comes to images size which is about 200 kB bigger every year. These numbers show clearly how important performance optimisation is.

In order to improve performance there is a lot factors including:

  • compress (uglify) CSS and JavaScript files
  • concatenate (merge multiple into one) CSS and JavaScript files
  • reduce number of HTTP requests (CSS, JavaScript, images, Fonts, etc)
  • Gzip / deflate data over the wire
  • image optimisation

Performance optimisations for silver.eShop and eZ Platform/eZ Studio based sites

Assetic

Assetic helps us compress and concat CSS and JavaScript files. Using assetic is beneficial for reducing number of HTTP request as well as number of data that is transferred during request / response tango. Here’s how we keep it:

CSS
{% block stylesheets %}
 {% stylesheets
 'bundles/silversolutionseshop/css/style.css'
 %}
 {% endstylesheets %}
{% endblock %}

Note: We use Sass to manage our Stylesheets

JavaScript
{% block javascripts %}
 {% javascripts
 ...
 'bundles/silversolutionseshop/vendor/jquery-2.1.3.min/index.js'
 'bundles/silversolutionseshop/vendor/foundation/js/foundation/foundation.js'
 'bundles/silversolutionseshop/vendor/underscore/underscore.js'
 'bundles/silversolutionseshop/vendor/backbone/backbone.js'
 ...
 'bundles/silversolutionseshop/js/app.js'
 %}
 {% endjavascripts %}
{% endblock %}

In order to compress files we use some useful and well known NPM packages:

We keep those packages inside ezpublish/Resources/node_modules directory and here’s how our config_prod.yml file is configured:

assetic:
    filters:
        uglifycss:
            bin: '%kernel.root_dir%/Resources/node_modules/.bin/uglifycss'
            node: '%siso_eshop.nodejs%'
            apply_to: \.css$
        uglifyjs:
            bin: '%kernel.root_dir%/Resources/node_modules/.bin/uglifyjs'
            node: '%siso_eshop.nodejs%'
            apply_to: \.js$

As you may notice NPM has a dependancy of Node.js which also needs to be installed on the environment where our shop instance is running.

Related links:

Charts

Before / after assetic filters

Before and after assetic filters

Asset type Before After % saved
JavaScript 751 kB 486 kB ~35%
CSS 414 kB 325 kB ~22%

data excluding third party assets like Facebook, Olark chat, etc

Number of HTTP requests

Number of HTTP Requests saved using Assetic

For CSS number is the same since we use Sass. On the output we always have one CSS file. When it comes to JavaScript the difference is huge. Using assetic and server configuration properly we reduced number of HTTP request from 48 to 3 in production mode.

Sass and Gulp

This is not directly related to the performance topic but it’s worth to mention that we use Sass in order to keep our stylesheets nice and organised. Thanks to Gulp and some packages we are able to deliver well organised CSS including always up to date vendor prefixes.

Components driven front-end

When working on a complete redesign and rework of our front-end layer both technically and visually we had to take a lot of things into the consideration. On of them was if we should help ourselves and use one of the popular frameworks out there. We decided to go with ZURB’s Foundation for Sites which is really nice to work with. One of the nicest things about it is that we can create a custom build out of components we really need. Having this principal in mind we have extend a lot of Foundation’s components as well as created a bunch of our own which are missing. Thanks to this approach our standard design is divided into small components which is beneficial in terms of file size for client’s work. We can easily enable / disable a component when it’s required. This leads to smaller file size on the end which is beneficial from the performance perspective.

Headers

Each type of assets wheatear it’s an HTML file, JavaScript, CSS or image should have different expiration time. It means that over certain amount of time the asset should be taken from the server, not from browser cache. It can have huge impact on the site performance and that’s why it so important. For files that are not changed often you should set long expiration time. We recommend using longer expiration for files like images, fonts.

This is usually done in the VirtualHost configuration and may look like:

ExpiresActive On
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType application/x-shockwave-flash "access plus 1 hour"
ExpiresByType application/shockwave-flash "access plus 1 hour"
ExpiresByType text/css "access plus 1 year"
<LocationMatch "^/var/[^/]+/storage/images/.*">
# eZ Publish appends the version number to image URL (ezimage
# datatype) so when an image is updated, its URL changes to
ExpiresActive on
ExpiresDefault "now plus 10 years"
...

Mod deflate

Apache configuration can be powered by a mode_deflate module which can be used to compress data using gzip compression before the data is send to the user. Having data compressed on the server means there is less data to transfer which results into faster page lead. Here’s how you can configure this in your Virtual Host:

AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript text/plain text/html text/xml application/xml

Using this approach we can gzip all CSS, JavaScript, HTML as well ass XML files.

Related reading:

Image optimisation

As mentioned at the beginning of this blog post images is the asset that is growing every year in terms of file size. That’s why it is super important to approach images topic the right way. In terms of project from front-end perspective there are two types of images.

First we have all static images like logo, favicon, spinners etc. To optimise these kind of images we use tools like ImageOptim (https://imageoptim.com/mac) or TinyPNG (https://tinypng.com/). If you’re not fan of these just Google for „optimise images“ or any similar search term and I bet you’ll find the right tool for your needs.

Second we have product photos. We tend to use a few image sizes for these files. In order not to load one huge file for each product or article we have couple of different configurations and serve proper files based on the view requirement. For example we might need different file for product list than for product detail page. Our team has developed and image converter tool that is using ImageMagick (http://www.imagemagick.org/script/index.php) and some .yml configuration. On top of it it’s important to set the quality for the output image. We suggest to set the quality between 60-75% in terms of JPEG compression.

Example of .yml configuration:

image_variations:
    thumb_smallest:
        reference: null
        filters:
            - { name: geometry/scalefillarea, params: [81, 61] }
            - { name: geometry/crop, params: [81, 61, 0, 0] }
    thumb_small:
        reference: null
        filters:
            - { name: resize/both, params: [150, 113] }
            - { name: background/white, params: [] }
            - { name: gravity/center, params: [] }
            - { name: extent, params: [150, 113] }
    image_zoom:
        reference: null
        filters:
            - { name: geometry/scaledownonly, params: [1600, 1200] }

Here’s how we use it in Twig:

<img src="/{{ st_imageconverter(product_image, 'thumb_small') }}" alt="Product name">

Conclusion

As an e-commerce platform manufacturer we feel responsible for delivering products that loads fast on every device. We make sure that mobile experience is as pleasant as desktop. In order to make it work as we expect we optimise performance on each layer: front-end, backend, server. Here’s what you should think about in terms front-end performance optimisation:

  • Reduce number of HTTP request by merging (concatenation) multiple files into one.
  • Reduce the number to bytes that are send over the wire by compressing files.
  • Optimise images for different views.
  • Enable gzip for CSS, JavaScript, HTML.
  • Set proper expiration time for files.

The brand new eZ Studio

9 Feb

In December 2015 eZ presented eZ Studio, a brand new and modern software tool for the popular CMS eZ Platform. We have already taken a closer look at what the next generation of content editing will look like.

eZ Studio

eZ Studio

From a design point of view this is a major upgrade from their previous versions. It has many modern features like drag and drop, real-time previews for multiple devices, a new way to interact with time-scheduled content via an intuitive timeline and more. But in my opinion the most important fact, besides all these new fancy features, is that the content itself is the main focus of the whole interface.

The content creator

eZ Studio content editor

eZ Studio content editor

The interface looks pretty modern. With the main content in the middle, all available tools are inline and easy to reach. At first the concept of inline tools may be confusing, because at a first glance it seems as though there are no formatting options available. But as soon as you click into the content area the tools available for this particular type of content are shown. In traditional text editors or word processors you may find all the available editing options over the editing area. Which easily distracts from the content itself. With the new inline-tools approach the user can focus on the content first. eZ Studio interface is doing just that, most options regarding the editing areas are hidden at first and only show up as an inline menu at a click of a mouse. Once you’ve adjusted to this new interface it is very nice and comfortable.

Different previews

Previews for multiple devices

Previews for multiple devices

The modern web is not just for the desktop computer anymore. Even though you may produce most of the content on a desktop device, the information is consumed on a wide range of devices like smartphones and tablets. eZ Studio handles this very well by directly offering three types of preview for your content. This way you can quickly see how your content will look like in those types of devices.

Edit content inline

New inline editing approach in eZ Studio

New inline editing approach in eZ Studio

This is actually a radical change from previous versions and also from other CMS where you get the classic HTML editor with all the editing options visible. This new approach is minimalistic. Less is more. You get only a few format elements, and if you need more you just can click on + and start adding elements. At first you may miss having all the usual buttons at glance, but how many of those buttons of your HTML editor do you really use regularly?

The page viewer/editor

eZ Studio page editor

eZ Studio page editor

The first thing that becomes apparent is that view and edit functionality are on the same page. This is quite nice because as a content editor you are able to see the full picture in the same place where you are creating and playing around with different content.

The landing page editor is also presented as a preview with all elements with a menu available for drag and drop. You can rearrange, preview and delete elements right there. Unfortunately they did not yet add an edit button. To edit a single content element from this interface you should switch back to view mode, then click on the element and then finally click edit again. Or of course you can switch back to the content editor and search for the document there, but then you will not be using this nice view/edit way of working with your content. For sure this minor annoyance will be fixed/added in future versions.

Also very handy is the preview in different devices, which is also available in this section, and will give you an impression of how the landing page will look on desktop, tablet and smartphone. This page viewer/editor has the same philosophy regarding content – content takes center stage.

Schedule blocks

Scheduled content - timeline lets you see the whole picture

Scheduled content – timeline lets you see the whole picture

A major change has been brought to scheduled content. This functionality is not new. It has been available with the eZ Flow module for quite some time now. But where the eZ Flow user interface has been a bit cryptic at times this completely new interface is very transparent and user friendly. Editors are now able to preview and edit content by using a timeline that appears on top. It is looking very good and the fact that you can see and edit content for certain points in time is quite practical.

Finally…

With this kind of interface eZ platform is taking a big step ahead of other CMS software solutions, both enterprise or small scale, which don’t have this kind of user experience that puts full focus on the content itself. If you want to see more you can watch eZ’s Demo video.

Happy content writing!

eZ Studio home page http://ezstudio.com

eZ Blog http://ez.no/Blog

Author: This article has been provided by Lucas Dima, software developer and specialist for user interface and artificial intelligence.

eZ Publish, eZ Studio, eZ Platform – What’s what?

26 Nov

In der vorletzten Woche haben wir bereits in einer kurzen Nachlese unsere Eindrücke Highlights der eZ Conference 2015 geschildert. Eines der Top-Themen waren die neuen Produkte und Lizenzmodelle. Bereits seit geraumer Zeit bereitet eZ Systems seine Nutzer, Partner und die Community auf den Wechsel zu eZ Platform vor.

Warum jetzt eZ Platform und nicht mehr eZ Publish? In der Praxis hat sich eZ Publish als leistungsfähige Online-Plattform für Projekte mit enormen Anforderungen an Content und Nutzerverwaltung bewährt und ist seinen Kinderschuhen als CMS zum Veröffentlichen (=Publish) von Internetseiten längst entwachsen. Im Zuge der nächsten Version wird sich dies nun auch im Namen des Produkts wiederspiegeln: aus eZ Publish wird eZ Platform.

Für professionelle Nutzer bietet eZ Systems künftig ein neues Produkt als Erweiterung zu eZ Platform an: eZ Studio richtet sich an Nutzer, die mehr möchten als ein CMS. eZ Studio ermöglicht ein intuitives Editieren der Seite während der Redakteur durch die Seite navigiert. Die entscheidende Erweiterung ist aber das interaktive Landingpage Tool, welches per Drag & Drop das komfortable Erstellen von Landingpages ermöglicht.

Aber was genau ist eZ Platform? Was macht eZ Studio? Und wo liegt der Unterschied zum alten eZ Publish? Hier der Versuch, ein klein wenig Übersicht in die Neuerungen zu bringen.

Continue reading “eZ Publish, eZ Studio, eZ Platform – What’s what?” »

eZ templating – Override an embed image template

16 Sep

eZ 5 allows to override embed templates as well. Right now it is hard to find out which data is passed to the template.

In order to override the template the template has to be configured in your yml file:

content_view:
    embed:
        imageEmbedRuleset:
            template: WebsiteBundle:block/content:image.html.twig
            match:
                Identifier\ContentType: [image]

In this case for ContentTypes of type image your template will be used

Place a template in your Resources/view folder (in this example Resources/views/block/content/image.html.twig is used):

{% if not ez_is_field_empty( content, 'image' ) %}
 
   {{ ez_render_field( content, 'image',
     { parameters: {
       alias: objectParameters.size|default( 'original' ),
       showFigure: false,
       align: objectParameters.align|default( 'center' )
      } }
     )
}}
{% endif %}

eZ passes a lot of parameters to the embed template:

embed-object_tpl-parameters

  • objectParameters.size: imageAlias used in the backend
  • content: your object which has been embedded
  • linkParameters: if a link has been set in the editor

eZ trouble shooting: Login into the new stack from the legacy stack

24 Aug

eZ Systems changed the way how logins are handled a few versions ago (versions > 5.3).

If your application still uses the legacy stack and you are using your own login module in the old stack you might have a problem: the new eZ (and Symfony) version will not login the user on the Symfony stack.

If you want to login a user in the new stack as well as in the legacy stack this solution in eZ 4 might help:

 $userId =  = 1224;
 $container = ezpKernel::instance()->getServiceContainer();
 try {
      
     $repository = $container->get('ezpublish.api.repository');
     $userService = $repository->getUserService();
     $ezUser = $userService->loadUser($userId);
     if ($ezUser) {
            $user = new CoreUser($ezUser);
            $providerKey = 'ezpublish_front';
            $token = new UsernamePasswordToken($user, null, $providerKey);

            $securityContextService = $container->get('security.context');
            $securityContextService->setToken($token);

            $repository->setCurrentUser($ezUser);
    } else {
            eZDebug::writeError('User with id '.$userId.' in new stack not found, login falied',__METHOD__);
    }
} catch (\Exception $e) {
     eZDebug::writeError("Exception while trying to login on new stack: ". $e->getMessage());
 }

eZ Conference 2015

18 Mai

eZ Conference 2015Es ist so weit – die ersten Informationen zur diesjährigen eZ Conference kommen herein und das Motto scheint ein klein wenig „Back to the roots“ zu sein, wie selbst eZ Systems bestätigt. Nach diversen Experimenten mit eZ Summit, eZ Unconference und eZ Days gibt es also in 2015 wieder eine eZ Conference.

Die Early Bird Registrierung läuft noch bis Anfang Juni. Und auch für Sponsoren und Speaker ist noch Platz, falls jemand sowieso zu dem Termin gerade in New York ist 😉 Alle aktuellen Infos dazu gibt es auf der offiziellen eZ Conference Website.

 

eZ-Publish-Blog.de wird zum silver.solutions Blog

27 Mrz

silver.solutions logo

Vor nunmehr fast 4 Jahren hat silver.solutions das eZ-Publish-Blog ins Leben gerufen. Damals sollte es helfen, den wachsenden Bedarf an Informationsmaterial und Interaktionsmöglichkeiten für Anwender und Entwickler in deutscher Sprache zu decken und neue Impulse geben. Das Blog bot Tipps und Tricks für eZ Entwickler, ebenso wie praktische Hilfen für Anwender und Hintergrundwissen für Entscheider.

In vier Jahren ist viel passiert. eZ setzt mit Version 5 des CMS nun auf das Framework Symfony und wird damit Teil einer größeren internationalen Community. Mit der ins Haus stehenden eZ Platform wird die grundlegende Basis der Software wieder Open Source und und damit wieder stärker Teil der Community. silver.solutions hat in den vergangenen 2 Jahren mit Hochdruck daran gearbeitet, die neue Version der eCommerce-Lösung silver.e-shop auf Symfony-Basis an den Start zu bringen. Nun wird es auch im Blog Zeit für einen Neuanfang.

Continue reading “eZ-Publish-Blog.de wird zum silver.solutions Blog” »