Found 15 results in Site performance

While YouTube embed options are powerful and effective, they are not always the most efficient use of resources when it comes to bandwidth. Using a facade can help decrease page load time and increase site performance without sacrificing any of the utility of the native YouTube embed options. 

Sometimes, Apache Solr doesn’t index data in just the way you need for your custom search criteria. When you need to add data not indexed by default in the Solr search engine, the document field mapper should be created to fit your needs.

A few months ago we discussed the importance of A/B testing to help your business build a winning digital strategy. In this blog post, I’ll show you how to use Optimizely, a leading A/B testing platform, to create your first experiment to study, analyze and decide what’s the best move for your content and key site pages.

Dealing with permissions and security systems such as Security-Enhanced Linux (SELinux) is an issue that seems to challenge many developers. Some enterprise Linux distributions like Red Hat and CentOS come with SELinux enabled by default, but not knowing how SELinux works can lead developers to disable it. This is a mistake.

I recently did a performance review for a server setup running more than 200 websites. The infrastructure is hosted at Amazon Web Services (AWS). It contains multiple web servers behind multiple Varnish caching servers, uses Relational Database Service (RDS) for database storage, and uses Elastic File System (EFS) for storing assets like content images and documents. There were several areas of performance optimization to be done, which was a good development exercise and resulted in an improved user experience. Most importantly, though, the results also saved bandwidth; reduced the number of servers, number of CPUs, and amount of RAM required; and saved money! A faster site also improves SEO, which will drive more visitors / customers to your site, and will increase conversions.

Your eZ site might be serving megabytes of unnecessary image data on every page load. Do your users and your SEO rankings a favour: strip image metadata and set a reasonable image quality setting for your image aliases!

For one of our high-traffic clients, we switched the Content Delivery Network (CDN) from Akamai to Amazon CloudFront. This blog post looks at why we decided to change the CDN and describes the switching process. Plus we share some useful tips about how to configure CloudFront.

In eZ Publish 5.x and eZ Platform, the concept of "view cache" has changed. The "module result" part of it (which was basically page-level caching if we didn't count the pagelayout) has been offloaded to HTTP caching, most often implemented with Varnish. In addition, Cache blocks no longer exist and have been replaced by ESI (Edge Side Includes) blocks.

The persistence caching element -- that is, caching of your actual content from the database -- of the "view cache" still exists, handled by default on the file system through the Stash bundle. Stash also supports memcache (which, as its name suggests, uses memory, and has a much better performance). We use memcache(d) for all of our production sites.

A good caching system keeps elements in the cache as long as possible, but clears them as soon as the elements are updated. For content pages in eZ Publish and most content management systems, "purge-on-publish" features are well documented. When it comes to JavaScript and CSS files, there are usually different caching systems involved, and these are important to configure. Otherwise, you'll end up with the all-too-familiar problem of a broken front-end on deployments, where the only fix is to have users do a "hard refresh" (CTRL+F5) in the browser.

In order to increase the image serving performance of high-traffic websites and improve the editorial user interface around image management, Mugo Web came up with an alternative way to serve content images in eZ Publish.  It is aptly titled the "Mugo Image Server for eZ Publish".

eZ Publish 5 comes with built-in Varnish Cache support. Essentially this means that when content is published in the eZ Publish back-end, it notifies Varnish so that the Varnish cache is cleared. This feature is often called "purge-on-publish" and makes it so that you can cache your pages for a very long time, but that edits refresh the cache and thus appear immediately. To get this native support, you just have to use the "new stack" in eZ Publish. However, even if your legacy site is not ready to be fully upgraded to the new stack and you are running eZ Publish 5 in "legacy mode", you can take advantage of this native support.

Varnish is great for high traffic sites where the same pages are served over and over to millions of visitors, but when you have to do something differently depending on the specific user or user group, things get complicated. There are several techniques, and how you might use them depends on the details. Here, we have outlined a solution for a particular use case on eZ Publish.