Murshid Muzamil

Enhancing an Agentic Wiki with Graphify for Semantic Reasoning

Mon, 11 May 2026 00:00:00 +0000

I have been experimenting with a Karpathy style LLM maintained wiki for small business knowledge management. The system is structured as a Markdown based knowledge base where agents maintain concepts, entities, summaries, and syntheses across a strict directory taxonomy.

This approach has been effective for organizing knowledge into a clean, navigable structure that agents can reliably use for summarization and retrieval.

However, while the wiki provides strong explicit structure, it is limited by its reliance on manually defined links and human imposed categorization.

I am now exploring Graphify as a complementary semantic layer to enhance relationship discovery, retrieval quality, and multi hop reasoning.

The Wiki Approach

The current system is inspired by the LLM wiki pattern used in agent based knowledge systems.

Core Structure

concepts/ → business ideas and frameworks
entities/ → organizations, legal structures, tools
summaries/ → distilled knowledge from raw sources
syntheses/ → comparative reasoning and decision frameworks
journal/ → observations and experiments

Each page includes:

YAML frontmatter metadata
strict naming conventions
explicit wiki style linking
agent maintained updates

Strengths

Highly interpretable Markdown structure
Deterministic navigation via explicit links
Stable, curated knowledge representation
Strong alignment with LLM summarization workflows
Easy to audit and maintain

Limitations

Despite its structure, the system has inherent constraints:

Relationships must be explicitly written
Cross domain connections are often missed
Multi hop reasoning is limited
Semantic similarity is not computed
Knowledge remains partially fragmented across folders

In short: the wiki is a structured knowledge repository, not a fully connected semantic system.

Introducing Graphify

Graphify introduces a different paradigm: a semantic knowledge graph extracted from documents and relationships.

Graphify

Instead of organizing knowledge into pages, it builds:

nodes (concepts, entities, documents)
edges (relationships between them)
inferred semantic links
confidence scored associations
clustered communities of related ideas

Graphify processes information through multiple passes:

structural extraction (documents, code, metadata)
semantic inference (LLM based relationships)
media transcription (audio/video)
graph merging and clustering

The output is a connected knowledge network, not a document tree.

What Graphify Adds to the Wiki System

Graphify does not replace the wiki. It enhances it by adding a hidden semantic layer.

1. Discovery of Implicit Relationships

The wiki only contains explicit links such as:

[[startup]] [[small business financing]]

Graphify can infer missing relationships:

For example,

startup → undercapitalization risk
franchising → alternative to entrepreneurship
financing → constraint on marketing capacity

These are often not explicitly encoded but are critical for reasoning.

2. Cross Domain Connectivity

The wiki separates knowledge into structured domains:

concepts/ entities/ syntheses/

Graphify ignores folder boundaries and connects across them:

legal structures ↔ tax implications ↔ financing models
marketing ↔ customer acquisition ↔ cash flow
operations ↔ scalability ↔ cost structure

This produces a unified semantic view of the system.

3. Multi Hop Reasoning for Agents

Graphify enables traversal based reasoning:

Example:

small business
→ undercapitalization
→ financing gaps
→ startup failure patterns

This allows agents to perform reasoning chains instead of isolated retrieval.

4. Conflict Detection and Consistency Checking

Graphify can identify contradictions across documents:

one synthesis may claim franchising reduces risk
another may highlight operational rigidity risks

These relationships can be flagged as: conflicting uncertain context dependent

This improves the reliability of the knowledge base.

5. Semantic Retrieval Enhancement

Instead of retrieving isolated Markdown pages, Graphify enables:

entity based retrieval
neighborhood expansion (k hop traversal)
community based clustering

This significantly improves retrieval context for agents.

6. Emergent Structure Discovery

Graphify can reveal hidden patterns:

clusters of marketing related concepts
financing dependency networks
operational bottlenecks across business types

This helps validate and refine the existing taxonomy.

How the Two Systems Complement Each Other

The wiki and Graphify serve different roles:

Layer	Role
Karpathy style Wiki	Structured, curated knowledge representation
Graphify	Semantic relationship and inference layer
Agents	Reasoning + summarization layer

Combined System Behavior

The wiki provides: structured definitions
curated explanations
explicit taxonomy
Graphify adds: implicit relationships
cross domain links
semantic clustering
multi hop connectivity
Agents use both: wiki for grounded explanations
graph for deep contextual reasoning

Why This Matters for Business Knowledge

Business systems are inherently relational:

financing affects marketing
legal structure affects taxation
customer acquisition affects cash flow
operations affect scalability

A wiki captures these concepts individually.

A graph captures how they interact.

For agent based systems, these relationships are often more important than isolated definitions.

Agents Think in Markdown, Humans Prefer HTML

Sun, 10 May 2026 00:00:00 +0000

The funny thing about the viral HTML vs Markdown post from Thariq (Anthropic) is that it’s basically stating something incredibly obvious, but packaging it in a way that suddenly makes everyone collectively realize it at the same time.

Of course HTML is better for humans. Of course agents should output visually structured artifacts instead of giant Markdown walls. Of course a browser is a better interface for consuming complex AI-generated information than endlessly scrolling through a 500-line .md file. None of this is actually surprising.

The core idea underneath the entire article is almost hilariously simple: feed agents Markdown-like structure internally, then render the final output as HTML for humans.

That’s really it.

A fancy post to explain a very straightforward idea.

But the reason it went viral is because it quietly summarizes what agents are becoming good at. Not just answering questions, but organizing information, structuring complexity, and presenting ideas in ways that are actually pleasant to consume.

And honestly, the examples in the article make the point very well.

Things like:

interactive specs with tabs and diagrams
code reviews with flowcharts and annotations
visual diff explorers
mockups and UI prototypes
reports synthesized from Slack, Git history, and documents
temporary interfaces for editing prompts or configs
export buttons and interactive controls

None of these are fundamentally new capabilities. The underlying intelligence is often the same model generating the same information it would have generated in Markdown anyway.

The difference is the presentation layer.

Once agents become capable enough to synthesize large amounts of context, presentation suddenly matters much more than before. An ugly Markdown dump feels cognitively heavy, even if the information itself is good. The exact same output rendered with diagrams, visual hierarchy, cards, timelines, previews, tabs, and interactive controls suddenly feels significantly more intelligent and usable.

In many cases, the reasoning barely changed at all.

The interface changed.

And browsers are still the best medium we’ve ever built for information density and navigation. HTML was always going to become the natural output layer once agents became capable of producing things larger than simple chat replies.

So the article itself is not technically revolutionary. But it captures something important about where agent workflows are heading.

Agents are increasingly useful not just because they “know” things, but because they can take messy, overwhelming information and reshape it into formats humans can actually understand, navigate, share, and work with comfortably.

That’s probably why the post resonated so much. It articulated an obvious idea that many people were already experiencing intuitively while working with agents every day.

The Business Brain: Organizing Small Business Chaos with AI Agents

Sat, 09 May 2026 00:00:00 +0000

Small businesses are still massively under-discussed when it comes to AI transformation.

Most of them don’t feel like systems. They feel like habits stitched together with spreadsheets, inboxes, and informal decisions. Work gets done, but only because people constantly bridge the gaps.

Invoices in Excel. Customer updates in WhatsApp. Support handled from memory. Pricing exceptions decided case by case. It functions, but it’s fragile.

The opportunity for AI isn’t just automation. It’s structure.

Agentic workflows aren’t valuable only because they execute tasks faster. Their real value is that they can observe how work actually happens, surface patterns, and reveal where knowledge is fragmented or inconsistent.

Most inefficiency in small businesses isn’t dramatic failure. It’s repetition without structure:

The same invoice corrections happening repeatedly
Customer replies rewritten from scratch
Refund decisions varying by staff member
SOPs that exist but aren’t consistently applied

AI agents can begin to expose these patterns. Not just act, but map how work flows and where it breaks.

That leads to a useful framing: the Business Brain.

A Business Brain isn’t a chatbot over documents or a search layer across tools. It’s a living representation of how a company operates its decisions, processes, and context continuously updated through real activity.

It connects actions across systems and preserves operational memory so that work becomes consistent, not dependent on who happens to be involved.

Underneath this shift is a simple constraint: models are no longer the bottleneck.

The bottleneck is domain knowledge.

In most companies, critical knowledge is scattered Slack messages, email threads, spreadsheets, support tickets, and individual memory. Humans act as the integration layer between all of it.

AI agents don’t naturally operate in that fragmented environment. They require structure: explicit processes, accessible context, and operational memory rather than passive documentation.

This is why many agent-focused systems, including those discussed in the YC ecosystem, converge on similar ideas around persistent context, tool use, and organizational memory.

The direction is consistent: AI that doesn’t just respond, but operates across workflows with continuity.

One YC framing that captures this well is that the real blocker to AI automation is not model capability, but fragmented company knowledge spread across tools and people:

Business Brain

The implication is straightforward:

AI doesn’t just automate work it forces work to become structured.

For small businesses, this is the real unlock. Not surface-level automation, but the transformation of messy, informal operations into systems that can be understood, improved, and reliably executed.

That’s where efficiency gains appear. That’s where leakage gets eliminated. And that’s where the Business Brain becomes meaningful not as a feature, but as an operating layer for the company.

Why Wiki-style Knowledge is Better Than RAG for Agents

Fri, 08 May 2026 00:00:00 +0000

I’ve been thinking about this a lot lately, and I keep ending up in the same place: for most agent workflows, the wiki-style knowledge structure just feels more natural and durable than classic RAG.

RAG had its moment and it still works but in practice it often feels like a temporary architectural compromise. You chunk documents, embed them, retrieve top-k, and hope the answer is somewhere in that semantic neighborhood. It’s clever, but it’s also a bit fragile. Context gets fragmented, relevance is probabilistic, and the system never really “understands” how knowledge connects.

The wiki pattern feels different. Instead of treating knowledge as scattered embeddings to be fetched on demand, you structure it like a living system of interconnected pages more like how humans actually maintain shared understanding. Agents don’t just retrieve snippets; they navigate a knowledge graph that can evolve, accumulate structure, and support reasoning over time.

What’s interesting is that the industry is slowly drifting in this direction. Even tools like Pinecone’s Nexus are pointing toward more agent-native knowledge systems rather than pure vector retrieval. You can see the shift away from “search for context” toward “maintain and reason over a structured memory.”

There’s also a growing discourse around this in the agent community. Andrej Karpathy has been vocal about the idea that LLMs paired with persistent, structured knowledge bases almost wiki-like in nature are a more scalable direction than naive RAG pipelines. Not as a rejection of retrieval, but as an upgrade in how knowledge is organized and maintained over time.

Karpathy method:

Andrej Karpathy: LLM wiki knowledge base discussion

To me, the key difference is this: RAG is about finding knowledge, while wiki-style systems are about accumulating and structuring it. And for agents that are supposed to operate over long time horizons, the latter starts to matter a lot more.

RAG wasn’t wrong it just feels increasingly like an intermediate step.

What's new in Safari 17

Wed, 07 Jun 2023 00:00:00 +0000

Apple has unveiled Safari 17, its latest browser release that delivers a significant upgrade to browsing technology across its desktop and mobile platforms.

WWDC23 announcements

The announcement was done at Apple’s Worldwide Developers Conference (WWDC23), where a host of exciting Apple product updates were showcased.

While the event attracted significant attention due to the next-generation hardware announcements by Apple, it is equally important to underscore the notable advancements announced for Safari.

In the latest WebKit open-source blog post, Apple revealed that Safari 17 will introduce an impressive 88 new web features. Key among those features are integration of Web Apps on Mac (🎉), Spatial Web elements for immersive spatial computing, improved Media streaming capabilities and exciting updates for render elements.

Today we will delve into the key features that are specifically designed to elevate and optimize web performance.

Its important to note that currently the features are available only via Safari Technology Preview, an experimental version of Apple’s Safari browser for developers, while the official version upgrade is anticipated to be released for all users in the upcoming fall.

JPEG XL

JPEG XL is a groundbreaking modern image format. Safari 17 will be the first browser to support JPEG XL officially.

JPEG XL offers the capability to recompress images without compromising data, leading to a significant reduction in file size of up to 60%. This advancement promises improved image quality and reduced transfer size, benefiting web performance and user experience.

What sets JPEG XL apart is its progressive loading capability, enabling users to start viewing images before the entire file is downloaded.

While it competes with AVIF and WebP, this new image format aims to become the unifying solution to raster images on the web, as similar to what SVG is to vectors.

Use case

Compression Superior image quality and compression ratios compared to legacy JPEG. The compression ratios achieved by JPEG XL are superior to those of both AVIF and WebP, as the file size can be reduced up to 1/50th of the original size.
Smooth transition JPEG is the most popular web image format. Transcoding JPEG images to JPEG XL is seamless and lossless, ensuring compatibility with existing JPEG-based applications.
Optimization The codec can be optimized for specific criteria. For example retaining high fidelity (i.e. Compatiblity with Professional photography needs), or for encoding speed (i.e. Faster image generation) or for compression ratio (i.e. Smaller files).

Its a point to note that each format brings its own set of features and optimizations to the table, aiming to strike the perfect balance between image quality and file size.

While there is wide adoption for AVIF and WebP, JPEG XL was trailing. Competing formats are bad for web standards, but it would be interesting to see the growth and development of this image format with the support of Apple.

Preconnect via HTTP Early Hints

Safari 17 brings a welcome performance feature by introducing support for preconnect via HTTP Early Hints. While this functionality was previously limited to Chromium-based browsers, it is now being experimented with in Safari

While Safari has previously supported other Early hints such as DNS prefetch (desktop), prefetch (experimental), and preload (desktop and mobile), the introduction of preconnect in Safari 17 further enhances the browser’s performance capabilities.

<link rel="preconnect" href="https://fonts.googleapis.com">

With preconnect, browsers have the ability to establish connections with external resources, like servers and APIs, ahead of time. This is particularly useful when a webpage includes references to external libraries or resources, such as Google Fonts.

Image 1: An example of preconnect tag to Google fonts servers

When a browser requests a resource, it does a DNS lookup, establishes a TCP connection and employs TLS encryption to ensure secure transmission. With preconnect, the browser can establish this early lookup and be prepared to accept the response while it idles until it receives a server response.

Testing by Cloudflare has demonstrated a noteworthy 30% enhancement in page load time for initial website visits using Early hints. This underscores the significance of widespread browser adoption for better web performance.

Fetch priority

Fetch Priority is a markup-based signal that enables developers to prioritize resources on their websites.This was only available on Chromium and now comes to Safari as well.

As opposed to server/network Early hints, this is primarily a browser API based signal.

Each browser has its own prioritization system for different file types. By default for example, Chrome assigns high priority to CSS files as they are considered render blocking resources, while non-blocking JavaScript and images are set to low priority.

It can be primarily used to boost the priority of the Largest Contentful Paint (LCP) image by specifying fetchpriority=”high” on the image element. This causes the LCP to happen sooner, resulting in a faster website load time.

LCP being a core web vital, this is one of the popular ways web developers utilize this feature.

<!-- Fetch the LCP image on high priority -->
<img src="lcp.jpg" fetchpriority="high">

<!-- Lower the priority of a below the fold image -->
<img src="-image.jpg" fetchpriority="low">

For Safari it is unclear how fetchpriority will be implemented at this point, given the browser resource prioritization. But there is a detailed guide on how Google Chrome handles this feature.

Why Safari matters

Safari’s last major upgrade was version 16, which was released for macOS Monterey and macOS Big Sur on September 2022. It was also shipped on iOS 16 which covered iPhone and iPad devices.

When considering the usage of web browsers, Safari holds a notable position, although it falls well behind Google Chrome in terms of global browser market share. (Desktop 12.85% , Mobile 27.8% - Source)

While prioritizing Chrome is essential for enhancing web performance due to its market dominance, it is equally crucial to recognize Safari’s substantial presence on mobile devices.

Thus, if your target audience predominantly uses Safari, it is crucial to dedicate efforts to test, improve, and optimize your website specifically for Safari users.

Links

Safari 17 Beta Release Notes https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes
Comparison of next-Gen image formats https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
Safari supported media formats https://developer.apple.com/videos/play/wwdc2023/10122

Back Forward cache: What you need to know

Tue, 16 May 2023 00:00:00 +0000

Imagine you’re browsing an online store, looking at different products. You click on an item to view its details but then decide to go back and continue exploring. Thanks to bfcache, when you return to the previous page, it instantly appears with all the information and images loaded, without having to wait for it to load again from the server.

What is bfcache?

Back/forward cache (bfcache) is a feature of web browsers that allows pages to be restored from memory after the user has navigated away from them and then back again. This can improve the performance of web pages by reducing the number of times that pages need to be loaded from the server.

This seamless experience saved you time, bandwidth and made your shopping journey smoother.

Let’s delve into the details of this feature, which is supported by modern browsers, including mobile devices.

How does bfcache work?

Bfcache operates by saving a comprehensive snapshot of a page, including the JavaScript heap, in memory as the user navigates away. With the complete page stored in memory, the browser can swiftly and effortlessly restore it when the user chooses to return.

This snapshot encompasses the HTML, CSS, JavaScript, and all other resources essential for rendering the page. Subsequently, if the user navigates away from and subsequently back to the page, the browser can restore it from memory instead of fetching it again from the server.

PageTransitionEvent

The PageTransitionEvent plays a role in signaling page transitions, including when a page is being unloaded or when a new page is being loaded. When a user navigates away from a page, such as by clicking a link or using the browser’s back or forward button, the PageTransitionEvent is triggered to notify the page that it is being transitioned out of view.

It encompasses various event types, including “pageshow”, “pagehide”, “beforeunload” and “unload” each corresponding to a specific stage in the page transition process.

This offers developers a way to observe and respond to page transitions within the browser, enabling them to enhance user experiences, implement custom behaviors, and optimize resource management.

Note: The unload event has been available in web browsers for a long time and is triggered when a page is being unloaded, either by navigating away or closing the browser window. On the other hand, the pagehide event was introduced later and provides an additional opportunity for developers to perform actions or cleanup tasks before a page is hidden or unloaded.

How can I make my pages eligible for bfcache?

There are a few things that you can do to make your pages eligible for bfcache:

Avoid using the unload event The unload event is fired when the user is about to navigate away from a page. If you use the unload event to do anything that might affect the page’s state, such as saving data or closing a modal dialog, then the page will not be eligible for bfcache.
Avoid attaching event listeners to the beforeunload event The beforeunload event is fired when the user is about to navigate away from a page and gives the page a chance to ask the user if they’re sure they want to leave. If you attach an event listener to the beforeunload event and the user clicks “Cancel,” then the page will not be eligible for bfcache.
Do not make any network requests after the user has navigated away from your page If you make any network requests after the user has navigated away from your page, then the browser will not be able to restore the page from memory. This is because the browser will not know what resources are needed to render the page.

Note: If there are any unload event listeners on your page, you should convert them to pagehide event listeners

How can I check if my pages are eligible for bfcache?

You can check if your pages are eligible for bfcache using the Chrome DevTools. To do this, open the DevTools and go to the Applications tab. In the Cache section, look for the Back/forward cache entry. If your pages are eligible for bfcache, they will be listed in this section.

You can find more information about testing page optimization for instant loads and identifying issues that may affect eligibility for back-forward cache in the Chrome DevTools documentation.

Limitations of bfcache

Size The size of the bfcache is limited by the amount of memory available on the device. When the bfcache is full, the browser will start to evict pages that have not been visited recently. This means that pages that are frequently visited or that contain a lot of resources may not be cached if the bfcache is full.
Persistence The bfcache is not persistent. When the browser is closed, the bfcache is cleared. This means that any pages that are stored in the bfcache will be lost when the browser is closed.
Security The bfcache is not secure. Any sensitive information that is stored in the bfcache can be accessed by anyone who has access to the device. This means that sensitive information, such as passwords or credit card numbers, should not be stored in the bfcache.

What are the benefits?

Bfcache can improve the performance of web pages by reducing the number of times that pages need to be loaded from the server. This can lead to faster page load times, which can improve the user experience.

Improved performance bfcache can significantly improve the performance of web pages, especially for pages that are frequently visited or that contain a lot of resources. By storing a copy of the page in memory, the browser can avoid having to make a new request to the server, which can save time.
Reduced bandwidth usage bfcache can also help to reduce bandwidth usage by the browser. When a page is stored in bfcache, the browser does not have to download the page from the server again when the user navigates back to it. This can save bandwidth for both the user and the host.
Better user experience bfcache can provide a better user experience by making it faster and easier for users to navigate back to pages that they have recently visited. This can help to improve the overall usability of a website and make it more enjoyable for users to visit.

Key observations

In her recent talk on How to Prioritize Web Performance Optimizations by Melissa Ada, she presented some interesting observations with regard to bfcache. (Slide from Melissa Ada)

The sharp increase in CLS scores for mobile devices in 2022 is believed to be closely related to the introduction of bfcache. The Web Almanac team suspects this as one of the primary factors contributing to the trend.

You can refer to the Web Almanac report for 2022 to explore the detailed analysis and reasoning behind this correlation. It aligns with the launch of bfcache on Chrome in late 2021.

Resources:

Bfcache eligibility criteria (100+) https://docs.google.com/spreadsheets/d/1li0po_ETJAIybpaSX5rW_lUN62upQhY0tH4pR5UPt60/edit#gid=0

Understanding how browsers identify the LCP element

Fri, 07 Apr 2023 00:00:00 +0000

Largest Contentful Paint (LCP) is a key performance metric that measures the loading speed of a webpage and is part of the Google Web Vitals initiative, which was introduced in May 2020.

Specifically, LCP measures the time it takes for the largest visible element on a page to become fully loaded and rendered in the viewport.

This element could be an image, video, or another content element that occupies a significant amount of screen real estate.

How does Chrome determine the Largest Contentful Paint (LCP) Element?

Here are the general steps that Chrome takes to determine the LCP element:

The browser begins to load the webpage and parses the HTML code to construct the Document Object Model (DOM) and the Render Object Model (ROM).
As the page loads, the browser searches for all visible block-level or replaced elements (such as images or videos) within the viewport.
For each eligible element, the browser calculates the size of the render box, which takes into account the element’s width, height, padding, and border. This calculation doesn’t include the margin or size of any child elements.
The browser selects the element with the largest render box size as the candidate for Largest Contentful Paint (LCP). This element must also be loaded via an HTTP request and be visible in the viewport at the time of measurement.
After identifying the LCP candidate, the browser measures the time it takes for the element to become fully visible in the viewport. This occurs when the element’s content is rendered and its layout is stable.
The time it takes for the largest contentful paint (LCP) element to become fully visible is recorded as the LCP value for the webpage.

It’s important to note that the LCP value may change as the page continues to load, and the final LCP value is typically the one recorded when the page finishes loading or when the user interacts with the page.

Figure 1: LCP element changed after the page is fully loaded

Factors that could affect LCP value

As per Google, the LCP metric can be primarily affected by these four factors,

Slow server response times
Render-blocking JavaScript and CSS
Resource load times
Client-side rendering

Slow server response times can cause delays in loading content, while render-blocking JavaScript and CSS can prevent the browser from rendering content until they’re fully loaded.

Resource load times refer to the time taken for the browser to download and process images, videos, and other media, while client-side rendering involves processing and rendering content on the user’s device.

Mobile and Desktop may have different LCP elements

Mobile devices and desktops have different screen sizes and resolutions, which can affect how a webpage is rendered and which elements are considered the largest on the page.

For example, an image that takes up a significant portion of a desktop screen may not take up as much space on a mobile screen, where the LCP element might instead be a text block or a button.

Additionally, mobile devices often have slower network speeds and processing power compared to desktops, which can impact how quickly the LCP element is loaded and rendered on the screen.

Figure 2: LCP element for dailymail.co.uk is different on mobile and desktop

Common LCP elements on a webpage

Google specifies what specific elements may be considered as LCP. Refer https://web.dev/lcp/#what-elements-are-considered.

Below are some common elements in web pages that are eligible:

Hero section image or video
Background image Background images which are loaded via the url() function
Video thumbnail
Image carousel
Text Text can also be an LCP element, especially if it is the primary content on a webpage.

Figure 3: LCP element can defer according to a specific website

What elements may not be considered

It’s understood that not all elements are considered candidates for LCP. For instance, elements that are not visible within the viewport, such as elements located at the bottom of the page or behind other elements, are not considered.

Additionally, elements that are dynamically generated, such as ads or pop-ups, may not be considered if they are not loaded via an HTTP request.

While background images can be an LCP element, solid background colours or patterns are typically not considered since they don’t require an HTTP request to load.

Lazy-loaded content may not be applicable as LCP as well. Lazy-loading is a technique used to defer the loading of non-critical resources until they are needed, such as images or videos that are below the fold.

Since the lazy load resources are not loaded immediately, they may not be considered part of the LCP calculation.

SVG elements on a page although the largest visible element may not be considered for LCP as well.

Figure 4: A larger SVG element may be ignored

How to find the LCP element on my webpage

To replicate and test the LCP (Largest Contentful Paint) values of your webpage, you can run audits using an online tool like Google’s PageSpeed Insights, GTMetrix and Webpagetest.

In a local environment, you can use Chrome’s DevTools:

Open the webpage of interest in your browser, such as cnn.com.
Open the Developer Tools in your browser. In Chrome, you can do this by clicking on the top right menu > More Tools > Developer Tools, or by pressing Ctrl+Shift+I.
Navigate to the Performance tab in the Developer Tools and click the Reload button to load the webpage.
After the page has loaded, locate the Largest Contentful Paint (LCP) option under the timings row and hover over it to view the LCP time.
To identify the LCP element, look for the element highlighted in blue in the screenshot shown in the LCP element section of the Developer Tools.

Figure 5: Identify the LCP element on Google Chrome Dev Tools

Alternatively, you can run a free webpage test on https://www.webpagetest.org/ where it has advanced tools to track LCP changes.

Select Start a Site Performance test
Enter the website url, such as http://bbc.com/
Select either mobile or desktop, and click on Start Test
Once the test report is generated, select the Web Vitals view
Go to the Largest Contentful Paint section and select the Filmstrip view
Click on Adjust Filmstrip Settings > Filmstrip options > Highlight Largest Contentful Paints
You can observe the LCP element as it loads on the filmstrip view

Figure 6: Identify the LCP element by running a webpagetest.org audit

UPDATE 10/Apr/2023 : To deep dive into LCP and recent trends from CrUX report refer https://almanac.httparchive.org/en/2022/performance#largest-contentful-paint-lcp

Happy discovering!