Optimizing Angular applications for speed and efficiency requires a deliberate strategy. In this article, I'll explore six key techniques to enhance performance: image optimization, routing, deferrable views, change detection, the async pipe, and the trackBy function. These methods address common bottlenecks, helping you build faster, more responsive applications.
This article provides real-world examples, screenshots, and bundle size comparisons to illustrate the impact of each optimization. It requires that you understand Angular Applications. By the end, you'll have a clear roadmap for improving your Angular app's performance and minimizing unnecessary re-renders.
Image Optimization: Faster Loads without Quality Loss
When it comes to performance improvement, developers often focus on JavaScript bundle size or lazy-loading routes. However, images significantly impact page load times as well. Poorly optimized images can lead to longer loading times, increased data usage, and a subpar user experience, especially on mobile devices with slower connections. Angular's latest image optimization features streamline the process of loading images efficiently while preserving quality. The key to these optimizations lies in the NgOptimizedImage directive, which enhances image performance through several advanced techniques.
Responsive Images and Automatic srcSet
Responsive images ensure that the correct-sized image is served based on the device's screen size and resolution, reducing the need for browser resizing. Manually managing responsive images with different sizes can be complex, but Angular simplifies this by automatically generating a srcSet for various breakpoints. This feature works with or without the sizes attribute, reducing the need for manual intervention. It ensures that lower-resolution images load on low-DPI screens and high-resolution images on high-DPI devices, improving both performance and visual clarity.
Consider the following snippet that doesn't use the sizes attribute:
<img width="200"
height="200"
priority="true"
ngSrc="angular.jpg" />
Angular automatically generates a density-dependent srcSet based on device pixel ratio (DPR):
<img width="200"
height="200"
priority="true"
src="https://.../angular.jpg"
srcset="https://...f_auto,q_auto,w_400/angular.jpg 1x,
https://...f_auto,q_auto,w_800/angular.jpg 2x">
This means that a 1x image is served to standard-resolution screens, and a 2x image is served to high-resolution screens such as retina displays. High-density screens, like those found on newer iPhones and Android devices, typically use a DPR of 3 or higher.
In Chrome Developer Tools, you can adjust the display density to test this behavior. Looking at the previous examples, you can see in Figure 1 that when the density is set to 1, the downloaded image is 400x400.
When you increase the density to 2 (Figure 2), the downloaded image scales to 800x800. This works effortlessly with the image provider out of the box.
Using the sizes attribute provides additional flexibility by allowing developers to specify how images should scale depending on viewport size. For example, setting the image to occupy 80vw (80% of the viewport width) ensures better responsiveness:
<img width="200"
height="200"
priority="true"
sizes="80vw"
ngSrc="angular.jpg" />
With this set up, Angular dynamically generates a srcSet that includes breakpoints, ensuring that users receive appropriately sized images based on their screen width.
<img
width="200"
height="200"
priority="true"
sizes="80vw"
src="https://.../angular.jpg"
srcset="
https://...f_auto,q_auto,w_16/angular.jpg 16w,
https://...f_auto,q_auto,w_32/angular.jpg 32w,
https://...f_auto,q_auto,w_48/angular.jpg 48w,
https://...f_auto,q_auto,w_64/angular.jpg 64w,
https://...f_auto,q_auto,w_96/angular.jpg 96w,
https://...f_auto,q_auto,w_128/angular.jpg 128w,
https://...f_auto,q_auto,w_256/angular.jpg 256w,
https://...f_auto,q_auto,w_384/angular.jpg 384w,
https://...f_auto,q_auto,w_640/angular.jpg 640w,
https://...f_auto,q_auto,w_750/angular.jpg 750w,
https://...f_auto,q_auto,w_828/angular.jpg 828w,
https://...f_auto,q_auto,w_1080/angular.jpg 1080w,
https://...f_auto,q_auto,w_1200/angular.jpg 1200w,
https://...f_auto,q_auto,w_1920/angular.jpg 1920w,
https://...f_auto,q_auto,w_2048/angular.jpg 2048w,
https://...f_auto,q_auto,w_3840/angular.jpg 3840w
">
Priority Directive for Optimized Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) is a key web performance metric that measures the time it takes for the largest visible element to render. Because images often contribute to LCP, Angular provides a priority attribute that marks critical images for faster loading. This is especially useful for above-the-fold content, such as company logos or banner images.
For applications using server-side rendering (SSR), marking an image with priority also triggers automatic <link rel="preload"> insertion, instructing the browser to fetch the image earlier in the loading process.
<img ngSrc="angular.jpg"
width="800"
height="400"
priority="true" />
This small addition can significantly reduce perceived load time and improve user experience.
Lazy loading is a technique that defers the loading of off-screen images until they are needed, preventing unnecessary network requests and reducing initial page load times. Angular applies lazy loading by default to non-priority images:
<img ngSrc="angular.jpg"
width="800"
height="400"
loading="lazy" />
However, it's important to avoid lazy loading for images that are immediately visible on page load, such as logos and banner images. These should be marked with priority="true" to ensure they load as quickly as possible.
When an image is marked with the priority attribute, the fetch priority is automatically set to high, and the loading attribute is set to eager. Angular also automatically adjusts the fetchpriority to high, instructing the browser to download the image as soon as possible. This can significantly improve the LCP.
LCP is a key loading metric that tracks how long it takes for the page's largest content element to load. In most cases, this is an image, as images generally take longer to display than text. The browser needs to find, download, and render the image. To optimize this process, use the priority attribute. Let's first examine what happens without setting a priority:
<img src="angular.jpg"
width="200"
height="200" />
By default, the priority of this image is set to low, which you can observe in the Priority column in the Network tab of Chrome Developer Tools. When the browser detects that the image is in the viewport, it automatically changes the priority to high. You will only see this if you enable the Big Request Rows option (Figure 3 Label 1) under settings, which will display both the initial and final priorities (Figure 3 Label 2).
This behavior shows you that the browser performs extra work to change the image's priority from low to high. This is where the priority attribute becomes crucial.
Now, let's modify the example by adding the fetchpriority attribute and setting it to high:
<img src="angular.jpg"
width="200"
height="200"
fetchpriority="high" />
With this change, you can see in the Network tab that both the initial and final priorities are set to high (Figure 4). This is especially useful for critical elements like banners and logos that need to appear as soon as the page loads.
Another benefit is that if you're using the directive with an image provider and haven't set the priority, the directive throws an error if the image is in the viewport. The error message notifies you to mark the image with priority:
NG02955: The NgOptimizedImage directive (activated on an <img> element with the ngSrc="https://res.cloudinary.com/dnj0y4eck/image/upload/f_auto,q_auto/angular.jpg";) has detected that this image is the Largest Contentful Paint (LCP) element but was not marked “priority”. This image should be marked “priority” in order to prioritize its loading. To fix this, add the “priority” attribute.
Placeholder Directive for Visual Feedback
The placeholder directive enhances the user experience by displaying a low-resolution or base64-encoded placeholder image while the main image is still loading. This ensures that users see immediate feedback instead of a blank space. For example, if you're using a CDN like Cloudinary, it can automatically generate placeholders for you, or you can specify your own. To optimize performance, keep placeholder images below 4KB in size.
To implement this feature, simply add the placeholder attribute to your image tag:
<img ngSrc="angular.jpg"
width="200"
height="200"
priority="true"
placeholder />
By default, this automatically downloads a low-resolution image from your image provider. If you'd prefer to use a custom placeholder, you can set the placeholder attribute to a Base64-encoded image. Figure 5 shows how the blurry image will appear.
<img ngSrc="angular.jpg"
width="200"
height="200"
priority="true"
placeholder="data:image/svg+xml;base64…" />
Note: Base64-encoded placeholders should be kept small. If the placeholder exceeds 4000 characters, you'll receive an error:
NG02965: The NgOptimizedImage directive (activated on an <img> element with the ngSrc="angular.jpg") has detected that the placeholder attribute is set to a data URL which is longer than 4000 characters. This is discouraged, as large inline placeholders directly increase the bundle size of Angular and hurt page load performance. For better loading performance, generate a smaller data URL placeholder.
By default, placeholder images are displayed in a blurry state to provide a smooth transition while the final image loads. You can disable this effect using the placeholderConfig attribute:
<img ngSrc="angular.jpg"
width="200"
height="200"
priority="true"
[placeholderConfig]="{blue:false}"
placeholder="data:image/svg+xml;base64…" />
Loaders
Loaders are essential for serving high-quality images, especially when working with CDN providers and responsive images. In this section, you'll see how to apply and customize loaders directly from the image element.
CDN providers like Cloudinary automatically create multiple versions of an image, and, with the help of the directive, the browser can download the right size based on the device, improving your application's performance. You can also transform image URLs for further optimization. To use a CDN loader, set the loader in your PROVIDERS array:
Angular provides five preconfigured loaders that you can use out of the box. If you want to use your custom loader, you need to provide the IMAGE_LOADER DI token and a loader function that takes an ImageLoaderConfig as an argument and returns the absolute URL of the image. Both can be imported from the Angular common package:
providers: [
{
provide: IMAGE_LOADER,
useValue: (cfg: ImageLoaderConfig) => {
const base = 'https://example.com/images?src=';
return `${base}${cfg.src}&width=${cfg.width}`;
}
}
]
You can also use the loaderParams attribute from the directive to pass additional parameters into your loader function. The loaderParams attribute is part of the ImageLoaderConfig and can contain any data you want to pass along. Here's an example:
<img src="profile.jpg"
width="300"
height="300"
[loaderParams]="{bustCache: true}" />
In your loader function, you can access and use these parameters to modify the loader's behavior. For example, you could use the bustCache parameter to force the browser to fetch a fresh image instead of using a cached version:
const myCustomLoader = (config: ImageLoaderConfig) => {
const base = 'https://example.com/images/';
let url = `${base}${config.src}?`;
let queryParams = [];
if (config.loaderParams?.bustCache) {
queryParams.push('bustCache=true');
}
return url + queryParams.join('&');
};
Finally, to ensure that your loader works correctly, you must add preconnect links to your index.html. The preconnect tells the browser to download critical resources as early as possible, reducing the time spent discovering them:
<link rel="preconnect" href="https://res.cloudinary.com">
Routing: Lazy Load Modules
Lazy loading is crucial for optimizing the performance of your Angular application, especially in large applications. It ensures that the initial load time remains low by only loading feature modules when needed. This reduces unnecessary code from being loaded up front and prevents excessive network usage. In this section, I'll explore how to configure lazy loading for routes, compare bundle sizes between lazy loaded and eagerly loaded routes, and discuss preloading strategies.
Why Lazy Loading Is Important
Lazy loading significantly reduces both the bundle size and initial load time, improving overall application performance. Angular creates a separate chunk of JavaScript for each lazy-loaded module or component, which is only loaded when necessary. This approach not only speeds up the initial page load but also enhances memory management by preventing unused code from being loaded into the browser.
Lazy loading optimizes resource usage by ensuring that only the most critical resources are loaded initially, leaving non-essential resources to be loaded later. This is particularly useful in enterprise-level applications where the user may not need all features right away, such as an admin panel that should only be available to users with the appropriate roles.
How to Configure Lazy Loading in Standalone Components and Modules
Angular has built-in support for lazy loading from the early days, and configuring it is straightforward. Let's first look at a typical eager-loaded configuration and its bundle size:
export const routes: Routes = [
{
path: 'foo',
component: FooComponent,
},
{
path: 'bar',
component: BarComponent,
},
// other routes
];
In this example, both FooComponent and BarComponent are eagerly loaded. For a real-world enterprise-level Angular application with multiple components, the main bundle can become quite large, even though not all features are used immediately. Some features may never be used depending on the user's authentication role, like the aforementioned admin panel.
If you build the application with eager loading, you'll see the bundle size like that in Figure 6:
This data in Figure 6 shows that all components are bundled together, resulting in several chunk files. Although the main bundle size is relatively small with just 10 small components, real applications typically have more and larger components, which increase the bundle size significantly.
To enable lazy loading, you need to change your routing configuration to use loadComponent (for standalone components) or loadChildren (for modules).
Here's an example:
export const routes: Routes = [
{
path: 'foo',
loadComponent: () => import('./foo.component')
.then((m) => m.FooComponent),
},
{
path: 'bar',
loadChildren: () => import('./bar.module')
.then((m) => m.BarModule),
},
…
];
In this updated configuration:
- The first route uses
loadComponentto lazy load FooComponent as a standalone component. - The second route uses
loadChildrento lazy load BarModule.
After lazy loading, the bundle size decreases significantly (Figure 7).
You can see that the main bundle (Figure 7) has reduced in size from 396.99 KB to 106.88 KB, representing a 78% reduction. This reduction improves initial load times and performance. You can also see additional chunk files that will be lazy loaded.
What Preloading Is and How to Apply It
Lazy loading improves performance by loading only what's needed, and preloading goes one step further. Preloading allows you to load modules in the background without the user having to navigate to the route first. This can improve user experience by ensuring that modules are ready when the user reaches them, without delay.
Preloading is particularly useful if you know the user is likely to visit certain routes soon after the initial page load. By combining lazy loading with preloading, your application will have a small initial bundle while loading additional resources in the background.
To enable preloading in a module-based application, use the preloadingStrategy property and set it to PreloadAllModules:
import { PreloadAllModules } from '@angular/router';
RouterModule.forRoot(appRoutes, {
preloadingStrategy: PreloadAllModules
});
For standalone components, use withPreloading in the provideRouter function:
import { ApplicationConfig } from '@angular/core';
import { PreloadAllModules, provideRouter, withPreloading }
from '@angular/router';
import { routes } from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes, withPreloading(PreloadAllModules)),
],
};
With preloading in place, Angular preloads modules in the background while the user is interacting with the current page. This ensures that when the user navigates to another route, the necessary resources are already available.
You can also create a custom preloading strategy by implementing the PreloadingStrategy interface. This allows you to control which modules to preload based on specific conditions.
Here's an example of a custom preloading strategy that only preloads certain modules if the route data contains a preload flag:
import { PreloadingStrategy, Route } from '@angular/router';
import { Observable, of } from 'rxjs';
export class AdminPreloadingStrategy implements PreloadingStrategy {
preload(route: Route, load: Function): Observable<any> {
return route.data && route.data['preload']
? load() : of(null);
}
}
In your routing configuration, set the preload flag for the routes you want to preload:
export const routes: Routes = [
{
path: 'admin',
loadComponent: () => import('./admin.component')
.then((m) => m.AdminComponent),
data: { preload: true }
},
…
];
Now you can use this custom strategy in your app configuration:
// other imports
import { AdminPreloadingStrategy } from '…';
import { routes } from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes,
withPreloading(AdminPreloadingStrategy)
),
],
};
This strategy is useful when you're certain that a user will visit a specific section of your application, such as the admin panel. By preloading those modules, you ensure that users experience minimal delays when accessing those sections.
Deferrable Views: Conditional Rendering for Performance Gains
Deferrable views allow you to delay the rendering of non-critical content until a specific condition is met, enhancing the performance of large applications with multiple sections. Angular's @defer directive enables you to control the timing of component rendering, which can be triggered by various conditions such as user interaction, idle time, or a timer. In this section, I'll explore how to use @defer along with other directives like @placeholder, @loading, @error, and custom triggers for conditional rendering, as well as the impact of these techniques on performance.
You can also combine deferred views with lazy-loaded routes. This approach ensures that not only the route but also the content on the page is lazy loaded. This synergy boosts application performance by ensuring that deferred or lazy-loaded content is not part of the initial bundle, thus reducing the initial load size.
Deferred Rendering with @defer
The @defer directive allows you to delay the rendering of a component or template until a specific condition is met, such as user interaction or idle time. By deferring the rendering of non-critical content, you can optimize load times and ensure that only essential content is shown up front.
Here's how you can use the @defer directive:
@defer () {
<app-images></app-images>
}
If no triggers or conditions are specified, the deferred block is triggered when the browser state becomes idle. This is the default behavior:
@defer (on idle) {
<app-images></app-images>
}
When you build your application using this technique, you'll notice that the component is lazy loaded (Figure 8), reducing the initial bundle size.
When the component is used, you can observe the additional bundle being loaded at runtime in Chrome Developer Tools (Figure 9).
Placeholder and Loading Indicators
While deferred components are loading, Angular allows you to display temporary placeholders or loading indicators using the @placeholder and @loading directives. These directives help improve the user experience by providing visual feedback during the loading process.
Keep in mind that the content inside the @placeholder and @loading blocks isn't lazy loaded. These blocks serve as visual feedback before or during the loading of the deferred content.
Here's how to implement the placeholder:
@defer() {
<app-images></app-images>
}
@placeholder(minimum 500ms) {
<p>Loading Images…</p>
}
In this example, the placeholder is shown for at least 500ms before the deferred content is loaded. This argument is optional, and it helps avoid flickering if the content loads too quickly.
The @loading block is similar, but it displays content while the deferred component is still loading or after it has started loading:
<app-images></app-images>
<p>Loading Images…</p>
In this example, the loading indicator appears after 1 second and stays visible for at least 500ms. This also helps to avoid flickering.
You can combine the @placeholder and @loading blocks for a good loading experience:
<app-images defer></app-images>
<loading after="1s" minimum="500ms">
<p>Loading Started</p>
</loading>
<placeholder>
<p>Loading Images…</p>
</placeholder>
In this example:
- The placeholder appears first to inform the user that images are loading.
- The loading message is displayed after a one-second delay.
Custom Triggers with @triggers
Angular's @defer directive offers flexibility through custom triggers, which allow you to define when the deferred content should load based on specific conditions.
Triggers are specified using when or on conditions. These conditions return a Boolean value to determine when to render the content. Here's an example using the when condition:
@defer (when condition) {
<app-images></app-images>
}
@placeholder {
<p>Loading Images…</p>
}
In this example, the content is deferred until the specified condition is true. Once the condition becomes false, the placeholder will not reappear (one-way interaction).
You can also use the on trigger, which is evaluated when one of the specified conditions is met. The conditions are evaluated using logical OR. Here's an example using multiple on triggers:
@defer (on interaction; on timer(5s)) {
<app-images></app-images>
}
@placeholder {
<p>Loading Images</p>
}
In this example:
- The deferred content loads either when the user interacts with the element (e.g., click or keyboard event) or after five seconds.
- The placeholder shows while the content is being deferred.
You can also mix when and on conditions, and they will still be evaluated using logical OR. For instance:
@defer (on interaction; when condition) {
<app-images></app-images>
}
@placeholder {
<p>Loading Images...</p>
}
This example uses a combination of interaction and condition to trigger the deferred content.
Error Handling with @error
In case deferred content fails to load, Angular provides the @error directive to display an error message. This can help inform users when a resource cannot be loaded successfully.
Here's an example of using the @error directive:
@defer () {
<app-images></app-images>
}
@error {
<p>Failed to load Images.</p>
}
Change Detection: Optimizing Component Checks
Change detection is an essential mechanism in Angular, responsible for keeping the DOM in sync with the application state. However, it can become a performance bottleneck in large, complex applications, especially when the component tree is deep or when there are frequent input changes. In this section, I'll explore how to optimize change detection strategies to improve performance.
Default Change Detection
By default, Angular uses a global change detection strategy, which checks every component in the component tree when any change occurs. This means that if a change happens anywhere in the application, Angular checks every component from the root to the affected one. In large applications with deeply nested components or frequent input changes, this global sweep can result in significant performance issues.
OnPush Strategy for Smart Updates
To address such performance issues, Angular provides the ChangeDetectionStrategy.OnPush strategy. When you use OnPush, Angular only checks the component when one of its @Input() properties changes by reference. This dramatically reduces the number of change detection checks and significantly boosts performance.
Here's an example of how to implement OnPush:
@Component({
selector: 'app-user',
templateUrl: './user.component.html',
changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserComponent {
@Input() user: User;
}
In this case, the component only re-renders when a new user object is passed in. If the same object reference is passed again, Angular skips change detection for that component.
Immutable Data and Change Detection
To maximize the performance benefits of OnPush, it's important to follow immutable data practices. Instead of directly modifying an object, always return a new instance of the object. This allows Angular to detect changes and trigger re-renders only when necessary.
this.user = { ...this.user, name: 'Updated Name' };
This ensures that Angular detects the change and updates the view only if a new object reference is passed to the component.
Optimizing Templates
In Angular templates, avoid expensive operations like method calls or property getters, as they can trigger unnecessary evaluations during change detection.
<!-- Avoid this -->
<p>{{ calculateScore() }}</p>
<!-- Better -->
<p>{{ score }}</p>
Instead of calculating values in the template, pre-compute them in the component class. This reduces the number of evaluations Angular needs to perform during change detection and improves overall performance.
Manually Triggering Detection with ChangeDetectorRef
In some edge cases, you might need more control over change detection. Angular provides the ChangeDetectorRef service, which allows you to manually trigger change detection when necessary.
constructor(private readonly cdr: ChangeDetectorRef) {}
updateUI() {
this.cdr.detectChanges();
}
This technique is useful when you need to manually trigger change detection after making changes that Angular doesn't automatically detect (e.g., changes outside Angular's zone or changes triggered asynchronously).
Async Pipe and trackBy: Avoid Unnecessary DOM Repaints
At this stage, you're already familiar with several strategies to boost Angular performance. Another key tip is using the async pipe, trackBy function and avoiding multiple async pipes on the same observable. It's a small adjustment that can make a noticeable difference in rendering efficiency, especially in large lists or frequently updating views.
Leveraging the Async Pipe
The async pipe in Angular is a powerful tool for subscribing to observables or promises within templates. It automatically handles subscription management and ensures that the view is updated only when new values are emitted.
<div *ngIf="user$ | async as user">
<p>{{ user.name }}</p>
</div>
Using the async pipe ensures that Angular doesn't run unnecessary change detection cycles on components that aren't actively receiving new data. It also simplifies subscription handling by automatically cleaning up the subscription when the component is destroyed.
Avoid Multiple async Pipes on the Same Observable
A common performance mistake is using the async pipe multiple times for the same observable within a single template. Each instance creates a separate subscription, leading to performance issues and potentially duplicate HTTP requests.
Problematic example:
<p>{{ (user$ | async)?.name }}</p>
<p>{{ (user$ | async)?.email }}</p>
Optimized example:
<ng-container *ngIf="user$ | async as user">
<p>{{ user.name }}</p>
<p>{{ user.email }}</p>
</ng-container>
In the optimized version, you only create one subscription and avoid multiple observable executions, which improves performance.
Avoiding DOM Churn with trackBy
When using *ngFor or @for to render lists in Angular, the default behavior is to re-render the entire list whenever the data changes. This can be costly, especially for long lists or complex DOM elements. To optimize this, you can use the trackBy function to tell Angular how to track items in the list and reuse DOM elements where possible.
Without trackBy:
<li *ngFor="let item of items">
{{ item.name }}
</li>
With trackBy:
<li *ngFor="let item of items; trackBy: trackById">
{{ item.name }}
</li>
Component code:
trackById(index: number, item: Item) {
return item.id;
}
The trackBy function minimizes unnecessary DOM manipulations by reusing elements with the same identifier (in this case, item.id). This saves resources and improves performance, especially when dealing with large lists.
Conclusion: Boosting Angular Performance for Scalable Applications
Optimizing performance is crucial for building scalable and responsive Angular applications, especially as they grow in complexity. In this article, you've explored a variety of strategies and techniques that can help you improve the performance of your Angular applications from the ground up.
By using lazy loading and deferred rendering, you can significantly reduce the initial loading time and avoid unnecessary resource consumption. Lazy loading routes and deferring non-essential content ensure that only the critical elements are loaded first, enhancing both perceived and actual performance.
Change detection optimization is another critical area for enhancing performance. By adopting OnPush change detection and following immutable data practices, you can minimize unnecessary checks, reducing the overhead of Angular's default change detection mechanism. Additionally, using tools like async pipes and trackBy for list rendering ensures that your app remains responsive, even when handling large amounts of data or frequent updates.
The combination of these techniques, when applied thoughtfully, allows you to create Angular applications that are not only faster but also more maintainable. Whether you're working on a small project or a large enterprise-level application, performance optimization should be at the forefront of your development process.
As web applications become more complex and the expectations of end-users rise, it's important to focus on these performance aspects early in the development lifecycle. By continuously refining your codebase with performance in mind, you'll create Angular applications that provide an excellent user experience while scaling efficiently.
By mastering these performance strategies, you can ensure that your Angular applications stay fast, responsive, and prepared for the demands of modern web development.
![https://res.cloudinary.com/dnj0y4eck/image/upload/f_auto,q_auto/angular.jpg"](https://res.cloudinary.com/dnj0y4eck/image/upload/f_auto,q_auto/angular.jpg"){kind=link}