FIT 14.6.2 – Stability and Security

FIT 14.6.2 focuses on stability and security.

We have replaced our existing CSS minifier by an entirely new implementation. The CSS parser provides better standard compliance and is a lot faster, especially for CSS files with large embedded images. On top of that, the minifier produces smaller results. As part of our open source effort we have made our PHP7 CSS3 extension available at

We have improved system stability with a couple of new knobs for admins. Image compression refuses to optimize images that are larger than the configured maximum area in order to avoid excessive memory and CPU usage. Furthermore, we have added a new fit.ini setting that limits the number of concurrent image optimization processes. This is an effective means to protect your cluster from image compression overload, e.g. caused by an in-rush after a cache flush.

Last but not least, 14.6.2 is the first release to be shipped with PHP 7.1.

The SDK for 14.6.2 is available from Github.

Refer to the full changelog for a more detailed list of changes.

FIT 14.6.1 – Improved image optimization

FIT 14.6.1 is the first release for 2017. And, while being packed with lots of bug fixes and improvements for existing features, it even brings a few new features for both, development and administration.

First off, we added the function ends-with to our stack of XPath functions. starts-with was already accessible everywhere in FIT where an XPath expression is supported, adding ends-with rounds off the set of string checks available.

For operation and administration we also have 2 new features. We now officially support systemd, so you can use the native init management tools in state of the art Linux systems. And to prevent huge content from being processed and overly stressing your CPU resources we added the fit.ini setting FIT_MAX_CONTENT_SIZE. With that you can specify a maximum size (in MiB) for content processing. When a resource exceeds that size, it will not be processed, but passed through unoptimized.

On the improvement front, we worked a lot on our image optimization.

The image compression engine, that was introduced in FIT 14.6.0, will now perform the optimization experiments after the actual requests have been handled. So when an image is requested, FIT will respond with either the original or the best experiment result so far. After the response is sent to the client, FIT will run its experiments, so the next request can be responded with an optimized version of the image, while neither user had to wait for an experiment to finish. This only works for images that are cacheable by FIT. Images that may not be cached are still processed live.

To reflect the new compression options in our JavaScript APIs, we added new functions that let you either explicitly generate image compression (composeImageCompressionUrl) or image scaling (composeImageScalingUrl) URLs. And the already established function composeImageUrl will now create URLs according to your config settings.

Image delaying received some updates, too. While we now opt-out of delaying for img tags within, for example, noscript or template tags, FIT is now able to delay images that use the srcset attribute.

On a side note, we tweaked the performance of many features, from analytics over image processing up to resource loading.

The SDK for 14.6.1 is available from Github.

Refer to the full changelog for a more detailed list of changes.

FIT 14.6: Web Accelerator with next-generation Image Compression

This year’s last release is a big one. FIT 14.6 introduces our next-generation Image Compression engine.

To find the optimal representation for an image, the Image Compression engine performs a number of optimizations suitable for the input image. For example, lossy compression techniques (WebP/JPEG) may be applied to a photograph for substantial size improvements. Transparent PNGs may benefit from ZorroSVG mapping, or graphics from WebP lossless coding or quantization. The experiments are traffic-aware, so that frequently requested images are taken care of with higher priority.

<image-compression> can be used if Image Scaling is disabled. As a bonus, the handling of Image Compression URLs in HTML (and CSS) documents is much faster, which reduces the footprint of HTML processing in the critical path.

As a BETA feature, we have added an automatic image quality assessment tool. Lossy compression usually achieves the highest byte savings. However, it is impossible to find a compression level (ironically often called “quality”) that balances compression and quality for all images. Different images show different patterns of degradation if the compression level is increased. While some images still look good with JPEG “quality” 30, other images may start showing visible artifacts already at high levels like 90. The common solution is to raise the quality for all images. You can now define the compression level by means of quality: “Compress an image as much as possible, as long it looks like the original”. This can be a real byte-saver! It allows us to apply lossy compression to input images in lossless formats without the risk of quality degradation. As this is beta, we would love to hear your feedback about this!

Another interesting beta feature is the HTML5 compliant parser. It parses HTML documents exactly like your browser, and you can still use all FIT development features like XSLT and XPath.

As this is a major release, the various bug fixes, 3rd party updates and smaller improvements are accompanied by a couple of removals of previously deprecated features. So please pay close attention to the changelog.

The SDK for 14.6 is available from Github.

Refer to the full changelog for a more detailed list of changes.

FIT 14.5.3 & Web Accelerator: Delayed iframes and more

In addition to fixing bugs FIT 14.5.3 introduces new and improved Web Accelerator features.

In many modern projects, iframes are used for social media widgets and user tracking. They usually have no impact on the perceived performance of a web page. But there are also sites that have iframes with heavy-weight media content such as youtube videos. Loading megabytes of videos slows down page loading tremendously, even in iframes.

To ensure that users will only load content they are about to see, we introduce delayed iframes. The delayed loading for iframes works exclusively with visibility based loading: The source of the iframe is going to be loaded when the iframes comes close to or into the browser’s viewport, for example by scrolling the page. Due to the unknown nature of the included content of iframes (small tracking and social media vs large videos), the feature cannot be activated globally. You have to enable it in config.xml and mark the individual iframe element with the ai-delay="true" attribute.

Probably even more exciting is an improvement we made for delayed images. If the dimensions of images are already known (i.e. the image is in the FIT cache) FIT will generate an SVG image with the same intrinsic size as the final image (instead of a transparent 1x1px GIF). Hence, the layout of the page will remain unchanged when the final image is loaded and replaces the placeholder. This saves a lot of browser reflows and avoids “jumping pages”. The SVG placeholder also clears the way for more promising improvements to the delayed image placeholders, so stay tuned for further news on the topic in upcoming releases.

The SDK for 14.5.3 is available from Github.

Refer to the full changelog for a more detailed list of changes.

Sevenval FIT 14.5.2

FIT 14.5.2 is another release bringing mostly bug fixes and improvements for existing features.

Delayed images prioritized to be loaded when they are going to become visible considerably reduce traffic. But if visitors want to print sites, they are basically missing every image that neither is nor has been in the viewport. The new parameter of the loadHQImages function makes the client load all images, whether they are in the viewport or not. And the new event delayedimagesloaded informs you when the client finished doing so. So this combination offers means to prepare the site for printing and lets you know when preparing has finished.

FIT 14.5.1 already addressed noise in the logs. We identified another source for noise, namely overly greedy bots (such as Google spiders) interpreting JavaScript strings starting with a / as relative URLs. So when you write something like <script>var foo = '/bar';</script> into your document, it will not take long until you notice said spiders requesting the resource /bar. This will probably lead to unnecessary 404 responses, inflating the FIT server logs and backend server logs, thus probably hiding real problems from you. FIT 14.5.2 will no longer generate JavaScript strings starting with a /.

Additionaly, fixing issues with the image scaling cache has reduced the CPU usage noticeably.

The SDK for 14.5.2 is available from Github.

Refer to the full changelog for a more detailed list of changes.


WirUm4-Vortrag: Web Architektur bei Sevenval

WirUm4 ist unsere Vortragsreihe von Kollegen für Kollegen, die stets nachmittags stattfindet. Zuletzt hat Robert Großer unsere Web Architektur vorgestellt. 

Um unseren Kunden moderne Webtechniken anbieten zu können, betreiben wir bei Sevenval in unseren Rechenzentren eine komplexe Infrastruktur. In seinem WirUm4-Vortrag erläuterte Robert die Komponenten der Web-Architektur und legte besonders Augenmerk auf die verschiedenen Stationen beim Request-Durchlauf, die für Caching eingesetzt werden können. So befindet sich, neben dem auf den FIT Servern eingesetzten FIT HTTP Cache, sowohl vor den FIT Servern ein Cachingserver (Varnnish Cache), als auch hinter den FIT Servern zu den Kundenbackenservern für http-Requests ein Proxy Cache (Squid).

In einer Simulation eines Requests beginnend vom anfragenden Handy bis hin zu dem Kundenbackend erläuterte Robert den Teilnehmern den vollständigen Ablauf inklusive DNS-Auflösung und SSL-Entschlüsselung. Das erworbene Wissen soll vor allem dabei helfen, ungenutzte Caching-Potentiale in Projekte zu erkennen, diese zu nutzen und die Identifizierung aufgetretener Fehler zu beschleunigen.


Ladezeiten sparen mit dns-prefetch, preconnect, preload und HTTP/2 push

Unser Kollege Johannes stellte in einem internen Vortrag Resource Hints und diverse andere Methoden vor, mit denen Ladezeiten von Websites und externen Inhalten bzw. Ressourcen verkürzt und die Performance verbessert werden können. Thematisiert wurden dns-prefetch, preconnect, preload und HTTP/2 push.

Durch explizites Aufrufen von DNS-Prefetching kann die Auflösung von IP-Adressen bereits vor dem Aufruf von Inhalten externer Domains durchgeführt werden. Da die Einbindung externer Domains ihren Aufruf mit sich bringt, wird dadurch möglicherweise das Laden einer Website verlangsamt. Die Verwendung von DNS-Prefetch-Links kann also dabei helfen, die Ladezeit um einige (Mili-)Sekunden zu verbessern.

WPT ohne alles

Ersten Laden ohne Optimierung (Usecase: Font Loading)

wpt dns prefetch

Ladezeiten mit DNS-prefetch (Usecase: Font Loading)

Preconnect hingegen ermöglicht es dem Browser Verbindungen einzurichten, bevor eine HTTP-Anfrage an den Server gesendet wird. Teure Roundtrips, die durch DNS-Lookups, TCP-Handshake und ggfs. TLS-Negotiaton entstehen, können hierdurch aus dem Request-Ablauf eliminiert und Ladezeiten verkürzt werden.

wpt mit preconnect

Ladezeiten mit preconnect (Usecase: Font Loading)

Bei Preload handelt es sich um einen neuen Web-Standard, der mehr Kontrolle bei der Anforderung bestimmter Ressourcen ermöglicht. Einen nützlichen Anwendungsfall stellt unter anderem die frühe Beschaffung kritischer Ressourcen dar, deren Ausführung erst später erwartet wird.

HTTP/2 push erlaubt das Senden von Subressourcen, bevor diese von Client angefordert wurden. Die Zeit, in der das HTML „zusammengebaut“ wird, kann somit überbrückt und die Performance hierdurch verbessert werden. Cache-bare Ressourcen sollten jedoch nicht gepusht werden, da nicht alle Browser den Cache prüfen und den Push ggfs. unterbrechen. Die Verwendung von HTTP/2 push sollte daher nur in Verbindung mit einer sinnvollen Cache-Lösung stattfinden.

FIT 14.5.1 – Web Accelerator vs Bigimage

This month’s release is mostly a “smoothing” release comprising a lot of bug fixes and smaller improvements, as well as 3rd party updates and security patches.

One of the most common errors that we have encountered in our log files was a complaint about source images being too large: … image area exceeds limit of 8 Mpixels. Of course, 8 million are a lot of pixels. But with the proliferation of high resolution cameras (in smartphones) and high density displays (also in smartphones), prepare to encounter large images in Web sites more frequently. However, the worst part of the error message was: Continue with original source. That means that of all things the largest images on your Web site are “too large to optimize”. The client has to load all these big files as they are. Even if those might be the outliers of your image files, a single large image with megabytes of data will outweigh every little byte saved by thoroughly optimizing everything else.

Acknowledging this problem, the Web Accelerator now supports sources images with up to 100 mega pixels. Image Scaling will drastically reduce the file size of large images by allowing optimizations such as format conversion or lossy compression. On our systems, we have seen savings of multiple mega bytes per image. To mitigate the operational costs of processing huge pixel arrays, images with more than 8 mega pixels are processed with an algorithm that is less precise but faster than our usual scaling method. Given so many pixels, there is no noticeable difference.

Don’t let the legendary Bigimage eat your bandwidth! Update today!

Refer to the full changelog for a more detailed list of changes.


New Web Accelerator Tutorials Published

We have just published some new tutorials to get you up and running with the latest features of the Sevenval Web Accelerator (WA). The tutorials look at how to use WA for image optimization, content optimization, and request reduction. If you are new to WA, or if you simply want a general, hands-on overview of its most common features, then these tutorials are for you!

Continue reading

Progressive Web App Dev Summit 2016 in Amsterdam

I had the privilege to attend the Progressive Web App Dev Summit 2016 in Amsterdam. Google invited developers to learn and share experiences about Progressive Web Apps: web sites that comprise a combination of HTTPS, Service Workers, application manifest for features like add to home screen or push notifications and – maybe more as a result from making great web apps rather than being a PWA feature itself – reliable performance.

Google did a great job in choosing top-of-the-line speakers. Continue reading