PERFORMANCE TUNING
FOR FRONT-END DEVELOPERS
@dotmcs / #dotcms
Kyung Kim
Senior Front-End Developer
dotCMS
Oswaldo Gallango
Senior Java Developer
dotCMS
Gabriela Gonzalez
Senior Project Manager
dotCMS
Performance Tuning for Front-End Developers
AGENDA
Information Architecture Considerations
Leverage of dotCMS Tools
General Implementation Recommendations
Performance Tuning for Front-End Developers
INFORMATION ARCHITECTURE
CONSIDERATIONS
Performance Tuning for Front-End Developers
INFORMATION ARCHITECTURE
Spend time structuring your content
Use widgets to store code
Parse widget code from vtl files
Build dynamic pages and use URL maps
Use dictionaries for multilingual sites
Performance Tuning for Front-End Developers
Spend time structuring your content
DON’T
DO
Create custom
tables to store
information relevant
to your website.
Store all your
content as Content
Generic.
Depending on the
information to be
stored and its usage
throughout the
website, content
must be organized in
different structures.
Performance Tuning for Front-End Developers
DON’T
!
Product information
added to Content
(Generic) Structure
DO
!
Product information stored
in its own content structure
Use widgets to store code
DON’T
Use a piece of
content to store
code.
Performance Tuning for Front-End Developers
DO
Use simple widgets
or a specific widget
structure to store
code.
DO
!
Create a widget structure if
you need to provide
parameters for content
editors to customize the
behavior of the code.
!
Otherwise, add all your
code to a Simple Widget
instance.
Parse widget code from vtl files
DON’T
Store code directly in
the code field of a
widget structure.
Performance Tuning for Front-End Developers
DO
Save the code into a
vtl file and parse it
from the code field.
DON’T
DO
Build dynamic pages and use URL maps
DON’T
Build static listing and
detail pages.
Performance Tuning for Front-End Developers
DO
Pull content to build
dynamic listing
pages and use
dotCMS’s URL Map
functionality to build
detail pages.
DON’T
!
If you choose static pages, you
or your content contributors will
need to create a new page every
time a product is needed.
DO
!
Use the URL Map
Pattern to create a
friendly URL for each
piece of content
stored in the
structure
DO
!
Create a unique detail
page per structure and
reference each piece of
content from the listing
page using its friendly URL
Use dictionaries for multilingual sites
DON’T
Add English text in
templates, containers,
or widgets.
Performance Tuning for Front-End Developers
DO
Use
$text.get(<key>)
to get the text from
the dictionary
matching the session
language.
DON’T
!
Add text directly in you
templates, containers, or
widgets
DO
!
Use dictionary terms instead
AGENDA
Information Architecture Considerations
Leverage of dotCMS Tools
General Implementation Recommendations
Performance Tuning for Front-End Developers
LEVERAGE OF DOTCMS TOOLS
Performance Tuning for Front-End Developers
DOTCMS
TOOLS
Pulling content: filter, paginate, and find
Use dotCMS viewtools
Use dotCMS restful interfaces
Use form structures
Use cache blocks
Use a dotCMS starter theme
Performance Tuning for Front-End Developers
Pulling content: filter and paginate
DON’T
Pull all your content
with minimal search
conditions.
DO
Limit content pulled
simultaneously.
Add filters to your
searches.
Paginate results with
$dotcontent.pullPer
Page
Performance Tuning for Front-End Developers
Pulling content: find
DON’T
Use $dotcontent.pull
when pulling a single
content.
Performance Tuning for Front-End Developers
DO
Use $dotcontent.find
to pull a specific
content.
Use dotCMS viewtools
DON’T
Code all your
functionality from
scratch.
Use velocity
macros.
Performance Tuning for Front-End Developers
DO
Check out dotCMS’
viewtools and
system variables.
Use viewtools and
modern javascript
libraries to achieve
same effects.
Use dotCMS restful interfaces: Images
DON’T
Resize your images
using width and
height properties in
the img tag.
Performance Tuning for Front-End Developers
DO
Use dotCMS’ image
REST API: /
contentAsset/
resize-image/
and /
contentAsset/
image-thumbnail/
DON’T
DO
Use form structures
DON’T
Create or migrate
your old school forms
into dotCMS.
Performance Tuning for Front-End Developers
DO
Think of forms as
structures in dotCMS
and use all the
functionality provided
by the Form Handler.
Use cache blocks
DON’T
Execute every pull
every time a page is
requested; especially
for heavily trafficked
pages.
Performance Tuning for Front-End Developers
DO
In addition to caching
entire pages, you can
also go more
granular with
#dotcache.
Use a dotCMS starter theme
DON’T
Start your theme
implementation from
scratch.
Performance Tuning for Front-End Developers
DO
Download a dotCMS
starter theme; there’s
one for almost every
need.
AGENDA
Information Architecture Considerations
Leverage of dotCMS Tools
General Implementation Recommendations
Performance Tuning for Front-End Developers
GENERAL IMPLEMENTATION
RECOMMENDATIONS
Performance Tuning for Front-End Developers
GENERAL RECOMMENDATIONS
Be careful with remote calls
Mind your scripts: minified and avoid inline
Use ajax to reload sections on heavy pages
Compact your css files
Performance Tuning for Front-End Developers
Be careful with remote calls
DON’T
Add remote calls
without knowing how
reliable and fast the
external services are.
Performance Tuning for Front-End Developers
DO
Wrap results inside a
#dotCache block.
Mind your scripts: minified and avoid inline
DON’T
Use friendly versions
of custom or third
party scripts on
production instances.
Performance Tuning for Front-End Developers
DO
Keep those versions
for your development
environment and
make sure you
always use the
minified script on
production.
Use ajax to reload sections on heavy pages
DON’T
Force the entire page
to be reloaded to
update only a section
of it; especially for
heavily trafficked
pages.
Performance Tuning for Front-End Developers
DO
Use ajax to update
sections of a popular
page.
Compact your css files
DON’T
Include every single
css file in every
single template.
Performance Tuning for Front-End Developers
DO
Concatenate files to
minimize the
requests done per
page.
AGENDA
Information Architecture Considerations
Leverage of dotCMS Tools
General Implementation Recommendations
Performance Tuning for Front-End Developers
SUMMARY
Information Architecture: measure twice, cut
once:
Structure content and forms
Use widgets for code
Prefer dynamic rather than static pages
Use dictionaries for multilingual
Performance Tuning for Front-End Developers
SUMMARY
Add restrictions to every content pull
Use viewtools and REST API’s
Use page and block cache
Be careful with remote calls
Compact css and script files
Performance Tuning for Front-End Developers
RESOURCES
dotCMS documentation:
Viewtools http://dotcms.com/docs/latest/ViewtoolsThatExtendVelocity
Block Cache http://dotcms.com/docs/latest/CacheHandlingWithTags
REST API http://dotcms.com/docs/latest/RESTAPI
URL Maps http://dotcms.com/docs/latest/URLMapSEOFriendlyURLs
Multilingual Sites http://dotcms.com/docs/latest/MultilingualSite
Performance Tuning for Front-End Developers
RESOURCES
Codeshare http://dotcms.com/codeshare/
User Forum http://dotcms.com/forum/
Videos http://dotcms.com/explore/videos/
Themes http://dotcms.com/themes/
Professional Services http://dotcms.com/products/consulting/
Support http://dotcms.com/products/server/support.dot
Performance Tuning for Front-End Developers