DEV Community: Jak s

5 Angular 17 performance wins that actually matter

Jak s — Mon, 15 Jun 2026 14:22:44 +0000

I've spent the last few years building large Angular applications for enterprise clients — data-heavy dashboards, real-time monitoring tools, document processors. Every project starts the same way: default change detection, BehaviorSubject everywhere, *ngFor without trackBy. By tip 3 or 4 in this list, the difference in rendering performance is visible without a profiler.

Here are the five things I do on every project.

OnPush everywhere 1 Angular's default change detection checks every component on every event. ChangeDetectionStrategy.OnPush cuts this to only check a component when its @Input() references change, an async pipe emits, or you call markForCheck() explicitly. On a tree with 200+ components, this is the single biggest win.

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
selector: 'app-invoice-row',
templateUrl: './invoice-row.component.html',
changeDetection: ChangeDetectionStrategy.OnPush,
})
export class InvoiceRowComponent {
@Input() invoice!: Invoice;
}
The cost: you have to be more deliberate about when data changes. Mutating an object in place won't trigger change detection — you need to produce a new reference. That discipline is worth it for the performance gain, and it also makes your code easier to reason about.

Signals instead of BehaviorSubject 2 Angular 17's signals (signal(), computed(), effect()) are a leaner alternative to BehaviorSubject for local and shared state. They integrate directly with Angular's change detection — when a signal value changes, only the components that read it are marked dirty, with no manual subscription management.

import { signal, computed } from '@angular/core';

// In a service or component:
const invoices = signal([]);
const totalAmount = computed(() =>
invoices().reduce((sum, inv) => sum + inv.total, 0)
);

// To update:
invoices.update(prev => [...prev, newInvoice]);

// In the template — no async pipe needed:
// {{ totalAmount() }}
computed() memoises automatically — it only recalculates when one of its signal dependencies changes. Replace your derived BehaviorSubject chains with computed() and you get lazy evaluation for free.

Virtual scrolling with CDK 3 Rendering a list of 5,000 rows creates 5,000 DOM nodes. Virtual scrolling renders only the nodes visible in the viewport, typically 20–50 items, and recycles them as the user scrolls. The Angular CDK provides this out of the box.

// Install: npm install @angular/cdk
// app.module.ts or standalone imports:
import { ScrollingModule } from '@angular/cdk/scrolling';

// Template:

class="invoice-row">
{{ invoice.vendor_name }} — {{ invoice.total | currency }}

itemSize is the fixed height of each row in pixels. For variable-height items, use AutoSizeVirtualScrollStrategy from the experimental package — it measures items and adjusts, though it's slightly more expensive to initialise.

trackBy / track in @for — prevent DOM thrashing 4 Without identity tracking, Angular destroys and recreates every DOM node when a list is re-assigned, even if only one item changed. trackBy tells Angular how to identify items across re-renders, so only genuinely changed or new items touch the DOM.

In the legacy *ngFor syntax:

trackById(index: number, invoice: Invoice): string {
return invoice.id;
}
In Angular 17's new @for control flow (preferred for new code), track is mandatory — the compiler enforces it:

@for (invoice of invoices; track invoice.id) {

}
Use a stable, unique property like a database ID or UUID. Using index as the track key is better than nothing but still causes unnecessary re-renders when items are reordered or inserted in the middle.

Lazy-loaded standalone components 5 Module-based lazy loading is well known, but with standalone components in Angular 17 you can lazy-load individual components directly from a route — no NgModule wrapper required. The component and its entire dependency tree are split into a separate chunk and fetched only when the route is first navigated to.

// app.routes.ts
import { Routes } from '@angular/router';

export const routes: Routes = [
{
path: 'dashboard',
loadComponent: () =>
import('./dashboard/dashboard.component')
.then(m => m.DashboardComponent),
},
{
path: 'invoices',
loadComponent: () =>
import('./invoices/invoice-list.component')
.then(m => m.InvoiceListComponent),
},
];
Combine this with PreloadAllModules or a custom preloading strategy to pre-fetch chunks after the initial route has loaded, giving you the best of both worlds: fast initial load and near-instant subsequent navigation.

// main.ts or app.config.ts
import { provideRouter, withPreloading, PreloadAllModules } from '@angular/router';

provideRouter(routes, withPreloading(PreloadAllModules))

Measure first — profile before you optimise Applying optimisations blindly wastes time and can introduce bugs. Before touching change detection or lazy loading, measure where the actual bottleneck is. Two tools I always use:

Angular DevTools (Chrome extension) gives you a component tree with render times. Sort by time spent and you'll find the real offenders within minutes — usually one or two components responsible for 80% of the render cost.

Bundle analyser: run ng build --stats-json then feed the output to webpack-bundle-analyzer. You'll immediately see which third-party libraries are bloating your initial bundle. I've seen projects shave 200KB off their initial load just by switching from moment.js to date-fns or by moving a charting library behind a lazy route.

Build with stats

ng build --stats-json

Analyse the bundle

npx webpack-bundle-analyzer dist/your-app/stats.json
Target a First Contentful Paint under 1.8s and a Total Blocking Time under 200ms on a mid-range mobile device. If you're above those, the five tips above — especially OnPush, signals, and lazy loading — will move the needle.

Three more wins worth knowing These don't make my "top 5" list because they're more situational, but they're worth keeping in mind for larger apps:

Pure pipes over methods in templates. Angular re-evaluates method calls in templates on every change detection cycle. Replace them with pure pipes — Angular caches the result and only recalculates when the input changes.
Avoid large object bindings in templates. Binding [data]="largeObject" forces deep comparison on every cycle. Flatten or memoize the values you actually need in the template.
Use the async pipe instead of manual subscriptions. It handles subscription teardown automatically and integrates cleanly with ChangeDetectionStrategy.OnPush — the component re-renders only when the observable emits, not on every cycle.
// ❌ Method call in template — runs every cycle
{{ formatDate(item.createdAt) }}

// ✅ Pure pipe — cached, runs only when input changes
{{ item.createdAt | formatDate }}

// ✅ async pipe with OnPush
@Component({
changeDetection: ChangeDetectionStrategy.OnPush,
template: <div *ngIf="data$ | async as data">{{ data.name }}</div>
})
export class MyComponent {
data$ = this.service.getData();
}
Angular 17 performance checklist
A quick reference I run through before shipping any Angular feature to production:

✅ ChangeDetectionStrategy.OnPush on every component
✅ Signals for local and shared state — no unnecessary BehaviorSubjects
✅ @for with track on every list
✅ CdkVirtualScrollViewport on lists over 50 items
✅ All routes lazy-loaded with loadComponent
✅ Pure pipes instead of template method calls
✅ async pipe for observable bindings
✅ Bundle analysed — no accidental large imports in initial chunk
✅ Lighthouse mobile score above 85 before release

jaklens.com

AI Invoice OCR Explained: How Local AI Reads Your PDFs

Jak s — Fri, 12 Jun 2026 09:14:21 +0000

jaklens.com

Step 1 in depth: pdfjs-dist
pdfjs-dist is Mozilla's PDF rendering library — the same engine that powers Firefox's built-in PDF viewer. In jaklens.ai, it runs in the Node.js process (via Electron's main process) to extract text content from each page of the invoice.

For a typical digital invoice PDF (generated by Stripe, PayPal, a CRM, or invoicing software), pdfjs produces clean Unicode text that preserves line structure. The output looks something like:

INVOICE
Invoice #: INV-2024-0891
Date: 15 March 2025
Due Date: 15 April 2025

Bill To:
Acme Corp Ltd
123 Business Street

Item Qty Unit Price Amount
Design work 10 $150.00 $1,500.00
Hosting fee 1 $50.00 $50.00

Subtotal $1,550.00
Tax (15%) $232.50
TOTAL $1,782.50
For scanned PDFs (photographed or printed-and-scanned invoices), pdfjs renders the page to a bitmap, which is then processed by an OCR layer before the text reaches the LLM. This two-pass approach handles the majority of real-world invoice formats.

Step 2 in depth: Qwen2.5 1.5B via llama.cpp
Qwen2.5 is a language model family from Alibaba DAMO Academy. The 1.5B parameter variant, when quantized to 4-bit GGUF format, fits comfortably in approximately 1.2 GB of RAM and produces fast responses even on consumer CPUs.

jaklens.ai uses node-llama-cpp, a high-quality Node.js binding for llama.cpp. llama.cpp is the industry-standard C++ inference engine for running GGUF models locally — it supports AVX2/AVX512 CPU acceleration, NVIDIA CUDA, AMD ROCm, and Vulkan.

The prompt sent to the model is carefully structured to maximize extraction accuracy:

System prompt: instructs the model to act as an invoice data extractor and return only valid JSON
User message: the raw text from pdfjs, with a schema for the expected output fields
Temperature: set low (0.1–0.2) to reduce hallucination and maximize consistency
Max tokens: constrained to avoid excessive output
The model returns structured JSON similar to:

{
"vendor": "Design Studio Ltd",
"invoice_number": "INV-2024-0891",
"date": "2025-03-15",
"due_date": "2025-04-15",
"currency": "USD",
"subtotal": 1550.00,
"tax": 232.50,
"total": 1782.50,
"line_items": [
{ "description": "Design work", "qty": 10, "unit": 150.00, "amount": 1500.00 },
{ "description": "Hosting fee", "qty": 1, "unit": 50.00, "amount": 50.00 }
]
}
All of this inference happens on your hardware. Typical response times range from 3–8 seconds on a modern 8-core CPU, or under 2 seconds with GPU acceleration.

Why Qwen2.5 for invoices?
Several factors make Qwen2.5 1.5B well-suited for invoice parsing:

Multilingual.
Handles English and Arabic invoice text natively — important for Middle Eastern markets
Small but capable.
1.5B parameters in 4-bit GGUF is ~1.2 GB — fits on budget hardware
JSON instruction following.
Qwen2.5 is specifically trained for structured output tasks
Free.
Open-weight model, no API costs, no rate limits, no usage tracking
Accuracy and limitations
No OCR system is perfect. Known limitations of the current pipeline:

Low-quality scans:
Heavily skewed, blurry, or low-DPI scans produce degraded text extraction, which reduces parsing accuracy
Unusual layouts:
Invoices with non-standard structures (tables in images, rotated text, watermarks) may miss fields
Currency ambiguity:
Multi-currency invoices may need manual correction
Hallucination risk:
Like all LLMs, Qwen2.5 can occasionally invent fields not present in the source. Always verify critical totals before confirming
jaklens.ai addresses this by showing all extracted fields in an editable review screen before saving. You confirm, edit, or reject the AI's extraction — keeping humans in control of the data.

The privacy advantage of local inference
Your invoice text never leaves your machine. It goes from your PDF to your CPU to your SQLite database — entirely within your Windows user session.
Cloud invoice OCR services (including Google Document AI, AWS Textract, and accounting software AI features) send your document to a remote API. That means your vendors, amounts, dates, and financial relationships are processed on someone else's infrastructure. With local llama.cpp inference, that pathway doesn't exist.

Invoice OCR AI — Frequently Asked Questions
What is invoice OCR AI?
Invoice OCR AI is the use of optical character recognition combined with artificial intelligence (typically large language models) to automatically extract structured data — vendor, amount, date, line items — from invoice documents. Modern invoice OCR AI uses computer vision and machine learning instead of brittle regex templates.

How does invoice OCR machine learning work?
The invoice OCR machine learning pipeline has three stages. First, a PDF parser like pdfjs-dist extracts raw text from the document. Second, a language model like Qwen2.5 reads that text and identifies which words mean "vendor", "total", "invoice number", etc. Third, the structured JSON output is saved to a database. jaklens.ai runs all three stages locally using llama.cpp.

Can I run invoice OCR with Node.js?
Yes. Node OCR invoice processing is possible using libraries like pdfjs-dist (Mozilla's PDF parser for Node) for text extraction, and node-llama-cpp for running open-source LLMs locally. This is exactly the stack jaklens.ai uses — a pure JavaScript/Node pipeline with no external API calls.

What is computer vision invoice extraction?
Computer vision invoice extraction refers to OCR systems that read scanned image invoices (JPEG, PNG, photos) rather than digital PDFs. These pipelines typically use models like Tesseract, PaddleOCR, or vision-language models (VLMs) to convert pixels into text, then feed that text into a language model for field extraction.

Is invoice OCR deep learning more accurate than rule-based systems?
Yes, significantly. Rule-based invoice OCR breaks the moment a vendor changes their invoice layout. Invoice OCR deep learning models like Qwen2.5 understand context — they can identify a total even if it's labeled "Amount Due", "Grand Total", or "Total Payable". The tradeoff is occasional hallucination, which is why jaklens.ai always shows extracted fields in an editable review screen.

What AI model is best for invoice OCR in 2026?
For local invoices OCR processing AI, Qwen2.5 1.5B is currently the best balance of size, speed, and accuracy. It runs on consumer CPUs via llama.cpp, fits in ~1.2 GB as a 4-bit GGUF, follows JSON output instructions reliably, and supports both English and Arabic. Larger models like Qwen2.5 7B or Llama 3.1 8B are more accurate but require more RAM.

Free offline AI invoice tracker — built for Windows.

Jak s — Wed, 10 Jun 2026 09:27:51 +0000

jaklens.ai scans invoices with a local AI model, organizes every expense and income transaction, and lets you query your financial history through a private on-device assistant — running entirely on your Windows PC.

https://jaklens.com/
https://jaklens.com/blog/

I built 26 free HTML templates across 12 industries — no npm, no build step, just open and ship

Jak s — Thu, 04 Jun 2026 16:17:20 +0000

I've been building client projects for years and kept running into the
same problem: free templates either require a full framework setup or
look like they were made in 2015.

So I spent the last few months building my own collection from scratch.

What I built

26 free HTML templates across 12 industries:

-E-commerce (fashion store, Indian boutique, luxury perfume, tech shop)
-SaaS & App landing pages
-Agency & marketing
-Business & startup
-Restaurant & fine dining
-Medical & dental
-Real estate
-Education & LMS
-Fitness & yoga
-Photography portfolio
-Developer portfolio
-Blog

Every template is a single .html file. CSS and JS are inlined.

No Node.js. No npm install. No Webpack. No Vite. Just open the file
in a browser and it works.

Built with Tailwind CSS (via CDN) and vanilla JavaScript.

A few highlights

The L'Élixir Perfume Store has a cinematic intro screen,
physics-based floating scent bubbles, a canvas particle spritz effect,
and a personality quiz — all in one HTML file.

The Amara Indian Boutique has a full cart drawer, quick-view modal,
size guide, and custom consultation form.

Tech used

Tailwind CSS v3 (CDN)
Vanilla JavaScript
Lucide Icons
Google Fonts
HTML5 Canvas for animations

Where to find it

Live gallery: https://templates.jack-codes.com

GitHub: https://github.com/jakscoduxdev-netizen/website_templates

All MIT licensed. Free for personal and commercial use.

Happy to answer questions about how any of them were built.