When a TYPO3 page scores badly in PageSpeed Insights, the reason is rarely TYPO3 itself. TYPO3 delivers cached HTML fast. The slow part is what the HTML asks the browser to load: a 3000 pixel hero image, three web fonts from another server, a big CSS bundle and a slider script in the head.<\/p>\n
This post goes through the three things I check first on any TYPO3 site, with the Fluid and TypoScript I use, and how to measure before and after. I will not promise you numbers. Your page is different from mine, and the only numbers that count are the ones you measure.<\/p>\n
LCP<\/strong> (Largest Contentful Paint) is when the biggest visible element, usually the hero image or the main heading, is painted. CLS<\/strong> (Cumulative Layout Shift) measures how much the layout jumps while loading. INP<\/strong> (Interaction to Next Paint) measures how quickly the page reacts to clicks and taps. Images and fonts mostly hit LCP and CLS. Heavy JavaScript hits INP.<\/p>\n Before changing anything, take a baseline. For lab data, Lighthouse from the command line gives a report you can keep next to the later one:<\/p>\n Then open the page in Chrome DevTools, go to the Performance panel and record a page load. The timeline shows the LCP element, when the fonts arrive and which requests block rendering. For INP, record while you click through the menu, accordions and forms.<\/p>\n Lab data on your fast laptop is not what visitors experience. If the site has enough traffic, PageSpeed Insights also shows field data from real Chrome users. Look at both.<\/p>\n The good news first: The bigger problem is size. A phone does not need a 1600 pixel image. In TYPO3 14.2 and newer there is Arbitrary attributes like On TYPO3 13.4 there is no srcset ViewHelper yet. Build the attribute with If the hero image is a CSS background, or the font is referenced only inside the CSS file, the browser discovers it late: first HTML, then CSS, then the image or font. A preload in the head starts the download right away.<\/p>\n TYPO3 14.0 added Use the same srcset and sizes as on the For a font, the TypoScript way also works on v13. This is how hoja.in preloads the one heading font that is visible above the fold:<\/p>\n Preload only one or two files. If you preload everything, nothing is a priority any more.<\/p>\n Web fonts cause two problems: invisible text while they load, and a layout jump when they arrive. What I do:<\/p>\n If the swap still causes a visible jump, choose a fallback font with similar metrics, or adjust it with Every stylesheet in the head blocks rendering until it is loaded. On many older TYPO3 sites I see a framework CSS, a theme CSS, a slider CSS and a plugin CSS, all in the head and all on every page.<\/p>\n INP problems usually come from big scripts that run on every click: sliders, tracking, consent tools. Here the Performance panel helps again; look for long tasks after your interactions.<\/p>\n Run the same Lighthouse command with That’s it. No magic extension, just images in the right size, fonts that do not hide text, and less in the head. If this post helped you, I will be really happy.<\/p>\n Most LCP and layout shift problems on TYPO3 pages come from oversized images, late fonts and blocking CSS. Fixes with f:image, srcset, preload and font-display, and how to measure.<\/p>\n","protected":false},"author":1,"featured_media":73,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[40,39,41,5],"class_list":["post-72","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development","tag-css","tag-performance","tag-seo","tag-typo3"],"yoast_head":"\nStep 1: Measure first<\/h2>\n
npx lighthouse https:\/\/myport.ddev.site\/ \n --only-categories=performance \n --output=html --output-path=.\/lighthouse-before.html<\/code><\/pre>\nStep 2: Images with real dimensions and srcset<\/h2>\n
<f:image><\/code> writes width<\/code> and height<\/code> attributes from the processed image automatically. With img { max-width: 100%; height: auto; }<\/code> in your CSS, the browser reserves the right space and the layout does not jump. If you build <img><\/code> tags by hand with f:uri.image<\/code>, you lose this, and that is a common source of CLS.<\/p>\nf:image.srcset<\/code> (Feature #102215) for exactly this. Here the hero image comes from the media<\/code> field of the page through the files data processor:<\/p>\npage.10.dataProcessing.20 = files\npage.10.dataProcessing.20 {\n references.fieldName = media\n as = heroImages\n}<\/code><\/pre>\n<f:if condition=\"{heroImages.0}\">\n <f:variable name=\"hero\" value=\"{heroImages.0}\" \/>\n <f:variable name=\"heroSrcset\" value=\"{f:image.srcset(image: hero, srcset: '480w, 800w, 1200w, 1600w')}\" \/>\n\n <f:image image=\"{hero}\" width=\"1200\"\n srcset=\"{heroSrcset}\" sizes=\"100vw\"\n loading=\"eager\" fetchpriority=\"high\" decoding=\"async\" \/>\n<\/f:if><\/code><\/pre>\nsrcset<\/code>, sizes<\/code> and fetchpriority<\/code> are passed through to the tag. The alt<\/code> text comes from the file reference if you do not set it. Two rules that matter for LCP:<\/p>\n\n
loading=\"lazy\"<\/code>. Lazy loading the LCP image delays it. Use eager<\/code> and fetchpriority=\"high\"<\/code>.<\/li>\nf:uri.image<\/code> per width instead:<\/p>\nsrcset=\"{f:uri.image(image: hero, width: '480')} 480w, {f:uri.image(image: hero, width: '800')} 800w, {f:uri.image(image: hero, width: '1200')} 1200w\"<\/code><\/pre>\nStep 3: Preload what the browser finds too late<\/h2>\n
f:page.headerData<\/code> (Feature #107056), so the preload can sit next to the image in the same template:<\/p>\n<f:page.headerData>\n <link rel=\"preload\" as=\"image\" fetchpriority=\"high\"\n imagesrcset=\"{heroSrcset}\" imagesizes=\"100vw\">\n<\/f:page.headerData><\/code><\/pre>\n<img><\/code>, otherwise the browser downloads two different files. The ViewHelper outputs its content as it is, so never put unescaped user input in there.<\/p>\npage.headerData.10 = TEXT\npage.headerData.10.value = <link rel=\"preload\" href=\"{path : EXT:sitepackage\/Resources\/Public\/Fonts\/big-shoulders-display-latin-800-normal.woff2}\" as=\"font\" type=\"font\/woff2\" crossorigin>\npage.headerData.10.insertData = 1<\/code><\/pre>\nStep 4: Fonts that do not block text<\/h2>\n
\n
font-display: swap<\/code>.<\/strong> Text is shown at once in a fallback font and swapped when the web font is ready.<\/li>\n@font-face {\n font-family: \"Atkinson Hyperlegible\";\n src: url(\"..\/Fonts\/atkinson-hyperlegible-latin-400-normal.woff2\") format(\"woff2\");\n font-weight: 400;\n font-display: swap;\n}<\/code><\/pre>\nsize-adjust<\/code> in a second @font-face<\/code> rule.<\/p>\nStep 5: Keep render-blocking CSS and JavaScript small<\/h2>\n
\n
site.css<\/code> and one small site.js<\/code>.<\/li>\ndefer<\/code>. The small site.js<\/code> on hoja.in stays blocking on purpose, because it sets a js<\/code> class before the first paint, and there is a comment in the TypoScript that says so. Write such decisions down, or the next person “optimises” it away.<\/li>\n<\/ul>\nStep 6: Measure again<\/h2>\n
--output-path=.\/lighthouse-after.html<\/code> and compare the two reports side by side, especially the LCP element and the “render-blocking resources” section. Change one thing at a time when you can, so you know which change helped.<\/p>\nFurther reading<\/h2>\n
\n